Rockbox

Tasklist

FS#8031 - Playback occasionally stops for no apparent reason

Attached to Project: Rockbox
Opened by Steve Bavin (pondlife) - Friday, 26 October 2007, 13:50 GMT
Last edited by Steve Bavin (pondlife) - Wednesday, 31 October 2007, 18:11 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

When playing a long playlist, occasionally playback stops and returns to the browser, just as if the STOP button had been pressed.

Pressing PLAY resumes at the point where it stopped.

Only seen on my H300 device, not on the simulator.

This always happens at the "decode end-of-track" - when I press PLAY it resumes and plays the last 2 or so seconds of the track. I suspect it happens only at the end of the last track in the buffer (so might be a result of my other problem where buffering stalls).
This task depends upon

Closed by  Steve Bavin (pondlife)
Wednesday, 31 October 2007, 18:11 GMT
Reason for closing:  Fixed
Comment by Steve Bavin (pondlife) - Tuesday, 30 October 2007, 09:27 GMT
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)
Comment by PaulJam (PaulJam) - Tuesday, 30 October 2007, 10:09 GMT
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.
Comment by Nicolas Pennequin (nicolas_p) - Tuesday, 30 October 2007, 17:29 GMT
This should hopefully have been fixed by r15374. Can you confirm?
Comment by PaulJam (PaulJam) - Tuesday, 30 October 2007, 17:59 GMT
I wasn't able to reproduce the problem with r15374 anymore.
Comment by Steve Bavin (pondlife) - Wednesday, 31 October 2007, 18:10 GMT
Seems to be fine now.

Loading...