After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 599772 - Rhythmbox corrupts ipod database for black 8GB nano iPod (model B754)
Rhythmbox corrupts ipod database for black 8GB nano iPod (model B754)
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: iPod
0.12.x
Other Linux
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 603356 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-10-27 14:50 UTC by rockorequin
Modified: 2010-03-02 14:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
iPod_Control/Device/SysInfoExtended (13.96 KB, text/plain)
2009-10-27 20:14 UTC, rockorequin
Details
iPod databases created by Rhythmbox in Jaunty and Karmic (1.11 KB, application/x-compressed-tar)
2009-10-29 08:47 UTC, rockorequin
Details

Description rockorequin 2009-10-27 14:50:00 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
Comment 1 Christophe Fergeau 2009-10-27 15:00:04 UTC
What iPod model? Do you ahve an iPod_Control/Device/SysInfoExtended file on your ipod in Karmic?
Comment 2 rockorequin 2009-10-27 20:14:49 UTC
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.
Comment 3 Christophe Fergeau 2009-10-28 00:14:39 UTC
Hmm, that's weird, these devices work ok with latest releases of everyhting as far as I know... :-/
Comment 4 rockorequin 2009-10-29 08:47:33 UTC
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.
Comment 5 Christophe Fergeau 2009-10-29 09:26:39 UTC
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)
Comment 6 rockorequin 2009-10-29 09:53:02 UTC
The SysInfo file just says:

ModelNumStr: B754
FirewireGuid: 000A27001D6C6254

and the last 3 digits are 3RO (I think).
Comment 7 Christophe Fergeau 2009-10-29 09:55:14 UTC
And you don't have an old install of libgpod somewhere on your system? (install done by hand)
Comment 8 rockorequin 2009-10-29 10:04:17 UTC
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.
Comment 9 Christophe Fergeau 2009-10-29 10:07:50 UTC
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.
Comment 10 rockorequin 2009-10-29 10:31:33 UTC
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.
Comment 11 rockorequin 2009-10-29 10:44:04 UTC
I just tried a VirtualBox VM running Karmic (i386 version), and exactly the same thing happened - Rhythmbox on the VM corrupted the ipod database.
Comment 12 rockorequin 2009-10-29 11:26:16 UTC
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).
Comment 13 Christophe Fergeau 2009-10-29 13:33:14 UTC
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 :-/
Comment 14 rockorequin 2009-10-29 23:15:50 UTC
I cloned the git repository from gitorious.org/libgpod, but there isn't a configure script. Should I be using a different repository?
Comment 15 Christophe Fergeau 2009-10-29 23:21:26 UTC
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)
Comment 16 rockorequin 2009-11-04 13:36:34 UTC
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.
Comment 17 Christophe Fergeau 2009-11-04 13:39:41 UTC
Wow, indeed, I had totally forgotten about this specificity. Thanks for tracking it down.
Comment 18 Christophe Fergeau 2009-11-04 13:41:52 UTC
Hmm, on the other hand, it should be using info from SysInfoExtended. I think you are supposed to put stuff like MB754 in SysInfo.
Comment 19 rockorequin 2009-11-04 14:20:19 UTC
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.
Comment 20 Christophe Fergeau 2009-11-04 14:24:19 UTC
Hmm, shouldn't happen, and if it was really happening, I'm surprised it wasn't noticed earlier.
Comment 21 Christophe Fergeau 2009-11-04 14:25:18 UTC
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?
Comment 22 rockorequin 2009-11-04 22:33:39 UTC
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++;
Comment 23 Christophe Fergeau 2009-11-04 23:06:47 UTC
(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.
Comment 24 Christophe Fergeau 2009-11-04 23:11:00 UTC
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!
Comment 25 Kalle Alm 2009-12-02 00:01:25 UTC
*** Bug 603356 has been marked as a duplicate of this bug. ***
Comment 26 James Sheldon 2010-03-01 17:31:06 UTC
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.
Comment 27 Christophe Fergeau 2010-03-01 20:47:22 UTC
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?
Comment 28 rockorequin 2010-03-02 03:28:07 UTC
@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.
Comment 29 James Sheldon 2010-03-02 14:25:56 UTC
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.