FS#10101 - track skipping stops file buffering

Attached to Project: Rockbox
Opened by Jonathan Gordon (jdgordon) - Sunday, 05 April 2009, 23:02 GMT
Last edited by Thomas Martitz (kugel.) - Wednesday, 10 June 2009, 17:15 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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
This task depends upon

Closed by  Thomas Martitz (kugel.)
Wednesday, 10 June 2009, 17:15 GMT
Reason for closing:  Fixed
Additional comments about closing:  Committed the attached fix as of r21244.
Comment by Steve Bavin (pondlife) - Monday, 06 April 2009, 06:52 GMT
We definitely should fix this, or at least work out exactly why it's happening.
Comment by Thomas Martitz (kugel.) - Monday, 08 June 2009, 22:06 GMT
I too think this should be fixed.
Comment by Thomas Martitz (kugel.) - Tuesday, 09 June 2009, 10:35 GMT
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.
Comment by Jonathan Gordon (jdgordon) - Wednesday, 10 June 2009, 03:01 GMT
looks good from a quick glance.... Steve?
Comment by Martin Ritter (MartinR) - Wednesday, 10 June 2009, 06:59 GMT
This obviously fixes  FS#8999  as well.
Comment by Thomas Martitz (kugel.) - Wednesday, 10 June 2009, 07:08 GMT
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 :)