Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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
Attached to Project: Rockbox
Opened by pabouk - 2006-10-18
Last edited by pondlife - 2006-10-19

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.

Closed by  lostlogic
2006-10-23 16:48
Reason for closing:  Fixed
Additional comments about closing:  

Fixed, many thanks for all the testing and logging!

pondlife commented on 2006-10-19 12:27

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.

lostlogic commented on 2006-10-19 14:27

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.

pabouk commented on 2006-10-19 15:04

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.

pondlife commented on 2006-10-19 16:31

I can reproduce. Discussed it with lostlogic; he'll look into it.

pabouk commented on 2006-10-20 06:49

Hi Steve,
thank you. Sorry, I forgot to answer that the problem appears with both VBR (testing files) and CBR MP3 files.

lostlogic commented on 2006-10-22 22:03

Does this still happen with the commit I just did?

pabouk commented on 2006-10-23 07:57

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.

pondlife commented on 2006-10-23 08:27

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.

lostlogic commented on 2006-10-23 11:28

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.

pondlife commented on 2006-10-23 12:10

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)
lostlogic commented on 2006-10-23 12:46

ok, I just tested this with my latest latest commit and I think it works right, one more review? :):)

lostlogic commented on 2006-10-23 13:26

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.

pabouk commented on 2006-10-23 15:16

It still happens on iriver H120.

lostlogic commented on 2006-10-23 16:25

id3v1 is not my friend.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing