Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To
    nicolas_p
  • Operating System All players
  • Severity High
  • Priority Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by lostlogic - 2007-11-05
Last edited by nicolas_p - 2007-11-26

FS#8092 - rebuffer_handle is hopelessly broken

rebuffer_handle for backwards seeks is hopelessly broken. it will only work in the very isolated case that there is no track after the playing track on buffer. Otherwise it will end up with a short allocation as it tries to rebuffer the new file from earlier than it was originally buffered.

I tried various solutions but none look good. First I tried to move it earlier on the buffer to make space. This doesn’t work because if the buffer is filling we could be mid-read and could then put the current track back on space that is about to get overwritten. Even if the buffer is not filling, if there are any tracks on buffer earlier than the playing track then it can’t safely move earlier.

My next solution was to return an error code which tells playback that it needs to do a full rebuffer. I have a patch with this proposed solution (as well as an associated but not equivalent fix to put the PRESEEK functionality back into the world and manage it from the playback side.

See attached patch, which breaks horribly and I don’t see why.

This FS is here for a tracker as either Nico or I get to fixing this for real.

Closed by  nicolas_p
2007-11-26 21:14
Reason for closing:  Fixed

I probably don’t understand the issue, but it seems that any solution should be internal to buffering and not involve playback. The need to rebuffer data in this manner could apply to any routine that uses buffering, no?

If it’s doable, just do a complete rebuffer in this case. It’s not often someone will rewind (or skip back?) before the start of buffered data, so not worth complicating the code to preserve later tracks.

Although …Like I said, I probably don’t understand the issue…. :)

A solution is to let the buffering code close a few handles to make room for the one that needs rebuffering. This isn’t possible currently because we have no way of notifying users that handles have been closed, but I’m working on an idea suggested by jhMikeS where the buffer_low_callback (or whatever it’s called) is generalised to be able to pass any message to the users. With such a callback, users could be informed that handles were closed to make room.

A full rebuffer is what happened before MoB, AFAIK, so that could be an acceptable fix until a better solution is found.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing