GNOME Bugzilla – Bug 558526
Mime type is not set for tracks ripped from CD
Last modified: 2009-01-10 06:02:53 UTC
Please describe the problem: When I drag flac files or let banshee automatically manage my iPod most of my flac files are not being transcoded but merely copied. This makes the files unplayable on the iPod. The following is the only debug output with regards to the iPod transaction: [Debug 13:59:24.659] Found DAP support (Banshee.Dap.Ipod.IpodSource) for device David [Info 13:59:26.307] Sync calculated for Music Library: to add: 1045 items, remove 0 items; sync_src.cacheid = 152, to_add.cacheid = 160, to_remove.cacheid = 168 Sync calculated for Video Library: to add: 0 items, remove 0 items; sync_src.cacheid = 170, to_add.cacheid = 172, to_remove.cacheid = 180 Sync calculated for Podcasts: to add: 938 items, remove 0 items; Steps to reproduce: 1. insert ipod 2. drag flac files to iPod Actual results: flac files on iPod Expected results: mp3s on iPod transcoded from my flacs Does this happen every time? 99% (occasionally a file will be transcoded in a large transaction but the general rule is a 100% failure rate) Other information: da_DK.UTF-8, x86_64, Fedora 10. podsleuth-0.6.2-3.fc10.x86_64 banshee-1.3.3-1.fc10.x86_64 ipod-sharp-0.8.1-1.fc10.x86_64 mono-core-2.0.1-12.fc10.x86_64 gstreamer-0.10.21-1.fc10.x86_64 gstreamer-plugins-good-0.10.11-1.fc10.x86_64 gstreamer-plugins-bad-0.10.9-1.fc10.x86_64 gstreamer-plugins-ugly-0.10.9-1.fc10.x86_64
This is not a blocker.
David, do you have an .is_audio_player file on your iPod? And did this used to work in a past version?
No .is_audio_player file and yes this used to work.
As a point of reference I found a standard MTP device and for that, the automatic transcoding works just fine.
Interestingly I now see this when putting ogg files on the iPod: [Warn 16:30:29.450] Caught an exception - File format conversion support is not available (in `Banshee.Dap') at Banshee.Dap.DapSource.AddTrackAndIncrementCount (Banshee.Collection.Database.DatabaseTrackInfo track) [0x000ce] in /home/david/rpmbuild/BUILD/banshee-1-1.3.3/src/Dap/Banshee.Dap/Banshee.Dap/DapSource.cs:388 at Banshee.Sources.PrimarySource.AddTrackList (System.Object cached_list) [0x00091] in /home/david/rpmbuild/BUILD/banshee-1-1.3.3/src/Core/Banshee.Services/Banshee.Sources/PrimarySource.cs:603 All gstreamer packages are installed.
Okay, I restored the iPod to factory defaults (using the rockbox instruction page for doing this in Linux). No dice still didn't transcode correctly. So I wiped my banshee configuration and tried again. Voila, now files are correctly transcoded. So somewhere it must cache information on the specific player and the fact that it has once upon a time had rockbox installed along with a .is_audio_player file. This sadly makes backing out of a rockbox attempt a bit harder than in should be.
and now it started happening again, given that this is a fresh database+iPod (meaning no trace of rockbox anywhere in sight) the above is wrong. Something is causing this and as the iPod does not play flac this makes the iPod syncing entirely broken. The following can be seen when running with --debug [Warn 02:49:20.247] Caught an exception - Collection was modified;enumeration operation may not execute. (in `mscorlib') at System.Collections.Generic.List`1+Enumerator[System.Object].MoveNext () [0x00000] at Banshee.Dap.Ipod.IpodSource.LoadFromDevice (Boolean refresh) [0x000bb] in /builddir/build/BUILD/banshee-1-1.4.0.1/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:215 at Banshee.Dap.Ipod.IpodSource.LoadFromDevice () [0x00006] in /builddir/build/BUILD/banshee-1-1.4.0.1/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:148 at Banshee.Dap.DapSource.ThreadedLoadDeviceContents (System.Object state) [0x00022] in /builddir/build/BUILD/banshee-1-1.4.0.1/src/Dap/Banshee.Dap/Banshee.Dap/DapSource.cs:278
This happens on my ipod nano 4G as well
On a clean iPod Classic 120GB, I started a sync of all my music (mostly FLAC). The few MP3 files I had copied over as expected. Almost all FLAC files decided they should be transcoded except for one album. This one album got copied to the database as FLAC files. The one difference about this album that I can think of in comparison to all my other FLAC albums is that this is the /only/ album I ripped in Banshee directly to my library, all other albums were ripped with other software.
Idem on an ipod nano 4th gen 8gb. One tidbit of additional info: removing the affected albums from the banshee music library and rescanning collection to add them again, seems to fix the problem. So far this has worked for about 10 albums that got copied as flac: 1) delete albums from ipod (find them by selecting all tracks and flicking through the properties) 2) remove the albums from the banshee library 3) rescan 4) add again
It would appear that when you rip a CD as flac format the mimetype isnt being saved to the banshee database. Here is an flac stored in the database not ripped straight into banshee: 1|83|11|13|0|0||Franz Ferdinand/Franz Ferdinand/03 - Take Me Out.flac|1|taglib/flac|30046570|5|0|Take Me Out|take me out|3|11|0|236987|2004||||||0|22|1|1229034385|1224145980|1223431354|1229034385|7b6a9969f00f72e7ab30707edcdc5975|0|0|||1014|1227676801|1223431218 See the taglib/flac now a flac ripped in banshee: 1|2690|30|73|0|0|e7083a0a-311a-4eca-81fe-de24eb758f9b|Nine Inch Nails/Ghosts IIV (disc 1 Ghosts III)/01. 1 Ghosts I.flac|1||12409715|5|0|1 Ghosts I|1 ghosts i|1|18|1|168000|0||||||0|0|0|||1229373477|1229373477|a10ab138eb0740930bbcca4dc6a1532b|0|0|||0||0 Nothing where taglib/flac should be kept
Created attachment 124897 [details] [review] banshee-riptags.patch This patch fixes the problem. When a track is ripped from a CD it's TrackInfo is updated consistently with the rest of everything else.
Any chance someone can whip up a little script people can run to restore files with broken tags?
Created attachment 124902 [details] [review] banshee-riptags.patch Minor change. The track URI gets set by TrackInfoMerge regardless so I removed that. I also told it to prefer any information from the Track over that of the File if info for the Track exists.
Changing to importing (I believe this componont encompasses cd importing). Also adding Aaron to CC as he is the last person to have touched the file in question.
I have the same issue, and didn't import with banshee (I use EAC under wine to rip cd's). How do I check for this taglib/flac in those files?
*** Bug 566091 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > I have the same issue, and didn't import with banshee (I use EAC under wine to > rip cd's). > > How do I check for this taglib/flac in those files? You can make the "Mime Type" column visible in the track list : right-click on a column header and check the "Mime Type" box.
The patch fixes the issue for me : tracks ripped from a CD get a proper MIME type.
You can fix files you've already ripped by running this on the cmd line: sqlite3 ~/.config/banshee-1/banshee.db "update coretracks set mimetype='taglib/flac' where uri like '%.flac'"
Thanks for the patch, Nicholas, and thanks for the help, everybody else. I committed this to trunk in r4894.
I've reverted this commit. I saw this bug this morning, but was unable to comment in time. I have a problem using TagLib in this case simply to set the mime type. The mime metadata already exists on the ripper pipeline, so I would prefer to pull it from there to avoid performing a full TagLib read on the file for which we already have collected 100% of the metadata. I'll commit a variation of this fix which addresses the bug but uses GStreamer pipeline metadata to do so. It should also result in a more correct mime type (e.g. audio/flac, not taglib/flac).
Created attachment 126151 [details] [review] Complicated version using GStreamer This was a bit more than I had wanted, but this is the most correct way to get a valid mime type. It's proxied directly from the pipeline after the encoder. Please test!
Seemed to work for me with FLAC and OGG. However, with Waveform PCM and WavPack, it did not import into my library after the rip. When I manually imported everything looked fine.
That's likely a separate issue entirely. I've done a lot of testing with this patch and am satisfied enough to call it FIXED. It's been committed to trunk, will be in 1.4.2, and an update to openSUSE 11.1.