FS#10039 - fast changing time indicators when pausing with fading on

Attached to Project: Rockbox
Opened by Johannes Linke (Jaykay) - Saturday, 21 March 2009, 20:50 GMT
Last edited by Frank Gevaerts (fg) - Tuesday, 15 December 2009, 13:35 GMT
Task Type Bugs
Category Themes
Status Unconfirmed   Reopened
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


to reproduce:

1. set playback settings-->fade on stop/pause to on.
2. play some music.
3. press the pause button to stop the music, and again to restart it. repeat that a few times, because this bug does not always occur.

you will notice that both "time-displays" sometimes change very to the previous second and then back to the normal one, e.g 3:32, then very short 3:31, and back to 3:32. the progressbar sometimes get smaller for a fraction of a second, too.

maybe i'll search for the revision which introduced this in the next few days
This task depends upon

Comment by Johannes Linke (Jaykay) - Wednesday, 25 March 2009, 18:06 GMT
i tested it in some previous revisions and found out that the wps "froze" in old revisions (i think about r17000) the oldest build which didnt freeze had this bug already.

tested with e200 + r20511
Comment by Johannes Linke (Jaykay) - Monday, 20 April 2009, 19:51 GMT
this works also with fading disabled, e.g. if you turn the scrollwheel very fast. maybe due to high cpu load? should i do a test with some cpu-intensive music, e.g. ape?
Comment by Boris Gjenero (dreamlayers) - Monday, 20 April 2009, 23:45 GMT
In my tests with r20753 on my 5G 30GB iPod, there is no need to pause, enable crossfading or be near a track boundary to see this. Rapidly changing volume (using the wheel) is sufficient to make the time change back and forth by 1 second.

It's harder to reproduce this in the 5G sim, but it can still be reproduced. There, it's easy to see what's going on. In codec_set_elapsed_callback() (in apps/playback.c), the "value" parameter is always increasing, but due to subtracting pcmbuf_get_latency(), thistrack_id3->elapsed goes backwards at regular intervals. Volume changes make the problem visible because they cause the WPS to update more often.
Comment by Jonathan Gordon (jdgordon) - Monday, 21 December 2009, 06:42 GMT
does this still happen?
Comment by Johannes Linke (Jaykay) - Monday, 21 December 2009, 10:51 GMT
yes. tested with an e200 and r24091
Comment by Andree Buschmann (Buschel) - Wednesday, 27 July 2011, 19:03 GMT
Still few times visible with r30210 on a 5.5G when fast changing the volume.