There's already support for various random algorithms, I dunno how to select
those however ;)

I think we definitely need a better way to select play-orders than the shuffle
and repeat checkboxes. There are a number of reasons for this, including:

1) There is no way to make alternate play-orders visible to the user.
2) I doubt anyone (who hasn't looked at the code) knows the different between
shuffle/repeat and shuffle/not-repeat.
3) I'm not sure how useful not-shuffle/not-reapeat is, because I think the "play
through the playlist once and then stop" usage would be fairly uncommon for
users of Rhythmbox.


I'm not sure of the best way of exposing this to the user; because it needs to
gain the ability to choose from multiple play-orders, which still being quick
and easy to change. I (personally) change between shuffle and linear regularly,
so don't want something that will take  considerably more time to change.

The obvious choice which will let the user choose from several play-orders is a
menu, but that is *much* slower than checkboxes because they can't scan the list
looking for the one they want until they have click on it.

Created attachment 58647 [details]
patch to add play order submenu

This was posted to the ML a while back by Paul Boyd (bughunter@gmail.com).

It replaces the Shuffle and Repeat menu items by a play order submenu. If this got updated for current cvs, and the toolbar items replaced, it would help to solve this. It also adds a "repeat one song" order.

What I would suggest is replacing the shuffle and repeat buttons with a drop-down list. This would give a hint that the play order can be changed with the control (this would be easier to notice than something hidden in the main menus, although that should exist too, for a17y issues), and would give an overview of choices when clicked.

Created attachment 61473 [details] [review]
updated patch

Updated to cvs, and now uses GtkUIManager.

Having a GtkMenuToolButton in the toolbar would be nice, but I couldn't figure out how to add it without doing dodgy stuff. I'm not sure if you can a) put a GtkMenuToolButton in the xml ui definition file, and b) have a single menu which you attach to two places (the menu bar, and the toolbar item).

If we can't do (b), we can just add another gtk_ui_manager_add_ui call.

Adding the toolbar menu doesn't appear to be simple. GtkUIManager can't create GtkMenuToolButtons unless we create a new GtkAction-derived class for it, and insert the action specially. If we don't use GtkUIManager to build it, it's harded to add the play-order actions.

Created attachment 61589 [details] [review]
updated patch

Updated for cvs, minor fix.

I would like to keep a toolbar item, or some other way to inform the user as to the current algorithm being used, e.g. linear or some form of random selection, because it's easy to forget.  There should be some way of finding out what the status is at a glance, without going through the menus, so I'd vote for some kind of feedback, ideally a toolbar button.  Making it work for gtk2 2.6 would be nice. ;-)

Perhaps another idea would be to factor in each song's play count 1 time out of 5.  This would start play the lesser played songs more often.

Created attachment 63566 [details] [review]
better patch

Adds the play order menu to the toolbar. RBMenuAction should really be in it's own file (not rb-glade-helpers) but I was lazy.

What should we do when the user presses the button next to the menu? Making it pop up the menu would work well, but I'm not sure how to do that. Another option would be to pop up a dialog listing all the play order, with really good descriptions of them, so people don't get confused.

Update summary to reflect the major remaining request: exposing the options in the UI, updating Priority to normal.

I like the foobar2k style of choices.
(see its UI snapshot:: http://foobar2000.org/screenshots/main-simple.png )

There is a drop down list called "order". The list items are::

# Playback/Order/Default
# Playback/Order/Random
# Playback/Order/Repeat (list)
# Playback/Order/Repeat One
# Playback/Order/Shuffle (list)
# Playback/Order/Shuffle album
# Playback/Order/Shuffle album 2 (directory)
# Playback/Order/Shuffle tag set 

(I find this list from its user guide, http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Commandline_Guide )

As of those choices, I like the "shuffle directory" most. I believe that no one would care about too detailed settings, such as random algorithms; but one will need these choices listed above.

Here's a different approach to this (I'll attach the diff in a sec).
It combines a lot of the random modes together and uses preferences to select the behavior:

------
Hi,
  I've spent some of the day looking under the covers of
Rhythmbox for the first time and would like to share a patch
I've put together today that changes the way the random play orders
work.  I'd been wanting some of the features for a while
and I had seen the patches in 
http://bugzilla.gnome.org/show_bug.cgi?id=163196
My approach is a little different.

  The main thing it does is to combine the various weighted
random orders into the single by-age-and-rating version
that already exists, but it adds preferences that allow the
user to specify how much they would like the age and rating
to influence the weight.  

  It also adds another weight into the calculation as a way
to penalise tracks that have been played 'very recently';
the user can specify in the preference a time period (e.g. 2 days)
and a penalty.  That way you get the weighted random but
with a much lower chance of getting the one you heard this morning.

  These preferences are sliders that go in a new tab in the 
preference dialogue.  I've also added on that pane a radio button
pair that specifies whether the 'shuffle' button sets shuffle
or random.  I feel this is better than the current situation
where the mode is hidden.

  It all works however there are a few rough edges:
    * The radio button to change the behaviour of shuffle is
