Rockbox

lostlogic reported the same problem still happening on IRC - around 3am on 30th October 2007.

03.16.22 # <lostlogic> Nico_P: (for when you return, if you read logs) I think that any bufopen or bufalloc should take an argument of a callback to say to whomever buffered this item that it is being freed and that if the caller needs the resource again they need to rebuffer it.
03.17.16 # <lostlogic> Nico_P: I’m trying to get a logfdump of it happening on target but I _think_ that what’s happening when playback stops is that the buffer_low_callback is somehow not being treated when the buffer is low but fully allocated.
… 03.47.09 # <karashata> hmm, I’m getting some issues playing back a FLAC file… 03.47.44 # <karashata> it’s stopping playback quite frequently and the only way to get it to continue is to fully stop it and resume playback again
03.47.58 Part Roan
03.51.33 # <karashata> and apparently that’s not even working very well
03.52.50 # <lostlogic> karashata: interesting, is the file larger than the buffer?
03.53.19 # <karashata> I don’t know, it could be
… 03.55.34 # <karashata> the file’s 17 MB 03.55.38 Quit mrmacky (”ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]”)
03.55.45 # <karashata> what’s the buffer size?
03.55.59 # <Llorean> 29 or so
03.56.07 # <karashata> hmm… 03.56.08 # <Llorean> Unless you’re on an X5, M5, or Archos.
03.56.18 # <karashata> nope, H10 20 GB 03.57.35 # <lostlogic> karashata: ahhh, that actually explains the bug I’m seeing too. I thought that it was a problem with the allocated buffer space being full and therefor not being able to fill, but it’s actually a problem that if the compressed filebuffer ever runs low enough that the codec can’t satisfy a request then it stops.
03.57.48 # <lostlogic> Nico_P: new theory above.
… 03.58.43 # <lostlogic> karashata: normally it’s not a problem because the buffer should start filling at the watermark, not when the codec is actually out of data to chew on
03.58.51 # <karashata> the file’s playing back after shutting the player down and rebooting
03.58.54 # <lostlogic> karashata: but on flacs or occasionally when it starts a buffer fill run it will
03.58.55 # <Llorean> lostlogic: Ah, yeah high bitrate flacs used to starve the compressed buffer long enough for the PCM buffer to empty even pre-MOB
03.58.58 # <Llorean> Though playback wouldn’t stop
…

I’ve attached a logf lostlogic made when this happens.

   logf.txt (55.3 KiB)

Hi,

i’m not sure if it helps finding the cause for this bug, but i get this behaviour too for files that are larger than the buffer and i noticed something interesting about the position in the song, where it stops:

when i start the file from the beginning it always stops after it has played aproximately
filesize % buffersize
bytes of the file. So to me it looks as if the file “ends” at the correct position on the buffer, but just one or more rebuffers too early.

This should hopefully have been fixed by r15374. Can you confirm?

I wasn’t able to reproduce the problem with r15374 anymore.

Seems to be fine now.