Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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
Attached to Project: Rockbox
Opened by Jonathan Gordon - 2009-04-05
Last edited by Thomas Martitz - 2009-06-10

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

Closed by  Thomas Martitz
2009-06-10 17:15
Reason for closing:  Fixed
Additional comments about closing:  

Committed the attached fix as of r21244.

Steve Bavin commented on 2009-04-06 06:52

We definitely should fix this, or at least work out exactly why it’s happening.

Thomas Martitz commented on 2009-06-08 22:06

I too think this should be fixed.

Thomas Martitz commented on 2009-06-09 10:35

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.

Jonathan Gordon commented on 2009-06-10 03:01

looks good from a quick glance…. Steve?

Martin Ritter commented on 2009-06-10 06:59

This obviously fixes  FS#8999  as well.

Thomas Martitz commented on 2009-06-10 07:08

Great, I was searching for  FS#8999  yesterday to see if it’s fixed as well (which I strongly suspected), however I couldn’t recall the number :)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing