Rockbox

Just wanted to add this info. Advancing to the next track while the track is being repeated causes the track that should now be playing to play, but the playlist information doesn't correct itself. So if track 5 is repeated, advancing causes track 6 to play, but the playlist info shows track 7.

I too have experienced this bug several times on my e280r and e260r players while listening to an M3U playlist with shuffle turned on but repeat disabled. A random track in the playlist will immediately play a second time. This bug seems to have been introduced in early January, as that is when I remember this behavior first started happening.

I've been testing a build from 20080107 on my Gigabeat F for the last several hours with no occurrences of this bug. I will continue to attempt to narrow down when it was introduced.

I was looking through the commits after that date and there were a slew of playback.c commits by Nicolas Pennequin right after January 7th. I'm betting that one of those caused the bug.

Yes, I probably introduced some bad side-effects while trying to fix other bugs. I'll look into this ASAP.

I am experiencing this on my Sans e280 only with the playlist with 1200 entries (Harry Potter VII audiobook)
My usual music playlists (around 300-400 entries) have not shown this behaviour. (As far as I remember...)

iPod Nano here and seeing the same behavior from time to time. M3U playlist of ~500 songs in 3 folders, shuffle off, repeat all.

Concurrency issues. I can force this bug to nearly always occur if mutexes yield on unlock to higher priority threads which should leave basic operation unaffected.

jhMikeS, could you send me a patch that does that - I'll see if I can repro it on H300 or even better (hint) on the sim...

I'd be interested in the patch too!

I don't really have a patch since it just came up in doing some reworking of things and I noted that various kinds of playback mal-behavior come and go with variations in scheduling whereas code like mpegplayer is unaffected (other than minor performance variation). Just add a switch_thread(NULL) call to mutex_unlock if a waiting thread was woken (further restrict by doing this only if the priority of the woken thread is higher (ie. lower value) than the waking thread). This must be done after the corelock is released of course. The FAT driver is not safe to perform this on at this time so take care with that as well.

If you need me to do a quick patch I suppose I can do that soon when I get the time.

I see this bug as well, with r16452. From looking at the audio thread debug screen, when the buffer reaches its low watermark, it fills, but *only to the end of the currently-playing track* (or perhaps the track at the end of the buffer; in all my tests so far these have been the same. Anywya, the buffer remains largely empty). Refilling then triggers again, and refills all the way, when the buffer is *completely* empty and the track hits zero, but it is too late: the pcm thread has jumped back to an earlier track (sometimes the previous one, sometimes the first track in the buffer before loading triggered).

Here we are. At start: data_rem 2924118, 6 tracks (of 14) buffered; 28314672 bytes...

Oh, great: if I fast forward to the next track all playing ceases and won't resume. That'll make replication really fun: I've got to let the buffer empty naturally.

(Hm, sorry, that last test was with playback.c backed out to r16424: I'm not sure that particular failure mode still happens with HEAD.)

Nick, you might want to try the playback_update_lpo_late.patch I attached to  FS#8455 . I think this is the same problem. Seems that patch causes fun with manual track skips during buffering, but I'd be interested in more feedback.

More info: if you wait a couple of seconds between each track skip, the problem doesn't seem to happen.

(The low-watermark bug above doesn't happen consistently either. I hate multithreading systems. I also hate finding a bug like this when I'm going to be away from all computers for the next week and a half, grrr.)

Thanks for the patch, Steve: I was suspicious that something was smashing last_peek_offset but hadn't figured it out. It looks plausible.

Building now.

OK. The freezes on fast track switches are still there. I think this is a fadeout bug: if you switch tracks while the track switch fadeout/fadein is still happening, you get a freeze. Rebuffering is not required; it happens even if the old and new tracks are both buffered.

The other bug, the one you can't work around by turning fade on manual track change off, is fixed!

Thank you! My life is complete!

(some people think I rely on my iPod too much. They do not know the lure of Rockbox.)

I have an iAudio X5L, and this problem still occurs occasionally. I think the last time I got the bug was when I was playing an album and I think track 7 of the album repeated in a playlist of about 30 songs. I had fade in/out turned off, and the database is disabled.

It happened to me again too - but only once in several weeks. Not easy to diagnose, perhaps someone can come up with a method to make it happen at will?

Spontaneous repeats do still happen now and then, yes, but they're rare enuogh that I can't even tell if they're associated with rebuffering or not, although their positions in the playlist implies that they are. I've had it twice sine I posted last.

I've been experiencing the playback repeat bug at least once a day. I now have something else to share that may be related to this bug. Yesterday while I was listening to a song from my MP3 playlist, I pressed the "left arrow" (rewind) key on my Sansa e280r (the one to the left of the scroll wheel), so that I could start over and listen to the song play from the very beginning again -- this was due to the fact that I had previously clicked the pause key during playback of the song and then shut down the Sansa. The song had about one minute of playback remaining before I pressed the "left arrow" key. The song did resume playback at the beginning of the song as I wanted, however a strange thing happened: the song only played for the amount of time that was remaining before I clicked the rewind button -- it then immediately stopped playback of the current song and began playback of the next song. The impression that this behavior imparts upon me is that Rockbox forgot to adjust the playing time of the track after it had reset the track's playback position to the beginning of the song. Could this issue be related to the buffering bug, or is this related to a completely different (possibly known) issue?

Hi Tony,

Which revision of Rockbox are you using? That was definitely a bug before, but I thought it had been fixed a month or so ago.

I think today I experienced exactly the same issue as Tony - running r16717. Upgrading now.

Hi Steve:

I am currently running Rockbox version r16623M-080310. Will an upgrade to a new version correct that playback issue I just reported?

Tony: Please only report issues with a very recent build. The bug you mention might have reappeared but I couldn't reproduce it.

I've been experiencing the playback repeat bug several times (5 or more) today while playing three different playlists with less than 30 tracks on my sansa e260 running r16932-080402

On the build from last night, r16941, I get the bug a lot more than with a build from a couple days ago. One album had a few repeats.

Much better with r16948. Only listened to one album, but it was the same one as last night that was giving me problems.

Much better with r16948. Only listened to one album, but it was the same one as last night that was giving me problems.

I think I'm pretty close to fixing this one, but I think it's worth mentioning why it happens and how I managed to reproduce it.
What I did is force a rebuffer on every track change to increase the odds of it happening (I got this idea from philibuster's comment :) ). With that change, the bug occurred (at least) on every track change that followed a resume. From there, it was rather easy to track down. The cause is, as someone speculated, r16019 (http://svn.rockbox.org/viewvc.cgi?view=rev&revision=16019). The problem is that if the playlist position isn't updated before rebuffering, rebuffering will start with the track that just played.
I'm working on a fix, but it's not trivial as I want to keep the playlist position updated *after* the track change is over.