• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by starjasmine0516 - 2008-08-20
Last edited by Buschel - 2011-01-31

FS#9306 - resume for m4a isn't consistent

I use a sansa e200 to play m4a files. In the latest version of rockbox r18323M-080820, the bug still exists. I have a version that I use that does not exhibit this behaviour. it is: r17907-080701. Looking back at the daily builds, this lack of resume is still happening in r18043-080715. Steps to duplicate this problem. I have lengthy files. A test file can be found at I have found that it doesn’t matter whether I am at the beginning of a file or in the middle. It will sometimes resume perfectly when I press stop, power the play off, and then start it up and press play, while at others, it jumps to earlier in the file, or to another file altogether. Bookmarking that is created separately from resume playback’s list works fine. This faulty resume will also work if the player is stopped, and then play is pressed.

Closed by  Buschel
2011-01-31 15:19
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Fixed with r29175.

This is my configuration file that I use when this behaviour occurs.

fg commented on 2008-08-23 19:35

I can reproduce this on my c250 with default settings

Steps are:

* start playing
* seek to somewhere in the file, remember where
* pres Stop (long play on c200)
* shutdown the player
* start the player
* choose “resume playback”

Sometimes it will resume at another place in the file (I only had one file on the player). This seems to include times beyond the end of file, as sometimes the WPS shows a timestamp equal to the length of the file

This particular case isn’t a length problem at least, so I suspect a buffering issue (the fact that it apparently started happening after a change to buffering.c suggests as much). Could be triggered by a call to rebuffer_handle (caused by the initial seek by the codec)…

Oh, when the problem happens, the following buffering.c logf messages are printed:

buffering >| Q_RESET_HANDLE 2
buffering < Q_RESET_HANDLE 2
buffering >| Q_BUFFER_HANDLE 2
buffering < Q_BUFFER_HANDLE 2

(The handles are closed after this, and playback stops. Didn’t have any other logfs enabled at this point, so I don’t know why.)

Notice the ata_sleep() (which ought to be the call in fill_buffer), which is called due to buffer_handle being interrupted while processing the last handle. ata_sleep isn’t supposed to be called in this case, queue isn’t empty. Don’t know if this is related to the resume problem though. :)

The attached patch uses alac_seek() instead of the malfunctioning alac_seek_raw(). As alac_seek() is seeking to a desired sample position we need to calculate this position from the desired byte position. As a result the seek is much more precise than with current svn. In svn seeking is off by up to 6 minutes on a 1 hour file, with this patch seeking is off by max ~30 seconds on the same file.

If alac_seek_raw() really is the problem, wouldn’t it be better to fix that, since that seek should be more exact (and not based on estimates from the overall file bitrate)? Any ideas what the problem is?

The byte offset is very close to the desired position (actual file offset at stop, minus pcmbuf latency times bitrate).

Found the underlying bug in alac_seek_raw(), submitted with r29175.


Available keyboard shortcuts


Task Details

Task Editing