Re: [Bug-gnupod] Problem over 32946 entries in GNUtunesDB.xml

[H. Langos]

On Wed, Nov 26, 2008 at 09:23:44PM +0100, Pierre-Marie Gandoin wrote:
> > you could also do a 
> > "ls -lsaR <mointpoint>  > /tmp/before" 
> > before you add that last critical file and a
> > "ls -lsaR <mointpoint>  > /tmp/after"
> > afterwards and then post the output of 
> > "diff -u /tmp/before /tmp/after"
> 
> First thing, the bug is not reproducible : after loading the 32946 version
> of GNUtunesDB.xml, then loading back the 32945 version, my iPod does not
> work any longer !
> 
> The new limit seems to be 32767. So I give you the diff file between a
> recursive ls with 32766 entries (iPod fine) and the same with 32767
> entries (iPod out of order).

Now that sounds more like a program limit to me. 2^15-2 and 2^15-1. 


In an iTunes forum I've found that there used to be a limit in iTunes:

> http://forums.appleinsider.com/showthread.php?t=65822
...
> It used to be 32,767 songs, which means that it was likely based on a 2Byte 
> integer (w/negatives).
> 
> If they made it 3 byte, it's 8,388,608 I think..


So, if the iTunes database file that gnupod produces is based on 
that old format, this would indeed explain the problem you see.

I am not very good at reading lots of pack/unpack perl code to see
if the stuff in iTunesDB.pm is correct. (Any volunteers?)

Instead I suggest doing the full circle GNUtunesDB.xml -> iTunedDB -> 
GNUtunesDB.xml
to see if anything gets lost along the way..

That means that you'd have to 
-backup your GNUtunesDB.xml file after adding some files more than the ipod 
accepts
-run mktunes
-move your GNUtunesDB.xml away or delete it
-run tunes2pod
-compare the resulting GNUtunesDB.xml with the one that you backed up.

That could tell us if there is something fundamentaly wrong with 
the iTunesDB that gnupod produces. 

> (I can also send you the two ls outputs
> tgzipped (800kB) if you want.)

That could help. But please send those to my address instead of the list.


cheers
-henrik