Rockbox

Tasklist

FS#8513 - Playback occasionally repeats a track when rebuffering occurs

Attached to Project: Rockbox
Opened by Jeremy Cayot (woodensoul) - Friday, 25 January 2008, 21:00 GMT
Last edited by Nicolas Pennequin (nicolas_p) - Thursday, 03 April 2008, 21:45 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To Nicolas Pennequin (nicolas_p)
Operating System All players
Severity Medium
Priority High
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

There is a new playback bug that causes a track to repeat even though repeat is DISABLED. The bug occurs as follows: play the first track in a directory and allow playback to continue normally through the playlist. I'm guessing that the repeat occurs when playback reaches the end of the buffer. The song at the end of the buffer? repeats and the playlist information moves to the next track. i.e. The ID3 info still shows the track that is repeated, but the playlist info shows "6 of 10" even the track 5 is being repeated. Clear enough?

This has occurred on my iRiver H140 and H320, Sansa e280 and Gigabeat F so it's not target specific. It showed up within the last two weeks, but at this time I can't be more specific about the date it was introduced.
This task depends upon

Closed by  Nicolas Pennequin (nicolas_p)
Thursday, 03 April 2008, 21:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  Should be fixed by r16955.
Comment by Jeremy Cayot (woodensoul) - Friday, 25 January 2008, 21:05 GMT
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.
Comment by Tony DeFusco (ToneDeF) - Sunday, 27 January 2008, 03:20 GMT
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.
Comment by Jeremy Cayot (woodensoul) - Sunday, 27 January 2008, 13:43 GMT
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.
Comment by Jeremy Cayot (woodensoul) - Sunday, 27 January 2008, 13:55 GMT
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.
Comment by Nicolas Pennequin (nicolas_p) - Monday, 04 February 2008, 19:44 GMT
Yes, I probably introduced some bad side-effects while trying to fix other bugs. I'll look into this ASAP.
Comment by Matthias Kraus (DerSarek) - Thursday, 07 February 2008, 10:50 GMT
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...)
Comment by Florin Popescu (florinp3) - Friday, 22 February 2008, 15:15 GMT
iPod Nano here and seeing the same behavior from time to time. M3U playlist of ~500 songs in 3 folders, shuffle off, repeat all.
Comment by Michael Sevakis (MikeS) - Friday, 22 February 2008, 16:34 GMT
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.
Comment by Steve Bavin (pondlife) - Friday, 22 February 2008, 17:57 GMT
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...
Comment by Nicolas Pennequin (nicolas_p) - Friday, 22 February 2008, 18:50 GMT
I'd be interested in the patch too!
Comment by Michael Sevakis (MikeS) - Saturday, 23 February 2008, 16:35 GMT
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.
Comment by Nick Alcock (Nix) - Friday, 29 February 2008, 20:51 GMT
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).
Comment by Nick Alcock (Nix) - Friday, 29 February 2008, 21:11 GMT
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.
Comment by Nick Alcock (Nix) - Friday, 29 February 2008, 21:13 GMT
(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.)
Comment by Steve Bavin (pondlife) - Friday, 29 February 2008, 21:43 GMT
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.
Comment by Nick Alcock (Nix) - Friday, 29 February 2008, 22:30 GMT
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.)
Comment by Nick Alcock (Nix) - Friday, 29 February 2008, 23:18 GMT
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.
Comment by Nick Alcock (Nix) - Friday, 29 February 2008, 23:48 GMT
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.)
Comment by philip kao (philibuster) - Friday, 14 March 2008, 23:57 GMT
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.
Comment by Steve Bavin (pondlife) - Monday, 17 March 2008, 17:45 GMT
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?
Comment by Nick Alcock (Nix) - Saturday, 29 March 2008, 19:29 GMT
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.
Comment by Tony DeFusco (ToneDeF) - Sunday, 30 March 2008, 02:09 GMT
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?
Comment by Steve Bavin (pondlife) - Sunday, 30 March 2008, 07:00 GMT
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.
Comment by Florin Popescu (florinp3) - Sunday, 30 March 2008, 10:59 GMT
I think today I experienced exactly the same issue as Tony - running r16717. Upgrading now.
Comment by Tony DeFusco (ToneDeF) - Sunday, 30 March 2008, 14:20 GMT
Hi Steve:

I am currently running Rockbox version r16623M-080310. Will an upgrade to a new version correct that playback issue I just reported?
Comment by Nicolas Pennequin (nicolas_p) - Sunday, 30 March 2008, 15:36 GMT
Tony: Please only report issues with a very recent build. The bug you mention might have reappeared but I couldn't reproduce it.
Comment by Heinrich Münz (HMuenz) - Thursday, 03 April 2008, 11:59 GMT
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
Comment by philip kao (philibuster) - Thursday, 03 April 2008, 15:55 GMT
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.
Comment by philip kao (philibuster) - Thursday, 03 April 2008, 17:31 GMT
Much better with r16948. Only listened to one album, but it was the same one as last night that was giving me problems.
Comment by philip kao (philibuster) - Thursday, 03 April 2008, 18:28 GMT
Much better with r16948. Only listened to one album, but it was the same one as last night that was giving me problems.
Comment by Nicolas Pennequin (nicolas_p) - Thursday, 03 April 2008, 20:21 GMT
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.

Loading...