Scott,

I take it you're using the SlimServer web interface and you've queue'd up about 5 songs, then you chose shuffle: songs? Is this an accurate summary? Then the Squeezebox player's screen goes blank and music stops playing? 

I tried this with SlimServer 6.5.2 on XP and I wasn't able to reproduce this. 

Something tells me this may not be a bug, but rather a potential support issue. Have you been able to reproduce this again?

Here are the steps to reproduce.

I am using the slimserver web interface.
Under Browse, I choose Random Mix.
All Genres are Checked, Add new items when old ones finish is checked.  Now playing will show 500 upcoming songs and 5 recently played songs.
Still on the left hand frame click Play.
On the right hand side of the screen there is a line that says Shuffle:  off/songs/album.
If I click Songs it is highlighted and the songs shuffle.  After about 5 songs it sets itself to off.

This isn't that big of a problem in 6.5.2.  I discovered it in 6.5.1 because the random mix generated wasn't random at all.  Now that random mix works, the shuffle isn't that big an issue, but I still thought I would report it.

Sure enough, I'm able to reproduce this with 6.5.2 on XP. Thank you for clarifying. 

However now I'm more confused, why are we trying to shuffle something that is already random? Scott, what are we trying to achieve in the end here? Sorry if I'm asking something silly, but it seems to me shuffle mode shouldn't matter while playing a random mix. 

As I said below.  In 6.5.1 the random mix was anything but random.  It was obviously addressed in 6.5.2, because it is back to being random again.

This is by design, as shuffle is meaningless in randomplay mode.

See RandomPlay/Plugin.pm line 370:

Slim::Player::Playlist::shuffle($client, 0);

It's been there since the old days of it being a third-party plugin. As for why it doesn't update the status when the user initiates a shuffle...the line above is executed each time tracks are added, so if you have "show 5 previously played songs" then new songs will only be added after 5 songs.  Set for 2 previous songs, and it will be reset after 2.

(In reply to comment #5)
> This is by design, as shuffle is meaningless in randomplay mode.

Wouldn't it make more sense to just ignore shuffle rather than to reset it?  So that when the client is asked to play something other than random mode it will be in the same state in which it was left.

Ross, if you have a 7.0 installation handy, could you have a look just to verify this still occurs in 7.0?

Ross doesn't need to waste time checking.  The code is teh same as I have described previously.
properly ignoring shuffle will require checking the state of random play in every location where an action takes place due to a check of the shuffle pref.

There are basically two ways that I think this can work:

1) Turn off shuffle, add new items, turn on shuffle.  Using Player::Playlist::shuffle only sets the pref, so doesn't look like it will trigger a shuffle of the playlist on it's own.

2) Add a new argument to the playlistXTracks command which allows a bypass of the shuffle setting when the playlist addtracks command is used from RandomPlay.  This seems a bit trickier since it bounces through the whole CLI, but perhaps Fred knows the easiest way to add something like this, or whether it makes sense to do so when option 1 may work.

Created attachment 2440 [details]
temporarily disable shuffle while adding tracks.

We can do 2), no problem.

iTunes does gray out "shuffle" and "repeat" controls when you engage the party playlist.

hrm, not sure about graying out (more waiting for artwork) but we could set a "disable controls" flag from randomPlay, then simply fail to react to shuffle and repeat controls until random mode gets disabled. It means adding a check to every souce for those commands, however, so I guess CLI covers web/jive/cli and then we need to deal with the button commands and the settings mode.

It seems that the player UI in this case also goes through CLI, so it's not so bad after all.  We can set a state via a function call or client method (no worries about making it a pref, unless we want to ensure random play persistence).  The state can initially block the cli shuffle command.  HTTP can serve to skins so that skins can optionally change graphics where required.

Created attachment 2443 [details]
block shuffle functions while in continuous mode

sets a client state while playing in continuous mode.  outside of continuous mode, it's a static playlist so I figured it's ok to allow the users to shuffle however they want on that one.  Shuffle is still disabled when random play is adding the tracks so that shuffle doesn't affect the initial build.

pressing buttons will just keep showing the current shuffle mode.  We'd need to add a status query response and an http response for skins to do things like greying out of the buttons, but I don't think that's hugely important.

Andy: is this a variant of the don't-change-repeat-mode work that you are doing for Pandora et al?

Maybe, all Pandora does is remember the repeat setting and set it back when you play something that's not Pandora.  It also checks if the repeat setting is changed and ignores the change.

Could we do the same with random play?  Save the current shuffle setting when entering random mode, and restore it when leaving random mode?  And ignore changes while in random mode.

That's an interesting idea, but the problem is that the Pandora method forces a return to the required repeat setting, while this bug report expresses an issue with forcing a shuffle value.  In fact, it would seem that having repeat forced to 2, thus displaying repeat all mode would also be "wrong" if following this request.

Also, the pandora method still reacts to repeat, then resets.  If we react to shuffle, then there is a shuffle and unshuffle process involved.  

I think the simplest method may be the first proposed patch, which simply bypasses the shuffle setting when tracks are added.  This avoids a reshuffle of the random playlist without affecting the shuffle setting shown in the ui (except for the rare case when the ui updates at the exact same time that we are adding songs, which is theoretically not possible given the single thread design)

It looks like the first patch has already been applied.  I'm happy with it, and it doesn't seem to have affected anyone.  Marking fixed!

This bug is being closed since it was resolved for a version which is now released!  Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html

If you are still seeing this bug, please re-open it and we will consider it for a future release.