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
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
|
DetailsBrandon 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 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!
Monday, 23 October 2006, 16:48 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed, many thanks for all the testing and logging!
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 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.
thank you. Sorry, I forgot to answer that the problem appears with both VBR (testing files) and CBR MP3 files.
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.
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.
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.