Re: [Bug-gnupod] mktunes: Same settings & version, different databases

[H. Langos]

Hi Nonu!

On Fri, Oct 15, 2010 at 10:00:51PM +0100, Nuno J. Silva wrote:
> 
> address@hidden (Nuno J. Silva) writes:
> 
> > As far as I can tell, _Pretender (in Hash58.pm, the file I've been
> > looking at), writes at different places: in the computer which generates
> > the good db, it writes at the specified offsets, in the other, it
> > appends some values to the end of the file instead of doing it at the
> > given offset (but it might be doing some writes on the right place).
> >
> > Strange enough, I've been using the debug technique known as
> > debug-by-printf and it seems the offsets are okay...
> >
> > I'll dive deeper into this and then I'll say what's going on (I hope I
> > can find that out).
> 
> I found it out: it is seek() who is behaving differently: on one
> computer (the one on which mktunes.pl works fine), it reacts as
> expected, it actually seeks, while on the other after doing a syswrite,
> seeking has no effect and a future syswrite writes to the end of the
> file.
> 
> As the perl documentation for seek ($ perldoc -f seek) says seek
> shouldn't be used with sysread/write, I changed all the calls to seek so
> that sysseek is used instead.
> 
> (The docs also say sysseek doesn't mix well with other non-sys*
> functions, like read and write - I checked and those are not used in
> Hash58, so I suppose that's not a problem.)

Great debug work!
Thank you very much for investigating the issue and solving it.

Are the perl versions the same on both computer?

If you want to know wether to stay with the sys* functions or to take the
non-sys* functions I guess that depends on wether there is anything else 
besides sysread and syswrite to that file handle. The perlfunc man page
says that "print" is also in the same class of functions as "read" "write"
and (<>). Hash58.pm seems pretty straight forward. Go for the sys*
functions.

But there are other modules that operate on the iTunesDB and iTunesSD. I'd
be very greatful if you could check iTunes.pm and Mktunes.pm for mixing of
those function groups.

a simple "rgrep sysseek *" finds stuff like this:
src/tunes2pod.pl:       while(<ITUNES>) {}; sysseek(ITUNES,0,0); # the iPod is 
a sloooow mass-storage device, slurp it into the fs-cache

which is probably harmless, but revealing.

> I don't know if the developers want to change the code to use sysseek or
> if they prefer to keep seek instead. I'm attaching the patch I wrote,
> just in case someone wants to play with it.

"The developers" currently would be me and Richard. Adrian made me
co-maintainer since he doesn't have any time to maintain gnupod any more.
I'm currently pretty short on time myself. So if you are interested 
in becoming part of the team I'd be happy to tell you what I know about the
code ... em portugues se prefere, mas meu portugues e do brasil ;-)

Thanks for the patch! I'll incorporate it into the master branch!

> The patch is against GNUpod 0.99.8.

As 0.99.9 is around the corner I'll not prepare a 0.99.8.1 but rather make
this fix a part of 0.99.9

Once more thank you very much for solving that issue!
If you want to read up on whats been going on in GNUpod I'd recommend
the mail archive:
http://www.mail-archive.com/address@hidden/info.html

But feel free to ask

cheers
-henrik