View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000023 | MMW v4 | Now Playing | public | 2003-01-30 01:41 | 2024-03-12 14:13 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Target Version | 5.0.0 | Fixed in Version | 3.0 | ||
| Summary | 0000023: Configurable Shuffle functionality (current behavior vs randomize list) | ||||
| Description | Currently, the shuffle functionality has a couple of distinct problems: a) There's no way to know what song is going to be played next b) There's no way to know what song last played so users can't relisten to tracks that they might like (they can't find it) c) If the user turns off MM and then turns it back on, and continues playing a randomized playlist, they end up hearing songs that they've already heard recently (instead of the ones that haven't yet played). This complaint came in via e-mail. d) 'Shuffle' vs 'randomize' causes user confusion The following proposal deals with these issues (and includes all of the feedback/items raised in the comments until 10/30/03): 1) There's no need for a separate 'Randomize' function in the 'Now Playing' list. Clicking the 'Shuffle' button (wherever we decide to place it -- see bug 0002558), should randomize all the songs in the playlist (but keep the currently playing track as Track #1) 2) When 'Shuffle' is first enabled in the Player, it causes the contents of the NP list to be randomized exacly as 'Randomize' currently does, except that only those tracks subsequent to the currently playing track are randomized. i.e. it re-orders the tracks in random order, but that order is static--the tracks play in the order in which they are listed so that the user knows what tracks have played, and what tracks are going to play. 3) When 'Shuffle' is enabled in the Player then modifications to the Now Playing list work as follows: a) If tracks are queued (Play last) to the Now Playing list, then the set of tracks that have been added are randomized, but queued to the desired location. The implication is that if a single track is added, it is added to the location selected by the user. b) If tracks are Played Next, then the set of tracks Played Next are randomized, but insterted into the 'correct location' of the playlist c) If tracks are just Played, then the full set of tracks that are Played are randomized. d) Upon completion of playing the list of tracks in the Now Playing list, if continuous playback is enabled, the list should continue playing from the beginning _without_ reshuffling the tracks so as to prevent recently heard tracks from being played again (this alone would probably solve bug 0000829). 4) 'Shuffle' should be used in all cases to avoid terminological confusion. | ||||
| Additional Information | http://www.songs-db.com/forum/viewtopic.php?t=1631 http://www.songs-db.com/forum/viewtopic.php?t=1463 http://www.mediamonkey.com/forum/viewtopic.php?t=9881 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1092 | ||||
| duplicate of | 0018898 | closed | martin | MMA | Switching to Grid view in tracks triggers a crash |
| related to | 0011933 | closed | martin | MMA | It's easy to accidentally overwrite the current ad-hoc playlist |
| related to | 0002018 | closed | Ludek | MMW v4 | Auto-DJ: doesn't work correctly if shuffle is enabled |
| related to | 0000820 | closed | jiri | MMW v4 | 'Randomize List' should begin with currently playing track |
| related to | 0002822 | closed | jiri | MMW v4 | Ability to disable 'Shuffle' for certain tracks |
| related to | 0001273 | closed | petr | MMW v4 | Sorting isn't enabled for Now Playing (crash) |
| related to | 0005536 | closed | Ludek | MMW v4 | Now Playing scrolls by itself in cases where user wouldn't want it to |
| related to | 0006543 | assigned | Ludek | MMW v4 | Stop After Current behavior |
| related to | 0011625 | feedback | rusty | MMA | Shuffle mode: play order isn't displayed or retained |
| related to | 0014084 | closed | michal | MMW 5 | Add Play Random option on multi file selection ('Play to' option missing) |
| related to | 0013389 | closed | peke | MMW 5 | Now Playing: Improve handling of previously played tracks |
| related to | 0018776 | closed | Ludek | MMW 5 | Automatically retain X files in Playing list does not work when Shuffle is enabled |
| related to | 0018988 | resolved | michal | MMW 5 | Make Shuffle mode display track order (and related improvements) |
| related to | 0020503 | closed | michal | MMW 5 | Play on Info Panel doesn't add files shuffled when Shuffle is enabled |
| related to | 0020582 | closed | michal | MMW 5 | Now Playing List mode is different than Playing List mode |
|
|
Currently the behaviour is like WinAmp and I think it is correct. When you want to know previous song, you can do it a bit different way - go to Misc|Randomize list. |
|
|
I have to respectfully disagree on this one--Winamp is nice, but it was designed in this fashion because the Playlist is the _only_ facility it has for file organization and thus it _cannot_ dynamically make changes to the Playlist. In Songs-DB and other similar apps, the primary means of editing a playlist is in the 'Main Panel', whereas the 'Now Playing' view reflects what is actually playing. If you think about it from the user's perspective, they'll likely want to either: a) Mix up the order of what's playing b) Mix up the order of a current playlist If the functionality for both the 'Player' shuffle and the 'Now Playing' shuffle is implemented as in option 2) from the bug description, the user will not have to deal with the confusion caused by two slightly different implementations of a similar function. |
|
|
I still don't think that option 2) is a good idea. In my opinion "shuffle" is understood to randomly jump over songs. What I dislike in this solution is that just one click on the shuffle button would randomize the playlist, which is most likely what user would not expect. On the other hand, the option 1) doesn't look bad, it doesn't change anything immediately. I would think about implementing this one. |
|
|
option 1 is fine with me. fyi, in case you want to see an example of 2, Media Jukebox implements something like it. |
|
|
Ok, I think that option 1 would be a good default, some others can be configured in the options. |
|
|
I've thought about this issue a bit more, trying to think of a better solution that accounts for the following issues: 1) There are multiple means of randomizing the 'Now Playing' list of tracks: shuffle (via player) / randomize (via playlist editor). This is confusing 2) When 'randomized', the user should still be able to see what song is about to be played 3) When 'randomized', the user should be able to see what songs have been played prior to the current one This leads me to propose an alternate solution: -When the user clicks 'randomize' in the Now Playing list, it simply randomizes all the songs in the playlist (but keeps the currently playing track as #1) -When the user clicks 'shuffle' in the player, it causes: -Songs subsequent to the currently playing song to be randomized -Use the terminology 'Shuffle' in both cases to avoid terminological confusion. -Upon completion of playing the list of tracks in the Now Playing list, if continuous playback is enabled, the list should continue playing from the beginning _without_ reshuffling the tracks so as to prevent recently heard tracks from being played again (this alone would probably solve bug 0000829). Note: based on http://www.songs-db.com/forum/viewtopic.php?t=896, it would also be important to persist the Now Playing list, along with the last-played position in the list so that if the user clicks 'Play' after re-opening MM, it simply continues where it left off. 5/4/2004: Removed suggestion that all songs subsequent to the currently playing song to be randomized upon addition of any track(s) to the queue. This would cause unwanted/surprising changes to the NP list. 5/31/04: Note: Based on http://www.songs-db.com/forum/viewtopic.php?t=1856 it would be important that if 'Shuffle' is enabled and the user plays a track and all subsequent tracks, that playback of the double-clicked track proceeds, and only those tracks subsequent to it are randomized (this is pretty much in line with the above proposal). 10/03/04: Ludek made a hack/fix to Auto-DJ (see bug 0002018) to prevent Auto-DJ from working when Shuffle or Replay are enabled. This hack causes usability problems of it's own and should be disabled as soon as this bug is fixed (solving this bug eliminates the root cause of 0002018). edited on: 11-03-03 09:12 edited on: 05-06-04 13:44 edited on: 05-31-04 22:33 |
|
|
Pushed to 'high'. |
|
|
btw, Shuffle mode on the iPod is a good example of how this should work. |
|
|
Assigning to Jiri--I've reviewed this and think that it should be implemented as specced. |
|
|
1. When Shuffle is being turned on: - An item ‘Undo – Shuffle’ is added to Undo history list with the state of NP before shuffling, so that user can always return back. (this expects an improvement in 0001273 that I have already suggested) - If Player is Stopped (i.e. not Playing or Paused), all tracks in NP are shuffled, the one that becomes randomly the first one is focused and on subsequent start of playback it starts playing. - If Player if Playing or Paused, the tracks below the current track are shuffled. 2. When Shuffle is being turned off: - If there has been any change in Now Playing window since Shuffle was turned on, nothing happens, just Shuffle button is turned off. - If there hasn’t been any such change in Now Playing, i.e. ‘Undo – Shuffle’ is the last item of Undo history, the previous Shuffle operation is Undoed. 3. While Shuffle is already turned on: - When new set of tracks is going to be played, they are shuffled and added to NP. Other actions: - If user returns Undo history to ‘Undo – Shuffle’ item and undoes it, Shuffle state should go to ‘off’. - I wouldn’t rename Randomize to Shuffle – we would have two Shuffle operations with almost the same functionality. If we implement Shuffle as described, I’d say that Randomize can be removed completely and its functionality could be provided by a downloadable script (that could be named Randomize tracks – however some of our scripters could write it), just in case some users would need it. |
|
|
1b) I think you made a typo: i.e. it doesn't apply if the player is paused (1c) applies in the case a player is paused). 2) If shuffle is turned off, it would probably be unexpected/annoying for the playlist to automatically revert to its unshuffled state. Imagine if a user wants to disable shuffling because they want to play an album after a certain track in the NP list--if the NP list changes, then there's no way to do so. I think that if shuffle is disabled, most users would just expect that newly added playlists wouldn't be shuffled. I suggest not having this automated--we can easily add this if users ask for it. 3) To be clear: can I assume that you mean that the tracks would be added to NP _subsequently to the currently playing track_ ? |
|
|
1b) I clarified the sentence, it was meant correctly, but could be understood incorrectly. 2) My idea was that if user clicks Shuffle and turns it on, then he realizes that he actually wants tracks unshuffled, another click to Shuffle would fix it. I think that it would make sense, unless we decide to make Shuffle only one state button, i.e. there wouldn’t be any Shuffle On, Shuffle Off, Shuffle command would simply shuffle current tracks in NP a that’s all. 3) Good question, providing we don’t implement Shuffle as one state button, as I wrote above, it could work like this – depending on which Play command is executed: - Play – NP would be cleared and certainly all tracks shuffled. - Play Last – Tracks to be added would be shuffled and added to the end of NP list. - Plast Next – Tracks to be added would be shuffled together with all tracks following the currently playing track in NP. |
|
|
OK, sounds good (still not sure about 2)--hopefully it'll be fine). Assigning to Ludek. |
|
|
I'm not sure whether such shuffle functionality is a good idea. A couple of many problems: 1. If tracks are drag & dropped into NP above currently playing track then they aren't going to be played although they hasn't been played. 2. Re: 1) "When Shuffle is being turned on: If Player if Playing or Paused, the tracks below the current track are shuffled" - what if the current track is the last one in NP list? Therefore always when Shuffle is being turned on: all tracks should be randomized and the current playing one should become the first. 3. If user double-click a track that was already played (or skip back 10 tracks) he may want to re-randomize tracks to prevent playing the already played tracks below. Therefore one-state shuffle (Randomize List) would be better in such case so that he needn't to turn it off and back on at a time. 4. The 'Play next' and 'Play Last' would work in the same manner and this would be confusing. etc. Basically I tend to Jiri. The shuffle functionality that Rusty suggests should be one-state, but i.e. current 'Randomize List' command ( should begin with currently playing track) If a user need to know which random track was played last / is going to be played then he can use rather one-state 'Randomize List' otherwise current classical WinAmp two-state (on/off) shuffle can be used (as currently is). Summary: In my opinion the only that is really needed: 0000820 'Randomize List' should begin with currently playing track i.e. 0000820 should be re-opened and fixed. |
|
|
Assigning to Rusty for review my comments. |
|
|
This issue comes up over and over ( see it again here http://www.mediamonkey.com/forum/viewtopic.php?t=21249 ) . In terms of the last set of objections: 1. True, but user would expect that tracks prior to the current track wouldn't be played. User would have to disable/reenable shuffle, to reshuffle the list. 2. "Always when Shuffle is being turned on: all tracks should be randomized and the current playing one should become the first." I don't think this would be a good choice since it would prevent users from playing tracks that had recently been played (i.e. it breaks the 'back' rule). Nonetheless, I wonder if my proposal is overly complex and whether another solution is possible. So let me try to define the top level requirements and perhaps you can come up with something better/simpler. 1) If Shuffle mode is enabled, the user MUST be able to click the 'back' button and hear the last track again (or any of the x tracks played before it). 2) If Shuffle mode is enabled, it MUST function for new tracks in a manner similar to how it functions today. i.e. the next played track should be selected randomly from among those tracks in the NP list that have not yet been played. 3) If Shuffle mode is enabled, it MUST show users the playing track in the NP list (if it's enabled) 4) If Shuffle mode is enabled, it SHOULD allow the user to play the next track without randomizing it again. e.g. Pressing Back > Forward > Back > Forward would alternate between 2 tracks. 5) If Shuffle mode is enabled, the user SHOULD be able to see what tracks have played. 6) If Shuffle mode is enabled, it WOULD BE NICE to see what tracks are going to play. WMP: Implements 1 and 2 only Winamp: Implements 1, 2, 3, 4 iTunes: Implements 1,2, 3, 4 jRiver MediaCenter: Implements 1,2,3,4,5,6 . It's 'Shuffle' functions similarly to 'randomize' except that it also randomizes tracks that are added to Now Playing. The one limitation is that when disabling 'shuffle' the playlist doesn't revert. |
|
|
I would say that after fixing the 0000820 'Randomize List' should begin with currently playing track and after adding a 'randomize selected' option we will ensure _all_ 1,2,3,4,5,6 ! to be satisfied. Then we could add an shuffle option in Options panel where user could select the behaviour of the shuffle button: a) the new (one state) shuffle (i.e. current, slightly modified 'Randomize List') b) the current two state shuffle Releated notes: - The current shuffle could stay as is, but the 'back' button behaviour needs to be fixed (as users suggest, because this is _the_problem_ they complain on the forum). So in summary: i) Fix 0000820 'Randomize List' should begin with currently playing track ii) add 'randomize selected' option / command iii) Fix the 'back' button behaviour of current shuffle iiii) Add an option for users to select which shuffle behaviour they prefer. |
|
|
I'm correcting my previous suggestion, because I have got another (better) idea: Because we will need a play history anyway (because of iii) therefore we should use it also in case of the one-state shuffle: So in summary: i) Modified: i.e. The one state shuffle ( 'Randomize List') should not begin with currently playing track, but rather with tracks that have been already played, i.e. After clicking the shuffle the tracks are re-ordered this way: ALREADY PLAYED TRACK 1 ALREADY PLAYED TRACK 2 ALREADY PLAYED TRACK 3 ... CURRENTLY PLAYED TRACK RANDOMIZED TRACK RANDOMIZED TRACK RANDOMIZED TRACK ... (as you can see all your top levels requirements are satisfied - i.e. 1,2,3,4,5,6) ii) Removed: No need to add 'randomize selected' option / command iii) Stays: Fix the 'back button' behaviour of the current shuffle iiii) Stays: Add an option for users to select which shuffle behaviour they prefer. |
|
|
Another related link reported http://www.mediamonkey.com/forum/viewtopic.php?t=21658 |
|
|
Sounds reasonable. I would prioritize as follows: iii) IMMEDIATE/URGENT: Fix the 'back button' behaviour of the current shuffle iiii) URGENT: Add an option for users to select which shuffle behaviour they prefer. i) High: Modify the one state shuffle ( 'Randomize List') as described The question is whether item iii) can be fixed with little technical risk or not. Setting to 'immediate' for Ludek/Jiri to evaluate. I wouldn't want to include it in MM3.0 if there's a high risk of regression. |
|
|
I have fixed the iii) IMMEDIATE/URGENT: Fix the 'back button' behaviour of the current shuffle in build 1092. Setting as resolved for testing, if you will find a regression I can simply revert the code (couple of lines), but according my testing I believe that it is going to work fine. Note: It affects only prev button behaviour and only if you are in shuffle mode. |
|
|
Verified 1093. Re-opening for the future. |
|
|
Ok, I am about to implement the rest, i.e. iiii) URGENT: Add an option for users to select which shuffle behaviour they prefer. I am assigning to Rusty in order to decide where we should situate the option? I see a room on Options | Auto DJ / Now Playing where we could add Shuffle mode: [two state (on/off - like WinAmp), one state (randomize current list)] but we may probably need to replace "Auto DJ / Now Playing" by another text string. Rusty, please review wording and place for this option. Remainder: the one state shuffle mode reorders tracks this way: ALREADY PLAYED TRACK 1 ALREADY PLAYED TRACK 2 ALREADY PLAYED TRACK 3 ... CURRENTLY PLAYED TRACK RANDOMIZED TRACK RANDOMIZED TRACK RANDOMIZED TRACK ... so that user could see what track was played/is playing/is going to be played. And should be available via Undo command. |
|
|
The following attempts to summarize the original proposal + all feedback + integrate experience with the implementation of this functionality in recent versions of iTunes: Currently, the shuffle functionality has a couple of distinct problems: a) There's no way to know what song is going to be played next b) There's no way to see what song last played other than by pressing BACK to play tracks even if the user doesn't want to play them again (e.g. in order to rate the track or save it to a playlist). c) As a consequence of a) and b) pressing Back/Forward/Back/Forward doesn't alternate between the same 2 tracks d) If the user turns off MM and then turns it back on, and continues playing a randomized playlist, they end up hearing songs that they've already heard recently (instead of the ones that haven't yet played). i.e. the Randomization doesn't persist. e) There are 3 different types of shuffling atm: 'Shuffle' in the player (which has the problems described above; 'shuffle' in the various nodes, which behaves similarly to the 'randomize' function of the Now Playing list; and 'randomize'. This somewhat confusing since the first option works much differently than the latter two. Updated proposal 1) Clicking the 'Shuffle' toggle on (whether in the Player or via the NP toolbar) should randomize all tracks in the Now Playing list subsequent to the currently playing track so that the order of the tracks matches the order in which tracks have played, and the order in which they will play. If a track is playing, it should be the first track in the list following Previously played tracks. If no track is playing/paused, then all tracks are shuffled. 2) Shuffle toggle can be thought of as = randomize 'upcoming' NP list + items subsequently added to NP. For users who want to 'Shuffle all' we can add shuffle indicators to the NP list (similar to those in other nodes)--see item 5) below. 3) When 'Shuffle' is enabled, modifications to the Now Playing list work as follows: a) If tracks are queued (Play last) to the Now Playing list, then the set of tracks that have been added are randomized, but queued to the end of the NP list. This also implies that if a single track is added, it's added to the end of the list. b) If tracks are Played Next, there are 2 possible approaches; inserting a set of randomized tracks following the currently playing track OR inserting a set of randomized tracks mixed in with all tracks following the currently playing track. We should take an approach that's consistent with the approach taken at 0014084. c) If tracks are just Played, then the full set of tracks that are Played are randomized. d) Upon completion of playing the list of tracks in the Now Playing list, if continuous playback is enabled, the list should continue playing from the beginning _without_ reshuffling the tracks so as to prevent recently heard tracks from being played again. e) Toggling shuffle off/on would reshuffle the entire list f) Turning Shuffle off shouldn't affect the NP list as the behavior can't be consistent (e.g. in cases where the user shuffled and then edited the playlist). Similarly, undoing a NP list edit shouldn't undo shuffle mode. Note: When the user initiates Shuffled Play All (0014084), the effect is the same as activating the Shuffle Toggle except that the toggle isn't on. i.e. tracks that are subsequently added aren't shuffled. 5) MM should graphically show tracks that have played/skipped vs the track that is playing vs the tracks that will play so that users clearly understand which tracks shuffle applies to. In addition, one-time shuffles can be applied directly in the NP list. Possible approach: use headings in the NP list, and completely replace the list each time Play Now is used: e.g. Previous [shuffle--applies to all] -Track 1 -Track 2 >Playing Track 3 Upcoming [shuffle--applies to upcoming] -Track 4 -Track 5 ... 6) One downside of this approach is that Play History gets flushed from Now Playing each time the user starts playing a new set of tracks (Play Now). To limit this downside, I would suggest that the NP list Undo/Redo commands be simplified to just Undo/Redo so that users can easily go back and forward to see recent playlists in NP (rather than selecting particular undo/redo targets). |
|
|
As for the current state -- right, there are 3 ways to shuffle, each more or less different. It probably isn't good for a new user, on the other hand, it gives a user who _does_ understand these options full flexibility to achieve what he/she needs. So, I'm not actually sure, how to asses this, but I'd say that the current situation isn't that bad, considering MM is rather targeted to advanced users? As for the proposal -- generally speaking sounds as a good solution to me. Comments: 3e) Seems to be inconsistent with the rules above, where only tracks below the playing track are shuffled -- I'm not sure how to actually implement it so that it isn't confusing. I wonder whether this problem couldn't be resolved by modifying 1) as: 1) Clicking the 'Shuffle' toggle randomizes: a) Whole NP list in case the Player is in Stopped state. b) NP list _below_ the currently playing track when Player is in Playing or Paused state. 3f) re. Undo - Currently no matter what's done to NP, it can be Undoed. If implemented as suggested, a click on Shuffle would lose NP list order without a way how to undo it. I'd prefer an addition of this action to the Undo list. A click on Undo actually doesn't have to disable Shuffle, but should be able to restore the previous order of tracks in NP. 5) Not sure about this one, seems to be rather distracting to me (i.e. NP list is no longer a nice clean list of tracks). I understand the point, but would rather not do it. 6) Doesn't seem to be any problem, if we implement 3f) as I described above? Btw, I suppose that the Shuffle buttons (like in Album view) would remain unchanged and the Randomize command from the NP toolbar would be removed, or replaced by the new Shuffle functionality (a checkbox)? So, while I think that this could work, I'm not sure whether it's worth spending time at right now, I'd rather defer the decision to MM 5.1. |
|
|
e) True--the fact that there are different types of shuffling isn't the biggest problem on its own. It's just one other aspect of MM shuffling that can be improved by the proposal. 3e) You're right--I'd forgotten to edit that. Toggling shuffle on/off should just trigger the same behavior described in 1) (which is pretty much what you wrote). 3f) This was a misunderstanding. What I meant by "undoing a NP list edit shouldn't undo shuffle mode" is that if shuffle is activated and then the user presses 'undo', the playlist should revert to its previous state, but shuffle mode should remain on. 5) I think that a separation between Previously played and Current/Upcoming tracks would make it much easier to understand what is happening with shuffle active. See the attached image for an idea that is much more subtle. On the other hand, it might be too annoying to change the track numbers each time a track completes. Any other ideas? 6) The problem I was describing was the fact that the user has to use undo/redo in order to see flushed histories, and currently undo/redo is very difficult to understand because it requires users to remember the set of actions taken. Simplifying this to 2 buttons (undo/redo) would make this much easier to understand and use. To answer your question: yes--the shuffle buttons that appear for various nodes/views would remain. I'd keep the shuffle function in NP, but rename to 'Shuffle all'. We can defer this to 5.1 if it's too complex/risky, though I was hoping it might be possible. |
|
|
5) I don't see any image attached. Anyway, no, I don't see a good way how to do this, something that I'd like to have in MM. 6) I think that it's often useful to be able to return several steps in history and it's easy to do with the current implementation (in a single step, not multiple clicks). Ideally, as our MM global view history, there'd be a way to use either approach (currently as a right-click on the global Undo/Redo buttons), but I'm not sure how to implement this in the NP pop-up menu. We could trace this in another Mantis issue? 7) I wonder about turning Shuffle Off: Particularly if done right after turning Shuffle On, it'd be nice if also the NP reverted to the original order? However, what if there was an action done meanwhile, e.g. a track added to NP? Technically we could keep 2 copies internally, original and randomized, and after turning Shuffle Off return to the original, but I'm not sure whether it's easy enough to understand for an average user. On the other hand, if we don't do this, it looks weird to not revert to the original order after Shuffle Off. Thoughts? Without the complications from 7) it could be quite easy to implement, but I'd rather defer anything non-critical from MM 5.0 release, so that it's finished asap. |
|
|
re 7) I think it is completely ok to leave NP list as it is (i.e. shuffled) after switching shuffle off. I understand this as "from now on, do not shuffle tracks", any order reverting would be confusing for me. User could get back to older order simply by using Undo function of NP list. And as you mentioned, if user made some changes to NP list after switching shuffle on, it is not possible to say what is the correct unshuffled order. |
