Bugzilla – Bug 2169
Player fails to move to next item in playlist after resuming a song paused near the end.
Last modified: 2008-12-18 11:38:58 UTC
I played an mp3 until there was < 1 minute remaining. I'm assuming the remainder of the song was in the SB2's buffer. I then paused. I enabled d_source, d_slimproto_v & d_stream_v and resumed. The player plays the end of the track and does not proceed to the next item in the playlist. I then enabled d_playlist to see what was going on. Here's what I captured in the logs when the song ends and the player "stalls" Further log details are attached here http://forums.slimdevices.com/attachment.php?attachmentid=318 2005-09-20 21:26:01.7995 new state: OP 2005-09-20 21:26:01.7997 state: OP, framelen: 0, inbuflen: 0 2005-09-20 21:26:01.7999 attempting to read 4 bytes 2005-09-20 21:26:01.8000 no more to read. 2005-09-20 21:26:02.7968 Slimproto client readable: 192.168.2.10:55866 2005-09-20 21:26:02.7971 state: OP, framelen: 0, inbuflen: 0 2005-09-20 21:26:02.7972 attempting to read 4 bytes 2005-09-20 21:26:02.7974 Got 4 bytes from client, 0 remaining 2005-09-20 21:26:02.7976 new state: LENGTH 2005-09-20 21:26:02.7977 state: LENGTH, framelen: 0, inbuflen: 0 2005-09-20 21:26:02.7979 attempting to read 4 bytes 2005-09-20 21:26:02.7981 Got 4 bytes from client, 0 remaining 2005-09-20 21:26:02.7983 new state: DATA 2005-09-20 21:26:02.7984 state: DATA, framelen: 41, inbuflen: 0 2005-09-20 21:26:02.7986 attempting to read 41 bytes 2005-09-20 21:26:02.7988 Got 41 bytes from client, 0 remaining 2005-09-20 21:26:02.7993 output size: 3528000 output fullness: 0 elapsed seconds: 250 2005-09-20 21:26:02.7995 new state: OP 2005-09-20 21:26:02.7997 state: OP, framelen: 0, inbuflen: 0 2005-09-20 21:26:02.7999 attempting to read 4 bytes 2005-09-20 21:26:02.8000 no more to read. 2005-09-20 21:26:03.7968 Slimproto client readable: 192.168.2.10:55866 2005-09-20 21:26:03.7971 state: OP, framelen: 0, inbuflen: 0 2005-09-20 21:26:03.7972 attempting to read 4 bytes 2005-09-20 21:26:03.7974 Got 4 bytes from client, 0 remaining 2005-09-20 21:26:03.7976 new state: LENGTH 2005-09-20 21:26:03.7977 state: LENGTH, framelen: 0, inbuflen: 0 2005-09-20 21:26:03.7979 attempting to read 4 bytes 2005-09-20 21:26:03.7981 Got 4 bytes from client, 0 remaining 2005-09-20 21:26:03.7983 new state: DATA 2005-09-20 21:26:03.7984 state: DATA, framelen: 41, inbuflen: 0 2005-09-20 21:26:03.7986 attempting to read 41 bytes 2005-09-20 21:26:03.7988 Got 41 bytes from client, 0 remaining 2005-09-20 21:26:03.7993 output size: 3528000 output fullness: 0 elapsed seconds: 250 2005-09-20 21:26:03.7995 new state: OP 2005-09-20 21:26:03.7997 state: OP, framelen: 0, inbuflen: 0 2005-09-20 21:26:03.7999 attempting to read 4 bytes 2005-09-20 21:26:03.8000 no more to read. 2005-09-20 21:26:04.1827 currentPlaylistChangeTime : Tue Sep 20 21:17:49 2005 2005-09-20 21:26:04.1831 currentPlaylistRender : Tue Sep 20 21:17:54 2005 2005-09-20 21:26:04.1834 currentPlaylistRenderSkin : 2005-09-20 21:26:04.1837 currentPlaylistRenderStart: 0 2005-09-20 21:26:04.1840 skinOverride: 2005-09-20 21:26:04.1843 start: 0 2005-09-20 21:26:04.1847 Skipping playlist build - not modified
Created attachment 845 [details] Zip archive of log files capturing behaviour I'm only guessing that this is a firmware bug as I would expect the player to request the next track in the playlist and under the conditions described it doesn't. If the Server is responsible for "pushing" data to the player, then it's a server side bug.
Vid, what do you think?
I see this too, intermittently. I've seen it since I had the SB2 (April?). Not sure if it happens on my SliMP3's or not -- sorry! Every time I sit down to try to replicate this it stops happening. But it seems to always happen if I'm not paying attention. Debian sarge Linux, running svn nightlies.
Vidur: can you comment on this?
*** Bug 2214 has been marked as a duplicate of this bug. ***
Here's the issue. When we pause and the playmode is playout-play, then resume, the mode gets set back to play not playout-play. I guess we need a playout-pause mode. ick.
I recall that there was something siilar to this for an older bug, playe stopping if a song is added to near the end of the last song. Maybe something similar can be used to test the restore condition after pause. Does pause actually change the playout-play mode to pause or stop?
it changes it to pause and then upon resume it changes it to play (and not playout-play, if it was that before).
I don't think it is always happening just near the end of the track. I think it also happens if you wait hours before trying to resume.
My last comment was not for radio streaming, which always plays the buffer ouyt and then stops. It was for mp3 playing.
I can reproduce this faithfully on both SoftSqueeze and SB2 - tried server 6.5b, 10/28 & 10/29. I have tried several different MP3s in my library, and it happens on them all.
Created attachment 977 [details] possible solution I tried to accomplish this without the mess of creating a new playmode. I noticed that the condition to trigger playout-play was a chunksize of 0. On resume, by comparing song position with totalbytes, the playmode can be reset to playout-play. This needs a bit more testing as I was unable to try it under enough conditions. It does seem to go onto the next song where it had not previously.
*** Bug 2459 has been marked as a duplicate of this bug. ***
I tested out KDF's proposed patch here https://bugs-archive.lyrion.org/show_bug.cgi?id=2169#c12 and it seems to fix the issue I first saw. The player does now move on to the next song if paused/resumed close to the end of the track. I am seeing some Random Mix weirdness but that may be just down to the amount of stopping and starting of the server I was doing. I'll keep testing. If this is confirmed to work, can it be rolled into 6.21 for those of us who would prefer to run the stable trunk.
I missed this patch before. I've just applied it so will report back in due time.
Ok, just adding to my previous comment. The patch works correctly and does not interfere with Random Mix. Random Mix loops the playlist when you shutdown/re-start the server. If this is in tommorrows nightly, I'll retest with Slim.exe and the bug can be closed unless anyone can think of a scenario he new code would break. Nice one KDF.
How does one apply the patch? Or when will it be in the nightly build?
I'll put this into the 6.5b1 nightly build so that it can be available for windows testing tomorrow.
Put it in the 6.2.1 build too. Do I really want to upgrade to 6.5? I just got patches for the softsqueeze brightness and slimserver displayed labels fixed in 6.2.1. Did they also get put into 6.5?
"Put it in the 6.2.1 build too." Eh! Would you mind adding it to the 6.2.1 nightly please? Since this is someone giving up their personal free time to fix a issue that's annoying you, some manners wouldn't go astray. To test the patch above, you would need to alter the Slim/Player/Source.pm and run slimserver.pl at the command prompt using perl.exe. Thats what I had to do as I don't run subversion. Since I reported this bug, I thought I should at least be willing to spend the time to download perl (downloaded 5.6.x first DOH!) and spend 30 mins testing it.
ALL fixes are in 6.5 as well as future features. 6.2.1 is strictly for critical and STABLE fixes. As I am unsure about this one, I am only going to put into 6.5 builds until it is approved by Slim Devices for adding to 6.2.1. Please try to be patient. It will get there eventually, since this is targetted for 6.2.1.
I've been working from home today and playback has been solid with your patch applied to last night's 6.2.1 nightly for the last 9 hours or so. I've paused/resumed a number of times near the end of songs and playback has continued. One thing I have just noticed. If I ffwd to about the last minute of a song (this could happen if I ffwd to any point in a track but I was trying to break the patch) and then let the remainder of the song play out, the time remaining goes -1:12, -1:11, -1:10 etc then the playback "gauge" jumps back to near the start of the song (when I started ffwding) and the time remaining displays -4:50. However it's only a graphical glitch and the player moves on to the next track in the playlist as normal.
committed to trunk for 6.5 build as of change 5027. This will be in the Nov 4 nightly build of 6.5. I'd be interested in knowing whether the ffwd glitch described can be triggered without this update in place. If it is caused by this change, it won't make it into 6.2.1 (6.2.2 perhaps)
I can confirm that the ffwd glitch has been around for a while. Several weeks at least.
Thanks Sue, could you please file a bug report for that one (unless I'm forgetting an existing report) Dean, let me know if this is good for 6.2.1
Bug 2486 Submitted for FFwd glitch.
I'd prefer to hold on this post 6.2.1.
Patch has been in 6.5 nightly build. Please confirm and reopen if there's still an issue. Thanks!
*** Bug 2537 has been marked as a duplicate of this bug. ***
*** Bug 2725 has been marked as a duplicate of this bug. ***
This works for me in the 12/19 build. It needs to be a patch in the current release too.
*** Bug 2745 has been marked as a duplicate of this bug. ***
The change 5027 from 6.5b1 has been merged into the 6.22 branch starting at the 22nd Dec. It seems to fix this issue. There are some time remaining graphic glitches but that doesn't affect the actual playback.