- Status New
- Percent Complete
- Task Type Bugs
- Category Music playback
- Assigned To No-one
- Operating System SW-codec
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#8029 - Selecting a buffered track in the current playlist forces a rebuffer
Recipe:
1) Play an album. Wait until buffering completes.
2) Skip from track 1 to track 2. No buffering occurs.
3) Skip from track 2 to track 1. No buffering occurs.
4) In the playlist viewer, select track 2. Rebuffering occurs, even though the track is buffered.
The same problem occurs in the opposite direction (e.g. after step 2, it should be possible to switch to track 1 using the playlist viewer without rebuffering).
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
This isn't a bug introduced by MoB. It's due to the fact that selecting a track in the playlist calls audio_play(), which stops and restarts playback. Fixing this isn't trivial and (IMHO) falls into the scope of a big rewrite of playback.c.
I know this isn't a new problem, but with the new buffering code it should be easier to improve. Better if it could be handled entirely within buffering.c; there's no reason to clear the buffer just because playback is restarted, and if playback then requests a file that's still buffered then there shouldbe no need for a disk read…
I had always wondered about this, since the very beginning…. Nice to hear you explain something about it Nicolas.
Is this still a bug? If so then in theory could selecting a track in the playlist be implemented as a bunch of track-skipping operations, if those do not cause a rebuffer, to avoid any deep rewriting of playback.c?
This is still a bug.
It's probably even simpler than track skipping - just don't stop and restart the playlist or don't flush the buffer so easily.
Really this should be handled transparently in buffering.c anyway.