FS#5404 - Bug when queuing a song shortly before a tracktransition.

Attached to Project: Rockbox
Opened by PaulJam (PaulJam) - Saturday, 20 May 2006, 14:11 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Iriver H300 series
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



If i queue a song while the currently song is about to end then after queued song has finished playing the playback/WPS begins to act strange:
- The song that is displayed in the WPS does not reflect the currently playing song (e.g. WPS shows song c; song e is currently playing; playlist order is: ...b,c,d,e,f...)
- The timedisplay is continously counting up (e.g. 28:36/5:38).
- The playback is sometimes jumping to an other track in the middle of the current track.
- In the "View audio thread" menu the codec buffer has a negative number (e.g. codec: -16xxxxx/29084840).

When this happens Rockbox stays responsive (you can go to the menu, stop/resume playback etc.), but it continues to act strange even if you stop playback and play another playlist. The only way to achieve normal operation again is to rolo/restart Rockbox.


(Reset the configuration,)Load the attached config file*, set Shuffle to on and Repeat to off, start playing a m3u playlist, do a restart/rolo**, wait until the currently playing song is ~10-20 seconds towards the end then go to the filetree and queue an other song. When the queued song has finished playing, Rockbox should start to act funny.

*= The attached config file changes the language to german, so you might want to remove the line before using it.
**= I wasn't able to reproduce the bug until i did a rolo, so this bug might be related to DirectoryCache.

Music is .mp3 (mostly lame vbr)
I used a bleeding edge build from today with default font+wps (Ver. 060520-0737)
(application/octet-stream)    misc.cfg (3.3 KiB)
This task depends upon

Closed by  Nils Wallménius (nls)
Thursday, 05 October 2006, 16:08 GMT
Reason for closing:  Out of Date
Additional comments about closing:  closed on request of the submitter
Comment by PaulJam (PaulJam) - Sunday, 21 May 2006, 17:11 GMT
It seems as if this bug can also be triggered by moving items inside a dynamic playlist. It happened to me again today while/after i was rearranging a playlist with bleeding edge build Ver. 060521-0602.
Comment by PaulJam (PaulJam) - Thursday, 05 October 2006, 15:58 GMT
With a current cvs build i can't reproduce this anymore. I think this task can be closed now.