only loosely tacked in - I think it would be best to kill off
the shuffle+repeat semantics and it would tidy my change up a
lot if I did - with the preference selection I don't believe
it is needed any longer.
    * I'm not sure I understand the best ways to use 'eel';
and I may have a few knotted eels in places.
    * I haven't updated the docs yet.

  I think the main advantage of doing things this way is that
for the casual inexperienced user there is no added complexity;
(as opposed to adding a mode selector on the main UI) and it exposes
the random mode without the odd combination of pressing the two
unrelated buttons.

  From a code point of view I believe the result is actually
smaller since it combines the equal, weighted by age, weighted
by rating and weighted by age and rating into one.

  It's my first rhythmbox (and gnome) patch so I would appreciate
constructive comments and I'll happily admit to doing some of this
by voodoo-coding and welcome suggestions.

Created attachment 101867 [details] [review]
random algorithms in preferences

See my description in previous comment

Created attachment 102277 [details]
Screenshot of new preference pane

I like the idea.  However, you probably need to have a few words in the preference pane explaining how shuffle is different from "random".   i.e shuffle is without replacement and random is with replacement, although hopefully explained in less mathematical terms for regular users.

Maybe:

shuffle: "don't repeat tracks"
random:  "tracks may be played more than once"

(In reply to comment #13)

>   It also adds another weight into the calculation as a way
> to penalise tracks that have been played 'very recently';
> the user can specify in the preference a time period (e.g. 2 days)
> and a penalty.  That way you get the weighted random but
> with a much lower chance of getting the one you heard this morning.
> 
>   These preferences are sliders that go in a new tab in the 
> preference dialogue.  I've also added on that pane a radio button
> pair that specifies whether the 'shuffle' button sets shuffle
> or random.  I feel this is better than the current situation
> where the mode is hidden.
> 
>   It all works however there are a few rough edges:
>     * The radio button to change the behaviour of shuffle is
> only loosely tacked in - I think it would be best to kill off
> the shuffle+repeat semantics and it would tidy my change up a
> lot if I did - with the preference selection I don't believe
> it is needed any longer.

Could you set the preferences to simulate the current behaviour of "shuffle" if it didn't appear as an explicit option?   i.e. if you set "Very recent period" to 0 would that effectively be shuffle?  If there was a series of obvious settings that would duplicate shuffle semantics exactly as it is now, then I'd support the removal of the explicit "shuffle" option.

Hi Alex,
  I don't think that it is possible to simulate 'shuffle' exactly based on the settings of the random weighting; the two algorithms are rather different; I'm also up for adding a description of the options if we can find an easy to understand description.

  Shuffle really is a shuffle of the pack of items; it takes the whole pack, shuffles it and then plays through the shuffle in order - it only does this shuffle once.
  Random does the random weightings as it selects each song.

Now you would think if you wanted to make sure you didn't get repeats you would want 'shuffle'; however I was finding on shuffle I was getting what appeared to be repeats - and I'm not 100% sure why; I looked at the shuffle code and couldn't find any obvious errors.

What I think happens is that the shuffle code redoes the shuffle every time you restart or I think under certain UI actions (e.g. selecting an album or perhaps changing the sort order?) - and since it doesn't hold any state between shuffles it's entirely possible the new shuffle will have a track you heard very recently near the beginning; (This still seems unlikely - but shuffle did seem to be being a bit repetitive for me and it's the only reason I can see).

The random stuff does the calculation on each song and since it has the 'last played' date is a lot less likely to repeat as long it is suitably weighted.
The only downside I can see is that it is possibly computationally a bit expensive compared to shuffle which does it once.

The weighting needs a better algorithm as well - my sliders currently scale the weights - but I think what is actually needed is something exponential to make it very non-linear.

Dave

*** Bug 451726 has been marked as a duplicate of this bug. ***

*** Bug 539202 has been marked as a duplicate of this bug. ***

Created attachment 122538 [details] [review]
Improved random patch (against svn 20081006 as in ubuntu - a little after 0.11.6)

I've just attached a new version of my patch - this one works on 0.11.6 (or the slightly after 0.11.6 Ubuntu has - but should patch on other versions) - and in particular fixes an important bug with the age and ratings bias (i.e. they didn't previously work) - it also removes some of the numbers from the dialog moving to more user friendly 'high' and 'low' as was suggested; I'm not sure i like that.

If you have the age bias full on and have any unplayed tracks you will get almost always those; I find about 25% of the way up (setting of 10) works nicely.

I really don't think this is the right way to go.

The play order system is fine for linear/repeat/shuffle, but beyond that it's too opaque and single-purpose.  We should be able to use the same algorithm to create random(ish) selections of music to transfer to devices or burn to CDs or whatever else, and this approach won't do that.

I only have a few vague ideas about how I'd like this sort of thing to work.  I'll try to post more about this to the mailing list or something.

OK I look forward to the description of those ideas; I do like the way this patch changes the random behavior for me - but obviously some of that is personal preference; but I really think it improves things - and it makes the code simpler in the end; it might be less useful for random on a small set of songs (say random over an album).

I'd rather not leave this without any improvement at all.

Dave

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/52.