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 > > [email protected] > > http://lists.nongnu.org/mailman/listinfo/bug-gnupod > > _______________________________________________ Bug-gnupod mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-gnupod
