[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Nuno J. Silva
Subject: Re: [Bug-gnupod] mktunes: Same settings & version, different databases
Date: Sat, 16 Oct 2010 19:05:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

"H. Langos" <address@hidden> writes:

> Hi Nonu!
> On Fri, Oct 15, 2010 at 10:00:51PM +0100, Nuno J. Silva wrote:
>> 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.

You're welcome :-)

> Are the perl versions the same on both computer?

Yes, both 5.8.8.

> 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'll see if I find something there.

>> 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 ;-)

I doubt I'll have much time in the next weeks, as you can see from how
long I waited to look at this issue again, so I doubt I'll be able to
help a lot.

(O português do brasil pode ser um bocado diferente, mas dá para
perceber bem. Nas diferenças o Google deve ajudar (espero eu) :-))

> 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 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

Nuno J. Silva

reply via email to

[Prev in Thread] Current Thread [Next in Thread]