It seems something bad is happening when banshee is looking for cover art in the folders you imported.
This probably doesn't affect the importing of tracks itself, so you should have them all in your library.

You might want to narrow it down by (re)importing one folder at a time, and see if there's anything specific to the folders for which you get these errors.

And please do so by running "banshee-1 --debug" so that you can get debug info.

Created attachment 116404 [details]
Stack trace with debug information (trunk, not 1.2)

(I'm having the same issue)

As Bertrand mentioned, it'd be great if you could provide details about a specific directory that's having this problem, e.g. what type of files, is there any cover art (and how many files)?

The stracktrace references property ReadStream of class DemuxVfs in http://svn.gnome.org/viewvc/banshee/trunk/banshee/src/Backends/Banshee.Unix/Banshee.IO.Unix/DemuxVfs.cs?view=markup

I've replaced the code of the property with the following:

try {
	return file_info.Open (FileMode.Open, FileAccess.Read);
}
catch{
	Console.WriteLine("XXXXXXXXReadStream, file: " + this.Name);
	throw;
}


And one file I obtained on the output is:


XXXXXXXXReadStream, file: /home/knocte/Music/file:/home/knocte/var/entrada/05%20Ooh%20La.mp3

The bugfix I guess is that we need some character conversion magic here...

Created attachment 116423 [details] [review]
Proposed patch

I'm not sure if this patch fixes it (I can't test it because I'm getting a wierd behaviour, I cannot compile the code even though the call is correct, as I've tested it in a minimal test project). Is it happenning the same for you guys?

I think you can't compile with make because a reference to the System.Web assembly is missing from the build system.

But looking at your output, your patch might not fix it : 

XXXXXXXXReadStream, file:
/home/knocte/Music/file:/home/knocte/var/entrada/05%20Ooh%20La.mp3

The path looks wrong to me, with the "file:" in the middle. It looks like the path to your library got concatenated with the path to the file.

Are you able to reproduce the bug by only importing this file ?

