FS#12043 - Resume error at the end of a track

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Monday, 04 April 2011, 22:09 GMT
Last edited by Andree Buschmann (Buschel) - Wednesday, 06 April 2011, 19:12 GMT
Task Type Bugs
Category Playlists
Status Closed
Assigned To Andree Buschmann (Buschel)
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.8
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


A bug report in the forums states that resuming does not work as intended when resuming to the last seconds of a track. Details can be found here:,27655.0.html

Description by poster: "What you need is at least two successive tracks in a playlist, we'll call them track1 and track2, with playtime(track2) > playtime(track1) (preferably at least a 10..20% difference). Then stop playback within about the last 2 or 3 seconds of track1, e.g. by a short press of the Power button (you don't even need to power down). Hit the Home button and resume playback. You should find that you are well into track2 now.[...]"

Analysis: As assumed the resume issue occurs if you pause playback during a small time window. This window begins when audio_check_new_track() is called and ends when the new track is starting to play. Reason for the issue is that audio_check_new_track() calls playlist_next() which instantly increases the playlist index. The playlist index itself is used to save the resume position. Result: Rockbox will resume the previewed (next) track at the time position of the correct track. The time window has a duration 3 seconds (1 second for low memory targets). This is set in get_next_required_pcmbuf_size().[...]

The attached patch describes a possible solution. It uses mp3entry's "index" to set the resume position. This "index" is set after the playback of the new track has started.
This task depends upon

Closed by  Andree Buschmann (Buschel)
Wednesday, 06 April 2011, 19:12 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with r29682.
Comment by Michael Sevakis (MikeS) - Tuesday, 05 April 2011, 04:42 GMT
My rewrite will kill most of these sort of issues since the playlist isn't pre-advanced unless there is a new playlist. It still would fail this at the playlist boundaries but there's a reliable indicator that the auto skip is particularly for a playlist change (playlist can't peek into the next song in that case which should be fixed). If it's that important I'll incorporate a compatible fix (but the patch is huuuuge now already [but I said to myself I wouldn't be happy if it were less than 500KB of .diff and it's only 378KB] ).