Bugzilla – Bug 2644
Shuffled playlist does not play from the top
Last modified: 2008-09-15 14:38:10 UTC
When I start playing a saved playlist in shuffled mode, Slimserver does not start with the first song at the top of the list. It begins further down in the list, so that the first x number of songs don't get played. ("x" is different each time.) Settings: Repeat: Off Shuffle: Songs Slimserver version: 6.2.2 (from Slimserver nightlies) SB version: 3
I'm seeing this as well in the 2006-02-10 nightly on debian linux. It may be related somehow to the position of the last played item in the previous playlist. After listening to a lengthy playlist and playing another shorter one, the first song played in shuffle mode was the last in the shuffled playlist. After re-loading the long playlist and playing the first track, then re-loading the second playlist, it played from the beginning.
is this 6.2 only, or also happening with 6.5? how are you initiating playback of the playlist? the server does store thes last played track for a given playlist (CURTRACK) to restore to that index when playing again. could this simply be a misunderstanding of that feature? check if the CURTRACK line is being written to the m3u.
I'm not able to test 6.5 so I'm not sure. I noticed this first with a nightly playlist fired off with the 'playlist play' CLI from cron. I believe when the playlist reached the end (which would take several days, since playback is stopped by cron as well after 2 hours or so) subsequent plays with the CLI would load the list and start at the last track, and then stop. This is different than just stopping and hitting play since the CLI is supposed to do a new 'playlist play' each night in case we've used another playlist in the meantime. Just today, on a different player, we were several pages into a very long playlist on album shuffle mode. I switched to song shuffle and loaded a new playlist and it played the last track in the list. The second playlist was the same playlist mentioned above that is played by cron nightly. Maybe this is intentional although shouldn't CURTRACK have been reset at the end of the playlist? Is there any way to turn off CURTRACK short of removing write access? I'm not sure I really need the current position of the playlist stored outside the slimserver process. I looked for likely bugs and this one caught my eye.
I'll be frank, I despise the very concept of having to constantly add an option for every single feature. However, I'm well in favour of coming up with a more complete set of logic for a given feature. Yes, I think CURTRACK could be reset. Right now it looks like it is done via a newsong callback, so we'd have to have a special case to deal with ending a playlist. Also, when loading a playlist in shuffle mode, it might be applicable to disregard the CURTRACK. Having it manually set on/off introduces just too many issues: UI for web, UI for player, handling on-the-fly, now that its a pref-what about prefs as to how it behaves, etc. As always, just MY own opinion. I'll try to work up a patch for what I've described.
Created attachment 1138 [details] Dont' update CURTRACK or jump to CURTRACK if shuffled This patch will skip the writing of the CURTRACK when in shuffle mode. It will also skip the jump to CURTRACK when the shuffle mode is songs or albums
Created attachment 1139 [details] new patch to reset the CURTRACK as well This patch does what the previous one does, and also works if teh shuffle mode is changed after loading. This also resets the CURTRACK to 0 when a playlist ends. uses the existing nowPlayingCallback from resetSongQueue (which is only called when playing stops at end of playlist with repeat off.
I've applied this to 6.5 at change 6308. Once the start at zero function is confirmed by someone other than myself, I can merge it into 6.2.2. The reset to zero at and of play cannot be ported since it relies on the dispatch and callback code from 6.5. If this isn't critical as a fix for 6.2, feel free to mark this as closed.
Can anyone comment on KDF's fix? I'm ok for it to go into 6.2.2 Thanks.
Created attachment 1192 [details] ported to 6.2.2 Here is a version that covers everything done in 6.5, including a port of the callback. it seems to work, but my multi-server setup is a bit flakey, so it would be nice to have confirmation.
Created attachment 1193 [details] proper version sorry...forgot to rerun the proper diff.
committed to 6.2.2 at change 7035, please verify and reopen if there are problems.