Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Iriver H300 series
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by PaulJam - 2006-05-20

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

Description:

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)

(application/octet-stream)    misc.cfg (3.3 KiB)
Closed by  nls
2006-10-05 16:08
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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing