This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#5404 - Bug when queuing a song shortly before a tracktransition.
|
DetailsDescription:
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. Reproduction: (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) |
This task depends upon
Closed by Nils Wallménius (nls)
Thursday, 05 October 2006, 18:08 GMT+1
Reason for closing: Out of Date
Additional comments about closing: closed on request of the submitter
Thursday, 05 October 2006, 18:08 GMT+1
Reason for closing: Out of Date
Additional comments about closing: closed on request of the submitter
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.
With a current cvs build i can't reproduce this anymore. I think this task can be closed now.