GNOME Bugzilla – Bug 570600
rhythmbox picks bad filenames for ipod
Last modified: 2018-05-24 14:02:10 UTC
http://svn.gnome.org/viewvc/rhythmbox/trunk/plugins/ipod/rb-ipod-source.c?revision=6128&view=markup#l1317 get_ipod_filename() chooses the name for the file that will go on the ipod in approximately this way: (0) start with a source filename (1) generate a random number from 0..99. call it 's' (2) stitch the following together: - iPodControl/Music/ - "F%02d" % (s,) - the first 27 characters of the original filename - the extension for the file (after transcoding) i name my music like this: artist - album - ## - title.flac consider the album "one beat" by the artist "sleater-kinney". sleater-kinney - one beat - 01 - one beat.flac sleater-kinney - one beat - 02 - faraway.flac sleater-kinney - one beat - 03 - oh!.flac sleater-kinney - one beat - 04 - the remainder.flac sleater-kinney - one beat - 05 - light rail coyote.flac sleater-kinney - one beat - 06 - step aside.flac sleater-kinney - one beat - 07 - combat rock.flac sleater-kinney - one beat - 08 - o₂.flac sleater-kinney - one beat - 09 - funeral song.flac sleater-kinney - one beat - 10 - prisstina.flac sleater-kinney - one beat - 11 - hollywood ending.flac sleater-kinney - one beat - 12 - sympathy.flac these will get copied to the ipod like: f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 f**/sleater-kinney - one beat -.mp3 for random ** values between 00 and 99. of course, due to the birthday paradox, it doesn't take very many tracks on an album before there is a very good chance of a collision occuring (one would expect a 50% chance of collision at ~10 tracks). there are essentially three possible fixes: 1) if we get a collision then try another random number 2) use a different method, like the end of the filename instead of the start 3) both #1 has the drawback that if you have a very large number of files that start with the same string then you might easily get rhythmbox stuck in a loop. #2 has the drawback that maybe the end of the filename isn't unique enough either (although in my case, this is where the titles are so it would be a vast improvement)
current behaviour, by the way, is that rhythmbox asks you if you want to replace the existing file, so you have to choose which song you like more. this is made more frustrating by the fact that you can't guess which one you're replacing with which! once you turn the ipod on, the end result is that you get one of your tracks that, when played, actually plays the sound from some other track on the album.
Good detective work, I have been aware of that bug for a few months but haven't come around fixing it just yet. My current plan is to just use random filenames (as itunes, gtkpod do) like libgpodXXXXX which makes the whole problem easier to handle. Before doing that, I want to add a way to export songs from the ipod with good looking filenames, either with an "import to library" menu entry or using the xdirectsave protocol (or both :). I just need to get around doing that :-/
If you copy from the ipod to the library within rhythmbox, the library constructs the target filename, so it doesn't matter what the filenames are on the device. xdirectsave would help for drag and drop to external apps, though.
Ah, great to know, I thought I'd have to build the destination filename in the library by hand. I guess this makes an "Import to library" command trivial to implement.
there is a bug about that on https://bugs.launchpad.net/bugs/312902
(In reply to comment #4) > I guess this makes an "Import to library" command trivial to implement. > This is bug #576014
Created attachment 131908 [details] [review] Adds random suffix to truncated iPod filenames Solution proposed for Ubuntu bug 312902 - not a perfect solution but will cover most users cases. It adds a '~XX' (XX=random letters) suffix to an iPod filename when it is truncated - this keeps the files with readable names but reduces the chance of collision. Only two characters is not really enough (I calculate makes the chance of collision for 10 tracks at about 1/1000) but will work for most users. I also fixed the extension detection (only works for Unix though) - previously it looked for the first '.' - this would break for track files like this: artist.album.track1.mp3 artist.album.track2.mp3 artist.album.track3.mp3 ... (contrived but someone may try this) I initially looked at chosing a random directory name ('Fnn/') then incrementing n to stop the random chance of colliding 5 times - but then realised the file names are chosen before all tracks are written.
strrchr looks for the last occurrence of '.' in the string, so it works in the case you describe. And I don't think you have dots in the directory part of the filename, so the old code should be fine. The other part of the patch could go in as a stop gap measure.
Created attachment 131944 [details] [review] Revised patch What about this revised (untested) version?
Sorry, missed the extra 'r' - and I need to brush up on my C string manipulation :) Have tested your patch and updated the Ubuntu bug with it.
If no one's going to work on using more reliably unique filenames ("libgpodXXXXXX" or similar) soon, then this looks like a reasonable temporary fix. (In reply to comment #8) > I initially looked at chosing a random directory name ('Fnn/') then > incrementing n to stop the random chance of colliding 5 times - but then > realised the file names are chosen before all tracks are written. I hadn't realised this would be a problem, but it looks like something we should fix. If I ever get back to working on my grand total solution to all track transfer problems (tm) I'll have to remember to do something about this.
I committed the patch to svn. Fwiw, it seems the iQuiz iPod game expects 4 char filenames so even libgpodXXXXX might not work :(
Bug 442137 is about using XXXX.mp3, so I guess we can close this one.
This patch is inadequate. I have 120 files named "1.mp3" (really! and it's a rational organization too!) and the current scheme is entirely inadequate. What about using real uniquification, instead of just adding more and more random bits? At the very list, add the random bits every time, and not just on truncations.
Yep, reopening that bug since I had issues with duplicate filenames over the weekend while transferring thousands of tracks to my new ipod
*** Bug 612145 has been marked as a duplicate of this bug. ***
*** Bug 411634 has been marked as a duplicate of this bug. ***
Hy! My songs named only by "tracknumber - title.mp3" and many of them have a "01 - Intro.mp3" song, so when I tryed to transfer my entire library on my iPod I got many "Do you want to overwrite 01 - Intro.mp3" Because sometimes they got the same random number for the F** directory and two different songs tryed to use the same filename :(
is this fixed?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/695.