Rockbox

Er, are you skipping past the end of the buffered data?

Here is the feeling I get: where there is only a partial track remaining in the buffer, if you let it play normally, it'll play flawlessly, but if you try to go to the next track, the playback will pause.

That's normal (and unavoidable)... if the next track is not buffered yet, then skipping to it will cause an immediate rebuffer, which will include a delay (how long depends what kind of disc you are loading off, whether you have dircache enabled, etc). How else is it supposed to work?

If you let it play normally it starts to rebuffer shortly *in advance* of running out of data, so that there is no gap..

It would be normal if the pause was before the next track start.
But I forgot to mention that the pause occurs after a few hundreds ms of the next track.
The action to go to the next track when the next track is not buffered is a little longer, so I presume it's doing something on the disk.
It plays a few hundreds ms of the track, then pause and resume.
Once or twice, I got the feeling that these few hundreds ms were pure audio garbage, but most of the time it's really the start of the new track.

It's exactly the same symptoms that the one I described in  FS#11016  (which was a duplicate of the  FS#10919  I mentioned when opening this bug) excepts that it not longer occurs on normal playback refills.

Using the patch I made to get info on the remote (my h300 is in my bag when I'm listening ^^), I've made a few progress into reproducing it.
In fact, it's getting stranger.
If I understand correctly, the 'track count' under the buffering thread debug screen counts the number of track currently in the buffer, including the one playing.
Meaning that 1 means that the next song isn't buffered yet.

The strange thing is that the music pause happens when you skip to the next track when the track count is showing 2.
Then the next track plays for half a second then playback pause and shortly after the status bar shows that rockbox is reading something from the disk.
After that, going to the buffering thread debug screen shows that the buffer is now filled.

When skipping to the next track when the track count is 1 doesn't produce this pause.
The next track skip is a little longer to kick in though, probably waiting for the buffer to have a few pieces of the next track.

I've made another interesting dicovery (well maybe it's not really a discovery, I tried to search the wiki about the buffering thread and the returned pages are 3 years old ^^).

The first buffer fill, the one that occurs at startup) and the next ones (buffer RE-fill) don't do the same thing.
The difference lies in how they treat the last track, the one that doesn't completly fit in the buffer.

The first buffer fill will fill the buffer with as much data as possible while the buffer re-fill will simply put a really small part of the track in the buffer, leaving a relatively big part of the buffer empty.
I'm saying that it put a really small part because it would explain the track count being 2 just before AND the few hundred ms I can ear before the playback pause.

Since I've already discovered that this playback pause happens when I activate DB + dircache + WPS with an unicode font (see  FS#11016 ), it should be interesting to see how buffer re-fill works then.

I've updated the build on my player monday evening.
The bug is still here.

I've discovered another interesting thing : when dircache is deactivated, the buffer re-fills work as the first buffer fill, meaning that the last track (the one that doesn't fill entirely) gets partially (more than a few ms) buffered.

I tried to make a build with logf support, but something must have gone wrong.
The 2 log entries show in debug screen (show & dump), but none of them seem to work.
show log only clears the screen & dump shows a splash saying that the log file was dumped, but I can't find any file name logf.txt.

Something special needs to be done ?

Another interesting discovery : when tagcache is crashed but dircache is ok, the buffer re-fills works like the first buffer fill.

I though that the first buffer fill is OK because tagcache is still in its initializing stage and not ready yet.

All the previous tests where made with tagcache loaded to ram.
This time I tried to disable this (load tagcache to ram): the re-fills worked has it should!

Well I must have been sleepy when I made the tests of my previous post.
tagcache not loaded to ram exhibits the same symptoms that when loaded to ram.

This morning, with tagcache not loaded to ram, it did work as intended.

I managed to reproduce this, but I can't come up with a consistent way of doing so.

It *looks* like it happens when you skip ahead to a partially buffered handle (i.e. when track count is 2) and the skip results in the watermark for rebuffering being passed; if so, then the problem should happen less often if you use a larger value for the antiskip buffer (as this makes the watermark higher). It won't eliminate it, though, if you have long tracks or switch codecs mid-playlist or similar...

I could be wrong though.