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

[Pierre-Marie Gandoin]

Hi,

I realized that the files I put online contained some special caracters
that are modified by tunes2pod and thus make the comparison harder. So I
replaced them with cleaner files.

Besides, I began to look for differences between files. All the
differences appears in the attributes : id, dbid_1, lastplay, lastskip,
playcount, played_flag and skipcount.

Best regards,

P-M. Gandoin 

On Fri, Nov 28, 2008 at 08:04:16PM +0100, Pierre-Marie Gandoin wrote:
> Sorry for replying late, I was a little busy yesterday.
> 
> You will find some files that could help you to understand the bug here :
> http://eidolon.univ-lyon2.fr/~pmgandoi/Misc/
> 
> The diff between GNUtunesDB.xml files is not so easy to do because of some
> kind of renumbering between the original file and the regenerated one.
> 
> Best regards,
> 
> P-M. Gandoin
> 
> On Thu, Nov 27, 2008 at 02:13:34PM +0100, H. Langos wrote:
> > 
> > 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
> > 
> > 
> > 
> > _______________________________________________
> > Bug-gnupod mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/bug-gnupod
> >