From: Mike Holden <rockbox_at_mikeholden.uklinux.net>
Date: Wed, 26 Feb 2003 09:27:55 -0000 (GMT)

Björn Stenberg said:
> Mike Holden wrote:
>> Basically, I think we are too pessimistic if we get an error reading
>> the next chunk of an mp3 file.
>
> I think this is merely symtomatic. Being too pessimistic in the mpeg
> code only means we skip to next file sooner than we have to.

It usually doesn't actually skip to the next file, just locks up.
Sometimes pressing "RIGHT" will skip to next track, sometimes not.

>
> Only the ata driver turns on (and off) the led, and thus that is where
> we hang if the led stays on forever. It is however indeed interesting
> that you can affect the problem by modifying the mpeg code.

Red LED isn't always on permanently when I get this problem, but
sometimes is!

>
> It's also good that you can repeat the problem fairly easily. I can
> never get this condition, despite rigorous abuse of my archos.

Maybe the FM is more susceptible hardware? It is still hit and miss
though. Sometimes it will lock after a few minutes, and sometimes an
hour or so. Usually I get a lock within 10-15 minutes though. Maybe it's
the way I walk ;-)

>
> I would like you to test this patch for the ata driver (without your
> mpeg modification). It adds a soft reset on disk error:
>

Will look at this, but it will be tonight before I am at my home
computer, and tomorrow before I get the chance to try it out. I still
think it would be good to try to not skip to the next track on a read
error though, as this is exactly what the anti-skip buffering is meant
to achieve. We should continue to play the current track to the end, if
possible.

When read() returns < 0, do we have access to errno? I don't know if
this is implemented in Rockbox, and have no access to code to look at
the moment!

Mike Holden
Received on 2003-02-26