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
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
|
Detailsstart 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.
Wednesday, 10 June 2009, 17:15 GMT
Reason for closing: Fixed
Additional comments about closing: Committed the attached fix as of r21244.
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.
FS#8999as well.FS#8999yesterday to see if it's fixed as well (which I strongly suspected), however I couldn't recall the number :)