Rockbox

confirmed

Please report if this is still a problem with the latest builds.

Still a problem with 03/20/06 build (H3xx, ogg vorbis). Rewinding or attempting to skip to the beginning of the same song during last few seconds results in unpredictable behavior. The wps track information will either freeze or become out of sync with the song that is actually playing (e.g. playing track #4, but wps information for track #5 will be shown).

From  bug 2942  (which is technically a duplicate of this):

If you stop the track in the last 3 seconds (during
gapless transition to the next track) and the device
shuts down - when switching back on the resume function
gets stuck and you must skip to the next track manually.

brian.a.martin@gmail.com

Both of these are because technically the _decoder_ has moved on to the next song by the time the stop or rewind event is received, so the playback code gets confused as to which track it should be playing / resuming / rewinding.

It won't be elegant, but I'll 'invent' a way to handle this for 3.0. It'll be better post 3.0 when I put metadata on the buffer.

on the iPod Video I can reproduce this same bug by rewinding long distances no matter how far into a track the player is. During the last few seconds of a track it will begin playing the next track, but if I start rewinding BEFORE that point it will play tracks that come BEFORE the correct track in the playlist (and sometimes SEVERAL tracks before).

yup, both ogg and mp3 files do this.

Still there. H120. Mp3, Wav & Aiff. Very disturbing.

This is a test comment to try out the new Flyspray version.

Prehaps if you DIDN't rewind the song and reselect it or, better yet, listen to the whole album. Dose this matter as much as other commits?

All bugs matter, especially those affecting the fundamental use of a DAP.

DAP's Play music. Rewinding at the END of a song Dosent make sense. Now makimg the radio work on the H10 would affect the fundamental use of the player.

You are supposed to be able to rewind a song at any point. This is a genuine bug in the playback code and it should be fixed.

A bit different: if I try to rewind when only a few seconds of the current FLAC file are left, the progress bar move backwards... and jumps to the point where it was, just as if I never tried to rewind. I mention FLAC because it is the format I was using when noticed the problem. Difficult to reproduce this, though :(

Don't know if it's the same bug, but hitting 'previous track' towards the end also confuses playback. After hitting 'previous track', the _next_ track starts to play and the wps still shows the old track that was playing when you hit previous track. Hitting 'previous track' any number of times when this new track starts to play only restarts that track (instead of going to the previous track). Like mentioned above, going into file view & then 'now playing' fixes the problem...except if you didn't do that, you would have to hit next track (so that you are now @ track_you_wanted_to_start_from_the_beginning + 2) and then hit previous track twice.

I noticed the same bug (or if these are different, both bugs) on my sansa e250 with flac-files. r15510-071107

I think I know what is causing this bug from a coding point of view. Towards the end of the track, Rockbox will play the transition chunk, which is the end of the track currently being played and the start of the next track. The next track however is now registered as the current track, which means that when you rewind during the transition you start rewinding through the next track even though the current track is still being played. Hope this makes sense...

Yes, the problem is that there are actually 2 track transitions:
1) Internally to playback.c, when the codec moves from track A to track B.
2) Externally to playback.c, when the WPS moves from track A to track B.

The codec transition happens a few seconds before the WPS transition. If the user attempts a seek in this interval, horrible things happen!

All interfaces to playback.c need to refer only to the WPS transition, and corresponding track. I suspect the outputs are correct, but the inputs (seek position, in this case) are using the codec transition.