Rockbox

can you make one or a few of the tracks available? it sounds like the problem is with corrupt files.

It isn't the same song over and over again, and all the songs play fine is Apple's OS.

This is very puzzling indeed. Is the problem restricted to certain files, or does it appear to be random?
Maybe watching the buffering thread debug screen could be informative.

I've experienced this a few times with my Nano, but it's pretty rare - about once a month maybe. It's not file corruption as replaying the same song the behavior doesn't repeat itself. I think it's close to impossible (for me at least) to debug this as it happens so rare and random.

Maybe this is a different problem, but since r16430 (or thereabouts), I've been finding a regular problem where a track is restarted when rebuffering occurs. For example:
- Play an album (or playlist) from the start. It will play through to, say, track 7 fine.
- Track 8 plays partway through, then rebuffering occurs and track 8 starts playing from the beginning again!
- The WPS displays the ID3 data etc. for track 8 (and 9 as next track) correctly.
- The playlist index is actually track 9, and displays as, say 9 of 13.

Occasionally, playback will proceed fine, but most of the time this happens when natural playback through an album is allowed.

Very occasionally, rather than restarting the current track, it will skip forward many tracks (e.g. to track 18). In this case the resultant playlist index is still one too high.

I'm using the H300 sim, with album art on Cabbiev2.

I'm suffering the same problems as pondlife stated above; I'm also using r16430; target is a 5.5G iPod video, 30GB.

Ongoing investigation shows that this problem seemed to start (for me) in r16425.
- r16422 will play through albums fine (tested 4 times, worked 4 times)
- r16424 was fine (tested 3 times, worked 3 times)
- r16425 shows the above symptoms (tested once, failed once)
- r16426 shows the above symptoms (tested 3 times, failed 3 times)

OK, here are a couple of patches, that *might* help (but also might make things worse).

- playback_update_lpo_late.patch seems to fix the problem I've been having where rebuffering causes playback to go screwy. The idea is that whilst we want most of the track transition to happen asap (for a responsive UI), we don't want to update last_peek_offset until we have completed transition, so buffering won't attempt to overwrite the currently playing data.

- playback_scrap_les.patch attempts to get rid of the lowbuffer_event_sent variable, instead using queue functions to prevent multiple Q_AUDIO_FILL_BUFFER entries. I don't think this changes the functionality, but it is simpler and less use of global variables is normally a good thing.

I reserve the right to have grabbed the wrong end of the stick here, but if Nico_P, Lear and any other people who really understand playback.c could have a look this might be helpful. And of course, if people could test them that would be good too. In particular check (a) rapid manual track skipping, (b) use of auto-change dir.

playback_update_lpo_late.patch is now in SVN. Please report if you find this bug is fixed or not.

playback_scrap_les.patch might still be a good idea, perhaps jhMikeS and Nico_P could comment.

Seems to wrok 100%. Can anyone confirm?

Sorry to be the bearer of bad news, but my c250 is still experiencing this problem running r16460. It takes a while for the bug to show up, but when it does it consistently skips at the same point if I go back a track and try to play through the point again or fast-forward past it. I'm playing MPC files, but I don't think that is a factor in this bug.

Hmm, I don't have any MPC files. Could you perhaps try other formats and see if that is relevant?

Agreed, the problem is still here. I'm in savage realms beyond the reach of a machine with USB mass storage support, so I can't test fixes :/

The nature of the failure has chanegd somewhat. Where before your fix, on reaching the watermark, the buffering thread would pull in data up to the end of that file and then pause until complete exhausion, with remaining stuck at zero, and then playback would snap to the wrong track, now the buffering thread pulls in subsequent files as it's supposed to.

It just doesn't seem to pull in the *right* subsequent files.

I don't have any formats other than MPC. I'd be happy to transcode for testing if I could reliably trigger the bug. Since your check-in I've only had it trigger twice in two days of listening. If I can find some magic formula (like fwd 3 tracks back 1) then I'll transcode and test with Ogg or something.

I don't think we're talking about the same bug here, more likely two bugs with similar symptoms ("the first 5 seconds of a song play and then rockbox skips to the next track"). In other words, I accidentally hijacked this report, sorry.

Ian, Steve or Nick - If could you can come up with a better recipe (or even just a complete re-description of the problem), that might be useful. Does the problem occur when buffering starts, or during, or on completion?

Are you using album art? Do you have dircache enabled? How about scrobbling or gather runtime data? Does it happen with the default config?

Does it happen in the simulator, or only on target?

In case you didn't know, if you go onto the buffering debug screen, you can use the up and down keys to skip tracks.

Steve, when the problem comes up, it's usually in the first 5 seconds or so. I think it's the same thing I'm seeing. I've been playing with the buffer debug screen to try to find out what causes it. Could you explain the fields there? (like pcm frac, alloc frac, usefl frac, data_rem, handle count, pcmbufdesc)

When it happens I've seen twice track count = 3. And it was not in the middle of buffering. I think each time I've seen it I had done a fwd or back skip within a couple of tracks of where the problem manifests itself. All the times I've seen the problem I was using album art, dircache, and runtime data. No scrobbling and I don't know about the default config.

I too strongly suspect that these are unrelated bugs. The bug I see happens on the target, with oggs and mp3s both; I have scrobbling off and runtime data gathering on. It only happens after rebuffering, following which the subsequent track played is the wrong one (generally, it seems to hop back one or two tracks, the track number in the playlist moving forward as it should; from then on the playlist position and actual track remain out of synch with each other, even over a repeat. Nothing goes wrong with playback until track-end now that playback_update_lpo_late.patch is installed.

I can't easily change the config to a great extent or simulate things until next week, when I'll be back around a machine with a compiler and USB support; but I'm reading through the playback.c / buffering.c code, and will post more if I see anything suspicious.

My bug sounds identical to the bug pondlife@ is describing, and quite different from the one that originated this bug.

pondlife: Since your checkin of the 2nd patch I've been testing r16505 and have not seen the symptoms described here. I have seen the odd occurrence where a track gets to the end and then repeats from the beginning. But, that's not what is described here. As far as I'm concerned, I suggest closing this bug because I've not seen it occur in quite a while.