Warning: mysqli_real_connect(): Headers and client library minor version mismatch. Headers:50625 Library:50543 in /sites/rockbox.org/flyspray/adodb/drivers/adodb-mysqli.inc.php on line 108 FS#6205 : Delayed buffering of a new track after playback resume and rewind



FS#6205 - Delayed buffering of a new track after playback resume and rewind

Attached to Project: Rockbox
Opened by Václav Brožík (pabouk) - Wednesday, 18 October 2006, 15:49 GMT
Last edited by Steve Bavin (pondlife) - Thursday, 19 October 2006, 16:32 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To Brandon Low (lostlogic)
Operating System All players
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Brandon Low repaired the bug http://www.rockbox.org/tracker/task/5906 by this commit:
17 Oct 12:56 Brandon Low apps/playback.c 1.365 Remove fill_bytesleft, simplify some buffering code, fix  bug 5906 
Thank you, Brandon.

Unfortunately this repair revealed a new bug which could be observed under the same conditions. To be able to hear the gap while reproducing the bug use tracks which should play without a gap between them.

1. Play an MP3 file (not the last one in a directory).
2. Seek near to the end of the file (i.e. 30 seconds before the end).
3. Stop the playback. (A resume point is stored.)
4. Resume the playback by pressing PLAY.
5. Seek before the time point of resume. (Rockbock will rebuffer probably just the remainder of the track.)
6. Wait till the beginning of the next track.
7. Rockbox will start to buffer the next track too late - about 1 second before the end of the playing track although the default 5 seconds Anti-skip buffer is configured. As a result a gap will appear between the tracks.

Last reproduced on iriver H120, Rockbox CVS 061018-1412.
This task depends upon

Closed by  Brandon Low (lostlogic)
Monday, 23 October 2006, 16:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed, many thanks for all the testing and logging!
Comment by Steve Bavin (pondlife) - Thursday, 19 October 2006, 12:27 GMT
Hi Vaclav,

Seems ok here; the rebuffer at step 5 includes the subsequent tracks and no further rebuffer is needed.

What file format are you using - VBR? Could you also post your CFG file?

I was always able to reproduce  FS#5906 , so I'm slightly surprised not to see this.
Comment by Brandon Low (lostlogic) - Thursday, 19 October 2006, 14:27 GMT
I saw something similar to this before I fixed 5906, but after fixing it, it stopped happening -- the step 5 rebuffer should be a full rebuffer, so I don't really see a reason for this.
Comment by Václav Brožík (pabouk) - Thursday, 19 October 2006, 15:04 GMT

I have prepared defined conditions for reproducing the bug. It is reproducible with cleared settings.

1. Download testing files: http://www.dns.cz/ftp/data/Rockbox/_bug2_pabouk.zip
2. Extract them to the root directory of your player.
3. Reset the Rockbox settings.
4. Play the bookmark _bug2_pabouk.
5. When you let the playback to continue to the second track there will be continuous transition.
6. Stop the playback and play the bookmark again.
7. Seek back to let's say 3:30.
8. In the audio thread debug screen you can check that after the seek only one track is on the buffer.
9. Shortly before transition to the next track Rockbox will start buffering but it is too late and a gap will appear in the playback.

Last reproduced on iriver H120, Rockbox CVS 061019-1246.
Comment by Steve Bavin (pondlife) - Thursday, 19 October 2006, 16:31 GMT
I can reproduce. Discussed it with lostlogic; he'll look into it.
Comment by Václav Brožík (pabouk) - Friday, 20 October 2006, 06:49 GMT
Hi Steve,
thank you. Sorry, I forgot to answer that the problem appears with both VBR (testing files) and CBR MP3 files.
Comment by Brandon Low (lostlogic) - Sunday, 22 October 2006, 22:03 GMT
Does this still happen with the commit I just did?
Comment by Václav Brožík (pabouk) - Monday, 23 October 2006, 07:57 GMT
Hi Brandon,
thank you for your work. The gap between tracks does not appear anymore but it still starts to buffer the next track just before it is played so the (5 seconds) anti-skip buffer setting is not obeyed in this case.

I personally do not care much but I think that it is important to know.
Comment by Steve Bavin (pondlife) - Monday, 23 October 2006, 08:27 GMT
Hi Brandon,

This is still happening here in the H300 sim at least. You can see that the initial rebuffer only buffers the remainder of the current track, then further rebuffering (the next 7 tracks) only takes place when the buffer completely empties.

Previously the initial buffer would include as much data as possible.
Comment by Brandon Low (lostlogic) - Monday, 23 October 2006, 11:28 GMT
Steve, would you happen to have a logf of when it happens handy? I'm not seeing a code path that would cause it to stop buffering after just the playing track. Thanks.
Comment by Steve Bavin (pondlife) - Monday, 23 October 2006, 12:10 GMT
Yes, attached here. This is just me running Vaclav's test. I play from the bookmarked point, then rewind a little and then stop it after a few seconds (when no buffering is taking place anyway). I can do a longer one which shows the next rebuffering happening (at track change) if you want.
   log.txt (14.7 KiB)
Comment by Brandon Low (lostlogic) - Monday, 23 October 2006, 12:46 GMT
ok, I just tested this with my latest latest commit and I think it works right, one more review? :):)
Comment by Brandon Low (lostlogic) - Monday, 23 October 2006, 13:26 GMT
http://pastebin.ca/217053 thanks to pondlife for this log.

Weird thing is: it quick buf's part of the requested file, then playback resumes, then the next buffer mention is another quickbuf line, which probably indicates that the codec's request for the next track happens _before_ the playing track is fully buffered. This is where the problem crops up, what I don't understand is how the playing codec can finish and request a new track before the playing track has been fully buffered :-\\. Maybe there's trailing data, like an id3v1 tag or something? Is this still happening on faster targets than ipod? Codec must run pretty darn quickly for this to happen.
Comment by Václav Brožík (pabouk) - Monday, 23 October 2006, 15:16 GMT
It still happens on iriver H120.
Comment by Brandon Low (lostlogic) - Monday, 23 October 2006, 16:25 GMT
id3v1 is not my friend.