GNOME Bugzilla – Bug 430931
Banshee won't add files to library (plays fine though)
Last modified: 2007-05-08 17:49:45 UTC
Hi, This is a bug that I filed with Ubuntu some time ago (version 0.11.0) -- the bug in Launchpad is https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/63588 . I downloaded the 0.12.1 tarball from banshee-project.org and built Banshee, and that version also displays the problem. The problem is that Banshee will not add certain files to the library. Curiously enough, if you open these files using the "Open Location" option, it is possible to play the files (and Banshee even gets the correct metadata information). Most of the files I have this problem with are ones that I encoded myself with faac. They use MP4 style metadata tags (not id3). I am not sure if it is only these files that have the problem, or if there are some other ones too, but as it stands such files represent a large portion of my library, which makes Banshee unusable. I will follow up this bug report with an attachment of an audio file that illustrates the problem.
I tried to attach the audio file, but it was rejected by bugzilla on the basis of being too large. You can download the file on the Launchpad bug page (direct link is http://librarian.launchpad.net/4638347/01%20-%20Michael%20Rains.mp4 ). The file itself was created with faac from a FLAC source file (I believe I added all the metadata using the command line faac options), and was originally released under a CC license, so there shouldn't be any distribution issues. If you need any more files illustrating the problem just send me an email.
I have experienced this same bug. However, it was while importing MP3 files, not MP4 files. Like the poster above... 1. The files in question play when opened through "Open Location", but they are not added to the library. 2. When I try to import them through "Import Music", the following error appears for every song that fails: Message: Argument is out of range. Parameter name: index I obtained the MP3 files from these locations (they're under the Creative Commons license). Maybe it is notable that all the music from this album won't import, but will play: http://www.8bitpeoples.com/_MP3/8bp071-01-virt-incident_01.mp3 http://www.8bitpeoples.com/_MP3/8bp071-02-virt-survivors.mp3 http://www.8bitpeoples.com/_MP3/8bp071-03-virt-bedtime_story.mp3 http://www.8bitpeoples.com/_MP3/8bp071-04-virt-night_and_day.mp3 http://www.8bitpeoples.com/_MP3/8bp071-05-virt-choppastyle.mp3 http://www.8bitpeoples.com/_MP3/8bp071-06-virt-thrash.mp3 http://www.8bitpeoples.com/_MP3/8bp071-07-virt-across_rooftops.mp3 http://www.8bitpeoples.com/_MP3/8bp071-08-virt-scorched_sands.mp3 http://www.8bitpeoples.com/_MP3/8bp071-09-virt-visitor.mp3 http://www.8bitpeoples.com/_MP3/8bp071-10-virt-try.mp3 http://www.8bitpeoples.com/_MP3/8bp071-11-samuel_ascher-weiss-hes_a_radical_rat.mp3 And here is another song which suffers again from the same problem (also Creative Commons): http://www.shemusic.org/music/void/she%20-%20believe.mp3
It's interesting that you get an error message upon importing songs. In my case if I try to import the folder containing all of the songs on the album, the import progress bar in the lower left flashes for a second as if it is importing songs, and then immediately disappears. There are no import errors shown whatsoever. I tried launch Banshee from the command line to see if it would print any messages to the terminal, but didn't have any success. The only text that is displayed to the terminal when I try to import the folder containing the songs for the album is this: Setting IO Backend to Banshee.IO.Unix.IOConfig (unix) Importing timer stopped: 00:00:00.1485930 This actually isn't that interesting, since this is basically the same output I would get from importing an album with music that Banshee will add to the library. If I try to import the same folder again, the import progress bar doesn't seem to flash on at all, and the importing timer takes significantly less time, indicating that it must have cached the importing of that folder or something (which I presume is normal). Again, the odd things for me are that if I play the songs using "Open Location" they play fine and in fact all of the metadata for the songs is displayed correctly. If I try to import the folder containing the songs, none of the songs are added to the library, and there are no import errors at all.
I can confirm this bug here... Brian, any idea what could cause this?
These are two different bugs though... the first one (the mp4 file) is caused by shared-mime-info detecting this file as video/mp4 instead of audio/mp4 and thus it's ignored by banshee. This is not a banshee bug. The second bug (the mp3 files) is a banshee (or better taglib-sharp) bug...
The mp4 file bug is now at https://bugs.freedesktop.org/show_bug.cgi?id=10830
The problem with the MP3's is a few problems with ByteVector.FromString and ByteVector.FromStrings with UTF16. I'm working on it now.
Created attachment 87475 [details] [review] Patch for MP3 Problem This should fix everything. The changes should appear in svn://anonsvn.mono-project.com/source/tags/taglib-sharp-1-1-final/src/TagLib I would highly recommend Banshee move to this repository instead of svn://anonsvn.mono-project.com/source/tags/taglib-sharp-banshee-0.11.7/src/TagLib as it contains many bug fixes.
Only that this version doesn't build at all: ./TagLib/Ogg/Vorbis/File.cs(42,15): error CS0246: The type or namespace name `AudioProperties' could not be found. Are you missing a using directive or an assembly reference?
And ./TagLib/Ogg/Flac/File.cs(49,63): error CS1501: No overload for method `TagLib.Ogg.File' takes `1' arguments ./TagLib/Ogg/Vorbis/File.cs(50,63): error CS1501: No overload for method `TagLib.Ogg.File' takes `1' arguments After changing AudioProperties to Properties.
Oops. Must have tagged the wrong revision. I'll look into this.
Ok... any news with getting that branch fixed? :)
This might be caused by banshee just using $(srcdir)/TagLib/*.cs \ $(srcdir)/TagLib/*/*.cs \ $(srcdir)/TagLib/*/*/*.cs as sources. So if you have any stale files flying around there this would be the reason why things break.
Whatever, the bug is fixed in taglib-sharp trunk... not sure what to do about this bugreport then as it's not fixed in banshee yet but would be by bug #436743.
I've updated Banshee trunk to pull in taglib-sharp trunk again now that we're back to unstable work on the new series. Sebastian's patch to update Banshee to use the new API in the trunk taglib-sharp is now committed as well (bug #436743). Going to mark this FIXED.