- Status Closed
- Percent Complete
- Task Type Bugs
- Category Music playback
-
Assigned To
lostlogic - Operating System All players
- Severity Medium
- Priority Very Low
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#6205 - Delayed buffering of a new track after playback resume and rewind
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.
2006-10-23 16:48
Reason for closing: Fixed
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
Fixed, many thanks for all the testing
and logging!
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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.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.
Hi,
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.
I can reproduce. Discussed it with lostlogic; he'll look into it.
Hi Steve,
thank you. Sorry, I forgot to answer that the problem appears with both VBR (testing files) and CBR MP3 files.
Does this still happen with the commit I just did?
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.
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.
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.
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.
ok, I just tested this with my latest latest commit and I think it works right, one more review? :):)
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.
It still happens on iriver H120.
id3v1 is not my friend.