Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?

[H. Langos]

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