Details

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

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.