- Status Closed
- Percent Complete
- Task Type Bugs
- Category Music playback
- Assigned To No-one
- Operating System SW-codec
- Severity Low
- Priority Very Low
- Reported Version Version 3.2
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#10101 - track skipping stops file buffering
start playback, wait for a few sec then skip to the next track. disk activity should stop.. check the buffering debug screen and userfl, alloc and real should all be way below where you would expect (i.e <50%).
the “problem” here looks like the skip track kills buffering. We need to decide if we want to fix this or not.
The biggest annoyance from this is that there will be no next track info until the next buffer… Usually when the buffer is filled the first track that didn’t fit gets its id3 buffered separately so there is almost always something to display. This doesn’t happen until the end of buffering, and because its getting cut short there is nothing loaded, so nothing to display.
apart from that its not really an issue, just makes an etxra buffering earlier than it should
2009-06-10 17:15
Reason for closing: Fixed
Additional comments about closing:
Committed the attached fix as of
r21244.
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
We definitely should fix this, or at least work out exactly why it’s happening.
I too think this should be fixed.
This seems to fix it (for me at least).
What happened: audio_skip causes ci.new_track to be incremented. However, audio_fill_file_buffer() used ci.new_track as a return criteria. I simply removed that criteria as long as the buffer is filling.
BTW: It really is an issue, since it also doesn’t stop boosting (and maybe the disk doesn’t spin down too then?) when this bug occurs.
looks good from a quick glance…. Steve?
This obviously fixes
FS#8999as well.Great, I was searching for
FS#8999yesterday to see if it’s fixed as well (which I strongly suspected), however I couldn’t recall the number :)