On Fri, Jun 12, 2009 at 04:33:43PM +0200, Richard van den Berg wrote: > On Fri, June 12, 2009 15:21, Heinrich Langos wrote: > > I'd like to have a chain like this: ok -> ok -> broken > > Here is such a chain: > > http://richard.vdberg.org/gnupod/ok/11181/iTunesDB > http://richard.vdberg.org/gnupod/ok/11182/iTunesDB > http://richard.vdberg.org/gnupod/ok/11183/iTunesDB > http://richard.vdberg.org/gnupod/not_ok/11184/iTunesDB > > > Does this file have anything in its attributes that the files that you > > added successfully (until #11531) did not have? artwork maybe? > > Nope. In fact it breaks in the middle of an album. All those songs had > been added with the same gnupod_addsong.pl --artwork run.
I took a look at that chain (11182-11183-11184) using hexdump, sed and diff and i came pretty much the the same conclusion... Nothing obviously wrong. I wonder if it has anything to do with the IDs that playlist entries get. currently they are just sequentially continued after the last track ID. Thats why you get such a large number of tiny differences in the master playlist even when adding just one track. I don't have much time this weekend but maybe you could check out what happens if you start giving those IDs from the highest value and decrement with each entry. I doubt that this will solve the problem but it probably will help decrease the noise in the diffs. BTW thanks for the hint with vbindiff. I was using some mixture of hexdump, sed (to do linebreaks on "mh.." patterns) and diff. > > Could you try to add the SAME file over and over until you get a non > > working state? That would make hunt for an overflow in the internal > > structures even easier. (gnupod_addsong "-d" allow duplicates). > > I can do so tonight, but I was rather hoping of finding this bug without > having to wipe my iPod. Can't I just create a fake GNUtunesDB.xml with the > same file over and over again? I don't have the space left to add another > 11000 actual songs to my iPod (unless it's 1 kb or smaller). In my testing > so far I've just been manually editing GNUtunesDB.xml and running > mktunes.pl to generate a new iTunesDB. Skip that. I was hoping to find some pattern in the added file's characteristic but that will not help. > > Best way to get there is a binary search. > > That's exactly what I used last night. :-) 15 iterations for 30000 files > is the best you can do. Good to kown that we can talk more than just basic patterns. > > Did you try adding your collection with gtkpod? I assume it will be much > > faster as it is not written in perl. > > Nope. I really don't need a GUI and yet another local database to keep > track off. I want gnupod! :-) Me too, I was just wondering if their code produced an iTunesDB that wouldn't have the same problem. Then we could look for the differences. cheers -henrik _______________________________________________ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
