GNOME Bugzilla – Bug 599772
Rhythmbox corrupts ipod database for black 8GB nano iPod (model B754)
Last modified: 2010-03-02 14:25:56 UTC
Ref: https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/461639 If I transfer mp3 files to my iPod using Karmic's Rhythmbox and then eject it, the iPod reports it had no music on it. Rhythmbox and nautilus are able to see the files on the iPod, so it must be a database corruption problem. I tried rebuilding the database several times in Karmic by deleting the iPod's iTunes and Music folders, remounting it and reinitializing it when Rhythmbox asked, and finally recopying mp3 files to it using Rhythmbox, but after ejecting the iPod always reported it had no music files on it. I then rebooted into Jaunty and rebuilt the database followed the same procedure. This restored the iPod correctly so that it could see the mp3 files again. Version: Rhythmbox 0.12.5-0ubuntu4
What iPod model? Do you ahve an iPod_Control/Device/SysInfoExtended file on your ipod in Karmic?
Created attachment 146367 [details] iPod_Control/Device/SysInfoExtended The model is B754 (4th-generation 8 GB black iPod Nano) and the database version is 25.
Hmm, that's weird, these devices work ok with latest releases of everyhting as far as I know... :-/
Created attachment 146485 [details] iPod databases created by Rhythmbox in Jaunty and Karmic I've reconfirmed the problem. In the hope it helps in debugging this, I've attached the contents of the iTunes folder as created by both Jaunty and Karmic for an empty fresh install (zero songs) and after copying a single song. After copying the single song using Karmic, nautilus can see the music on the iPod but the iPod can't. The files are different sizes and have different contents. Karmic also created an additional iTunesSD file that Jaunty didn't create. I confirmed also the following: 1. Initialize the iPod using Jaunty, copy songs to it, and manually back up the iTunes and Music folders to another drive using nautilus. At this point after being ejected the iPod reports the correct number of songs. 2. Re-initialize the iPod (ie delete iTunes and Music then let Rythmbox do its thing) using Karmic and then copy songs to it. At this point after being ejected the iPod reports zero songs are on it (ie due to this bug); 3. Use nautilus to restore the iTunes and Music folders on the iPod. After being ejected, the iPod reports the correct number of songs. So there isn't a problem with files being copied, just an issue with how Rhythmbox in Karmic is writing the database. Another observation: when I copy a single song using Jaunty, the iPod says 'synchronizing' immediately. In Karmic, it usually does nothing (though Rhythmbox lists the song as copied) and if I then eject the iPod and replace it, Rhythmbox also thinks nothing was copied until I close and restart Rhythmbox.
It's missing a needed checksum at offset 0x58 in the karmic database which explains the symptoms you are seeing. If the iPod contains an iPod_Control/Device/SysInfoExtended file, I'm not sure why things would go wrong. Do you have an iPod_Control/Device/SysInfo file too? If so, can you paste its content? What is your iPod serial number? (last 3 digits, written on the back of the iPod)
The SysInfo file just says: ModelNumStr: B754 FirewireGuid: 000A27001D6C6254 and the last 3 digits are 3RO (I think).
And you don't have an old install of libgpod somewhere on your system? (install done by hand)
I've got: libgpod-common 0.7.2-1ubuntu1 libgpod4 0.7.2-1ubuntu1 Is that an old version? I don't think I've installed anything like that other than via apt-get.
I was thinking of packages you installed by hand, ldd /usr/lib/rhythmbox/plugins/ipod/libipod.so |grep gpod might tell. I'm asking because the libgpod version looks good, your ipod seems to have everything that is needed and yet it fails while it's working for everyone else. So I'm a bit at a loss to guess what's wrong.
The ldd command gives libgpod.so.4 => /usr/lib/libgpod.so.4 (0x00007f6e401c9000) which looks right. I'm running the amd64 bit version in case that matters. I tried reinstalling libgpod4 and libgpod-common and I tried running "ipod-read-sysinfo-extended /dev/sdb /media/IPOD/" and it failed until I ran it as sudo (Is that normal?) It rewrites the SysInfoExtended file, but the only immediately obvious difference is the rbsync data key. None of this has made any difference, though - it still corrupts the database when I try to change something using Rhythmbox.
I just tried a VirtualBox VM running Karmic (i386 version), and exactly the same thing happened - Rhythmbox on the VM corrupted the ipod database.
I successfully worked around the bug by linking the older version of libgpod.so.4 in Jaunty, ie libgpod.so.4.0.0 instead of libgpod.so.4.1.0. After rebooting I can now copy songs to the iPod in Rhythmbox without corrupting its database. So there must be a problem in libgpod, at least in Ubuntu's version of it (0.7.2-1ubuntu1).
I have no idea what can go wrong :-/ As far as I know, you're the only one with this issue. Maybe you can try adding a breakpoint in itdb_device_write_checksum and try to understand what's going on from there :-/
I cloned the git repository from gitorious.org/libgpod, but there isn't a configure script. Should I be using a different repository?
If you want to test something, use the svn version from sourceforge (http://sourceforge.net/projects/gtkpod). But I can't remember fixing a bug like that post 0.7.2 (this would have deserved a 0.7.4 release otherwise)
I confirmed the bug on another computer upgraded to the latest libgpod (ie in Ubuntu 9.10). The bug turned out to be in itdb_device.c#get_ipod_info_from_model_number: static const Itdb_IpodInfo * get_ipod_info_from_model_number (const char *model_number) { struct IpodModelTable *model_table; g_return_val_if_fail (model_number != NULL, NULL); model_table = get_model_table (); if(isalpha(model_number[0])) { model_number++; } return g_hash_table_lookup (model_table->model_number_hash, model_number); } libgpod is correctly reading the ipod model number ("B754") but the line "if(isalpha(model_number[0])) model_number++;" is making it jump over the "B", so it searches for "754" instead of "B754" in the model table. It doesn't find this and so returns a null info structure. Ultimately the ipod generation is set to 0 ('unknown'), which maps to 'no checksum', so no checksum is written. Commenting out "model_number++" fixes the problem. An aside - it took a while to figure out the problem, because something unset my gconf /apps/rhythmbox/plugins/ipod/active setting without telling me - and rhythmbox just said there were mime errors parsing the ipod files rather than saying it didn't have the right plugin to handle it.
Wow, indeed, I had totally forgotten about this specificity. Thanks for tracking it down.
Hmm, on the other hand, it should be using info from SysInfoExtended. I think you are supposed to put stuff like MB754 in SysInfo.
Something must be setting sysinfo_extended to null. itdb_device_read_sysinfo_extended sets it to a non null value, but it's null when itdb_device_get_ipod_info is called, which is why it looks up the sysinfo structure.
Hmm, shouldn't happen, and if it was really happening, I'm surprised it wasn't noticed earlier.
Can you try to set a watchpoint in gdb on sysinfoextended to try to figure out when the value is changed and paste the backtrace here?
Oops - sysinfo_extended isn't being set to null. The problem is the entry in ItdbSerialToModel serial_to_model_mapping for the last 3 digits of the serial number for the 8GB black nano is set to "3RO" instead of "3R0" (ie the character O instead of the number zero), so get_ipod_info_from_serial doesn't find it and returns null. Did that entry change from the previous version? So there are two problems: 1. It can't deduce the model number from the serial number because ItdbSerialToModel serial_to_model_mapping has 3RO instead of 3R0. 2. It fails to look up the model number from SysInfo because: if(isalpha(model_number[0])) model_number++; is making it look for "754" instead of "B754". If "MB754" is a valid identifier, perhaps the line should be this instead? if(isalpha(model_number[1])) model_number++;
(In reply to comment #22) > Oops - sysinfo_extended isn't being set to null. > > The problem is the entry in ItdbSerialToModel serial_to_model_mapping for the > last 3 digits of the serial number for the 8GB black nano is set to "3RO" > instead of "3R0" (ie the character O instead of the number zero), so > get_ipod_info_from_serial doesn't find it and returns null. Did that entry > change from the previous version? > > So there are two problems: > > 1. It can't deduce the model number from the serial number because > ItdbSerialToModel serial_to_model_mapping has 3RO instead of 3R0. Wow, good catch, thanks! I fixed it in libgpod git, so it should be ok in the next release. > > 2. It fails to look up the model number from SysInfo because: > > if(isalpha(model_number[0])) model_number++; > > is making it look for "754" instead of "B754". If "MB754" is a valid > identifier, perhaps the line should be this instead? > > if(isalpha(model_number[1])) model_number++; Can't exactly remember the rationales for this code, gtkpod puts a xB754 as the model info, old iPod models had a SysInfo file that they generated which contains Mxxxx with xxxx containing numbers, so this isalpha makes sense in this context. Nowadays, they indeed start with letters so this test is a bit weird, especially since the iPod no longer generates a SysInfo file with model info in it. But gtkpod depends on this model number, and it's a bit tricky to remove this dependency, so things stayed this way until now :-/ For what it's worth, I have some plans to rework the way libgpod decides what kind of hash to writ on what device.
I think we got to the bottom of this bug except that I can't really explain why it worked with libgpod 0.7.0 (the Jaunty one). Maybe it unconditionnally wrote hashes independantly of the iPod model it thought it was handling. I'll close this bug as FIXED even if this wasn't a rhythmbox/gnome bug per-se. Great job on the investigation, thanks a lot!
*** Bug 603356 has been marked as a duplicate of this bug. ***
My Ipod is having the same problem described- songs show up in RhythmBox but it says "no music" on the Ipod's screen when I unplug it from the computer. My serial number ends in 3RO; my Ipod_Control/Device/SysInfo file is blank. I upgraded libgpod to 0.7.90 but the problem still persists.
3RO or 3R0 ? How did you upgrade to libgpod 0.7.90? If you compiled from source, are you 100% positive rhythmbox uses the newly compiled libgpod (as opposed to the one installed by your distro)? Do you have an iPod_Control/Device/SysInfoExtended file?
@James: I tested 0.7.90 on Ubuntu 10.04 and it works fine. I've added a comment to https://bugs.launchpad.net/ubuntu/+source/libgpod/+bug/461639 for things to try - it is possible that Rhythmbox might still be using the old library.
I looked this morning and my songs were back on my iPod. I guess for some reason the fix took time to register! So, here's the trick to using libgpod 0.7.90 on ubuntu 9.10 1) Download the package from the lucid distribution: https://launchpad.net/ubuntu/lucid/i386/libgpod4 2) Attempt to install the .deb package. It will list dependencies that need to be satisfied. 3) Try to install the first package that it depends on. It can be found at https://launchpad.net/ubuntu/lucid/i386/packagename or click on the link from https://launchpad.net/ubuntu/lucid/i386/libgpod4 4) If that package requires a dependency, install that. Continue this process until all of the dependencies have been installed. 5) Do *not* add lucid/i386 as a repository.