(In reply to comment #6)
> I think you can't compile with make because a reference to the System.Web
> assembly is missing from the build system.

It's strange, this is the first thing I thought, but I made a small test adding a different reference (System.Xml) just in the .mdp file, and it worked.

Later, I talked with Sandy Armstrong and he told me I had to change the file "build/build.environment.mk" and after this, it compiled, so many thanks Bertrand and Sandy!


> But looking at your output, your patch might not fix it : 
> 
> XXXXXXXXReadStream, file:
> /home/knocte/Music/file:/home/knocte/var/entrada/05%20Ooh%20La.mp3

And you're right again, because when I tested my patch, I found it this strange thing. Besides, it seems Banshee is not calling the constructor of this class (DemuxVfs), but TagLibSharp, which is very wierd. Anyway, I'll look in TagLibSharp sources.

(In reply to comment #7)
> thing. Besides, it seems Banshee is not calling the constructor of this class
> (DemuxVfs), but TagLibSharp, which is very wierd. Anyway, I'll look in
> TagLibSharp sources.
> 

Nevermind, I was grepping Banshee sources incorrectly. The bug is not in TagLibSharp. Looking into it...

I found the culprit:

The problem is that we have an uri like this:

file:///home/knocte/var/entrada/emp/01%20empire.mp3

and, for checking if it's an absolute URI or not, we have this code:

uri_field[0] == System.IO.Path.DirectorySeparatorChar ? TrackUriType.AbsolutePath : TrackUriType.RelativePath,

which is clearly incorrect.

Now I'll post a patch.

Created attachment 116777 [details] [review]
Proposed patch, v2, tested and working (1 liner!)

Very easy to review (1 liner)

Seems to work for me, but could you describe some steps to reproduce this bug before the patch? I haven't spotted it, so I'm not sure how to review the patch.

I'm not sure, the simplest testcase I can think of (that reproduced the bug in my system is just):

- Have a file called "01 empire.mp3" (in case the name matters).
- Have it in the path /home/user/var/anything (in case the path being different than /home/user/Music/ matters).
- Import the folder containing the file into the library.

It doesn't crash banshee, but shows the exception on the log. After the patch, the exception is gone.

Anyway, I don't consider the bug to need a really reproducible testcase, because after seeing the code, the problem is quite clear:
1. The uri is of type: "file:///home/user/...".
2. The algorithm tries to state if the uri is relative or not, depending on if the first character of the uri is "/". In this case it fails, obviously, so Banshee thinks it's relative.
3. Thinking it's relative, it tries to perform a Path.Combine operation, which results in something like:
/home/knocte/Music/file:/home/knocte/var/entrada/05%20Ooh%20La.mp3
4. Which will end-up raising a FileNotFoundException.

Created attachment 116822 [details] [review]
Applying this patch demonstrates the problem with a prettier stacktrace than the one mentioned in first reports

Just to demonstrate the issue better, if you apply this patch, you get this exception (the stacktrace demonstrates this is a cover art related problem):

[Warn  21:41:39.583] Caught an exception - Exception raising for demostrating the strack trace on the wrong behaviour. (in `Banshee.Services')
  at Banshee.Sources.PrimarySource.UriAndTypeToSafeUri (TrackUriType type, System.String uri_field) [0x00046] in /home/knocte/Documents/iDocs/Proyectos/Banshee/arbolSVN/trunk_bis/banshee/src/Core/Banshee.Services/Banshee.Sources/PrimarySource.cs:186 
  at Banshee.Sources.PrimarySource.UriToSafeUri (System.String uri_field) [0x0000d] in /home/knocte/Documents/iDocs/Proyectos/Banshee/arbolSVN/trunk_bis/banshee/src/Core/Banshee.Services/Banshee.Sources/PrimarySource.cs:171 
  at Banshee.CoverArt.CoverArtJob.Run () [0x000e2] in /home/knocte/Documents/iDocs/Proyectos/Banshee/arbolSVN/trunk_bis/banshee/src/Extensions/Banshee.CoverArt/Banshee.CoverArt/CoverArtJob.cs:136

I was able to reproduce this. You have to import tracks that are not under your Music Library directory, and for which you don't have any cover art (in particular in ~/.cache/album-art/).

The patch fixes the exception. I don't really like the fact that it create a new Uri object, but I don't see any other way to do the check (the Uri.IsWellFormedUriString statis method does a "new Uri" anyway).

Thanks for reviewing, can anyone commit for me? (I don't have a gnome svn account.)

Patches must be approved by one of the maintainers (Aaron or Gabriel) before they can be committed.
I'll be happy to commit your patch when it is OK'ed.

The other day I committed a fix to the embedded and filesystem cover art providers that fixed a bunch of similar warnings for me.  Can you svn up and see if you still have this problem?

Created attachment 118203 [details]
Console output with trunk

This is what I get now with trunk, I think it's still the same as before.

I wasn't able to reproduce the exceptions  with latest SVN, so Gabriel seems to have fixed it for me.

Michael, the exceptions I see in your log are related to the Rhapsody metadata provider, so I think it's a different issue.

But Andrés' patch still seems valid to me. The issue in the UriToSafeUri method is still here. To illustrate it , apply the following change and import a file that is outside of the "Music Library" directory. The track.Uri is then wrong.

--- src/Extensions/Banshee.CoverArt/Banshee.CoverArt/CoverArtJob.cs	(revision 4490)
+++ src/Extensions/Banshee.CoverArt/Banshee.CoverArt/CoverArtJob.cs	(working copy)
@@ -135,7 +135,7 @@
                             track.PrimarySource = ServiceManager.SourceManager.MusicLibrary;
                             track.Uri = track.PrimarySource.UriToSafeUri (reader.GetString (3));
                             track.AlbumId = Convert.ToInt32 (reader[0]);
-                            //Console.WriteLine ("have album {0}/{1} for track uri {2}", track.AlbumId, track.AlbumTitle, track.Uri);
+                            Log.DebugFormat ("have album {0}/{1} for track uri {2}", track.AlbumId, track.AlbumTitle, track.Uri);
 
                             Progress = (double) current / (double) total;
                             Status = String.Format (Catalog.GetString ("{0} - {1}"), track.ArtistName, track.AlbumTitle);

Created attachment 118394 [details] [review]
patch that replaces other checks with a System.Uri check

I've seen other places where the check is correct but a bit tricky because it uses RegularExpressions (the are a bit inefficient BTW), so here's another related patch.

s/the are/they are/

I fixed this by getting the UriType out of the db in the CoverArt fetcher, and getting rid of the bad method in PrimarySource.  Thanks for investigating and tracking this down, guys.

Andres, please open a new bug for separate issues like your most recent patch.  Also, I'd prefer you keep the regex, but feel free to cache a compiled version of it.