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

Just read this back, and realised I had attached the wrong patch file,
which has an additional line in the wrong place :-(

The added line which says
queue_post(&mpeg_queue, MPEG_NEED_DATA, 0);

needs to be added to the first branch of the if (len < 0) line, after
the DEBUGF() line, not in the later branch as posted. Basically, if we
get read() < 0, we need to queue another request for mpeg data.

Sorry for the confusion!

Mike Holden

Mike Holden said:
> Re this bug:
> http://sourceforge.net/tracker/index.php?func=detail&aid=622799&group_id=44306&atid=439118
> concerning rockbox lockups during playback, especially when on the
> move.
>
> This is a problem I have been suffering from since the FM code became
> stable enough to use on a daily basis. Rockbox is solid when the unit
> is on a table, but when used on the move (walking, with the unit in a
> pocket), I get this problem a lot with Rockbox, even though the
> original Archos firmware is pretty solid in this respect.
>
> I have been looking at this, and think I have found the solution,
> although since it is an intermittent problem, and not reproducible at
> will, I can't be certain!
>
> Basically, I think we are too pessimistic if we get an error reading
> the next chunk of an mp3 file. We do a read(), and if the status is <
> 0, we basically give up immediately, even though the error is most
> likely due to disk skipping. If we have got this far, we can be sure
> there is no serious disk problem! I attach a patch for firmware/mpeg.c
> which basically treats read() < 0 as a flag to queue another disk read
> to try again. This should repeat until the anti-skip buffer is
> emptied. It could be argued that the anti-skip buffer should be able
> to be bigger than 7 seconds, but that is a separate issue.
>
> I have given the new build a good thrashing with a brisk walk round
> the village a few times, with no lockups in around an hour of use -
> who said software development was unhealthy! Normally I would expect
> to get a lockup within 10 or 15 minutes with a regular build of
> Rockbox.
>
> I wanted to submit this patch to the list for discussion, since
> reading mp3 files is pretty fundamental to Rockbox, and I am fairly
> new round here! I also wondered whether putting a short sleep() in the
> code if read() returns < 0, to give the hardware a bit of time to
> recover after a skip.
>
> Mike Holden
Received on 2003-02-26