[Fixed] Resume position sometimes incorrect

[keyb_gr]

(As a PS to my last thread, Buschel's latest patch gave me a chuckle - only recently did I retag a track from +0.00 dB to +0.01 dB to work around the issue it addresses. Some classical-heads are likely to appreciate the change.)

Here's another problem, this time one that I have encountered in Rockbox for as long as I'm using it on a ClipV2 and now a Clip+:

I have a habit of stopping playback in the last few seconds of a track. If I then turn off the player, it happens that playback resumes a good way into the next track.

My (layman's) explanation: At this point, the next track has already been loaded (which it needs to for gapless playback to work), and resume mistakenly saves the playback position of the current track plus the file name of the next one.

FWIW, pretty much all the files on the player are -V 6 to -V 4 MP3s.

So, any comments from those in the know (or code, for that matter)? Is it really like I think it is?

[saratoga]

Pausing in the last few seconds of a track and then rebooting resumes at the correct position for me on my Clip+.  Could you be more specific about the steps needed to reproduce this problem?

[keyb_gr]

OK, I'll give it a shot:

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.

I'm currently on build 29668. Other features I'm using: scrobbler, replaygain (track gain when shuffling), dithering.

[Buschel]

The issue can be reproduced as described by keyb_gr.

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().

Edit: I have created a bug report and a patch that solves this issue (http://www.rockbox.org/tracker/task/12043). The patch will need some reviewing now

[Buschel]

Fixed on Trunk with r29682.

[keyb_gr]

r29685 seemed to work fine already, but since I saw that a regression resulting from the patch had to be fixed, r29693 it is for now. Thumbs up!

I have had no stability issues at all with recent builds btw. Even 3.7.1 would still hang once in a while.