View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014553 | MMW 5 | Playlists (Auto) / Search / Filters | public | 2017-11-24 09:51 | 2021-11-02 17:14 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0014553: Make auto-playlists with random order more persistent | ||||
| Description | Currently (same as in MM4) the auto-playlists with RANDOM or RANDOM ALBUM sort orders has different content on each load of the playlist. This is particularly problematic when: 1) User sync such a auto-playlists to a device/cloud, in that case another set of tracks is used on each sync resulting in some rather undesired and unexpected re-sync behaviour, see 0014520 for details 2) With MM5 auto-update feature. If a track is played or a track property is changed then there is auto-update mechanism that re-loads all tracklists contents on background and once the content differs (e.g. the track change affected auto-playlist content) then the tracklist is refreshed. Thus in case of the RANDOM auto-playlists the content is refreshed after each track change, because new set of tracks is always generated! Therefore it would make sense to make RANDOM auto-playlists persistent. i.e. the randomness would be used only when creating the auto-playlists, later the same content would be still used. In the future (or once needed) we could add a [Randomize] button to the playlist header so that user can change the order manually? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2086 | ||||
| related to | 0014520 | closed | Ludek | MMA | In some cases, hundreds of tracks are deleted unnecessarily |
| related to | 0014566 | closed | Ludek | MMW 5 | Default auto-playlists are outdated |
| related to | 0015777 | closed | Ludek | MMW 5 | Auto-Playlists: 'Selected by' doesn't support all fields that users would expect |
| related to | 0016471 | feedback | rusty | MMA | Wi-Fi Sync: Playlists fail to update correctly when select by 'Random (refresh all)' is used |
| related to | 0016472 | closed | Ludek | MMW 5 | Play Now for a node can trigger Playback of tracks different than those that are displayed |
| related to | 0017342 | closed | Ludek | MMW 5 | Limited auto-playlists does not retain sort order over DLNA (or when syncing) |
| related to | 0017365 | closed | Ludek | MMW 5 | The new "Selected by" option is limited |
| related to | 0017486 | closed | Ludek | MMW 5 | Auto-Playlists selected by random (auto-refresh) don't refresh in some cases |
| related to | 0017854 | closed | Ludek | MMW 5 | Play Shuffled triggers a change in order of AutoPlaylists set to Auto-Refresh |
| related to | 0018496 | feedback | rusty | MMW 5 | Manual reloading/refreshing of Auto-Playlists |
|
|
Fixed in 2084 |
|
|
1. As talked in thread making this fix even default Auto Playlists do not function and acts like Static Playlist as it is created on first load. "Favorites - 1 Audio CD Worth (74 min)" "Favorites - 1 MP3 CD Worth (650 MB)" 2. When browsing DLNA Auto playlists do not refresh 3. The only way I can see this fix is worth to be persistent is where such playlist is in focus and user Select tracks (current view) in witch case selected tracks should be copied into temp memory playlist for execution of command: a) BURN a CD b) Use Send to -> sync c) Play Now/Next/Last and other context menu should be persistent to selected tracks in view 4. There is no way in Sync to get new Limited Auto Playlists with random sort on every sync eg. When I drive to work each new day I would like to listen 5 songs from my MM library that I have never heard. 5. This also breaks cases where I use MM as Alarm Clock (Windows Scheduler) to wake me up by Playing Alarm Auto-Playlist that consist of one Auto-Playlist limited to 3 random Songs I like (5 Stars) but have not listened last 90 days and another Playlist that contain 1 random track with real high pitched alarm sound (Genre: Alarm Clock Sounds) 6. Even if we add [Randomize/Shuffle] button ut would not be available in Service mode |
|
|
4/5: I don't think so, if you have "unplayed tracks" auto-playlists and you play those 5 tracks in the car then the tracks won't be no longer part of the "unplayed tracks" auto-playlist and you will get new set of 5 tracks. i.e. the change in 2084 isn't degrading the use-case, but rather improving, because only the tracks that really were played will be replaced by unplayed. Previously all tracks have been replaced on each sync despite the fact they were played or not. I see the logic that users want to delete tracks that have been already listened in the device and replace it by new non-played tracks. This is working before, now and then (despite the change in 2084). I don't see the logic why user would want to needlessly delete unplayed tracks and replace them by new unplayed tracks on each sync without listening them. But let's wait to collect feedback during alpha stage and then decide whether this should be reverted or not. |
|
|
Complex playlists also do not work eg. Criteria: - Playlist A (Random 5 tracks of Rock) - Playlist b (Random 5 tracks of Alternative Rock) - Playlist C (Random 10 Tracks from 2000->2010) Sort: Random |
|
|
First I'd like to summarize my understanding of some of the issues re. handling of playlists in MM4: A) Users are confused by the language 'Sort', as it implies that the selected tracks are sorted a certain way and doesn't convey the fact that it affects which tracks are actually _selected_. B) Even aside from the language problem, when the number of tracks are restricted to less than 100% of the matching tracks, the playlist is regenerated in it's entirety--rather than just regenerating the portion of the playlist that no longer matches. This isn't normally a problem, but it is an issue when using a playlist to sync tracks as it results in many tracks being resynced unnecessarily (i.e. tracks that still match the playlist criteria may be deleted). Solutions: A) The first issue can be rectified by changing splitting 'Sort' to 'Select and sort by:' (note: this will be superceded by 1)v) below). B) Ludek solved the second issue via an implementation that persists the random setting, as described below (per my observations): . i) Upon creation the playlist is randomized as in the past . ii) When tracks no longer match the playlist criteria (e.g. because they've been played and the playlist only includes tracks not yet played), then they are automatically removed from the playlist and tracks are randomly added to the end of the playlist to fill in the 'non-matching' tracks. . iii) To trigger a trigger a 'reset' of the playlist i.e. to reload it afresh, the user must ?? -- I couldn't figure this out. Shuffle simply shuffled the existing tracks (as expected), while F5 didn't trigger the playlist to reload. Shouldn't F5 trigger a refresh? Should we add a 'Refresh' button ? Problems with the implementation (raised by Peke/Martin): 1) Setting a constrained playlist to 'Random' doesn't result in fresh tracks being synced in cases where the playlist doesn't have a rule that replaces recently played tracks. Although this can be rectified by adding a rule to not include recently played content, Martin indicated that this is a hassle for users. He suggested that users setting a random sort expect fresh content, and that perhaps playlists or sync settings should have options to refresh unplayed tracks that match the playlist criteria. e.g. one of the following: . i) For each auto-playlist, include an option to [ ] Auto-refresh . ii) For sync, include an auto-refresh option. e.g. in the sync settings > options > playlists, provide users with an . option to: . [ ] Completely refresh Auto-playlists on sync (Disabled by default for any fresh installs). . iii) Allow the 'old' behavior if desired globally if desired. e.g. in Options > Library > Tags and playlists: . [ ] Continually refresh auto-playlists (disabled by default for fresh installs) I don't think any of these are particularly good options, though, since they basically revert the new behaviour ultimately confusing things. An alternative approach would be to facilitate the creation of rules that replace recently played tracks. e.g. . iv) Pre-create alternative mechanisms that allow users to easily configure playlists that replace recently played tracks without having to create a new rule. e.g. . [ ] Limit to _____ [[Files]/Minutes/Hours/MB/GB] Selected by: [Random track, Random album, Highest rating, Lowest rating, Most recently played, [Least recently played], most often played, least often played, most recently added, least recently added] . Sort by: [None, Random, Artist, Album, etc...] . The above approach allows users to easily set selection criteria for constrained playlists for a limited number of the most useful criteria so that user can easily set playlists to be selected from amount 'least recently played' matching tracks. Note: we could list all sort criteria for 'Select by:' however, this would make it much less simple to select the most useful criterion. I believe that iv) is the the best way of resolving issue 1). 2) Auto-Playlists don't refresh over DLNA This could be a problem IF play history isn't correctly updated over DLNA. Ludek do you see this as an issue? 4) No way with Sync to get new Limited Auto-Playlist with random sort of tracks never heard before This is dealt with in 1) above. 5) Alarm clock usecase This is dealt with in 1) above. 6) See 2) above. 7) Complex playlists don't work. This would need to be fixed. No reason why they shouldn't work. 8) Peke made points about an issue that upon sync with MMA 1.0/2.0 that this change results in a loss of the users ability to specify which tracks will sync / be deleted / remain on the device. I don't understand this point nor how it relates to Ludek's change. From my perspective, if the user wants a set of tracks to remain on the device, s/he only needs to add a (auto)playlist to the sync list. For tracks to delete from the device, s/he needs to create an autoplaylist that contains criteria that results in certain tracks not matching the playlist. e.g. to auto-delete all tracks that are played, just define a playlist that contains 'tracks that haven't been played within x days' and tracks that have been played will be deleted (since per 2b above, auto-playlists refresh when they no longer match the criteria). Summary of recommended changes: see B)iii), 1)iv). |
|
|
1)iv) Should I understand it that [x] Limit to: [5 files] Selected by [Random track] would take another set of 5 tracks on each auto-playlist reload? Watching how other apps implements it, and when I specify this in iTunes then iTunes still persist those same 5 random tracks that were on the playlist creation. It persists also after iTunes restart. The only way how to get another 5 tracks there seems to edit the 'Selected by' dropdown. i.e. Making it different way in MM5 would still lead to confusion (probably the same confusion as in cases of 1i, 1ii, 1iii) Another idea I have is to introduce both the "random" mechanisms like this: Selected by: [Always random, Random track, Random album, ...] where the 'Always random' choice would behave like in MM4 (dynamic) and the 'Random track' would behave like in iTunes/MM5 (static). Though I feel it still isn't ideal and is still confusing, but maybe it is just about finding a better wording for the "Always random" choice? Maybe something like "Shuffle", "Mix", "Shuffle mix", "Mixed", "Always new mix" ? |
|
|
1)iv) Re. whether MM should load another set of 5 track on each auto-playlist reload, it depends on what you mean by 'reload'. If you mean that the user Presses F5 or the 'Refresh' button, then yes, a new set of tracks should load (per B)iii) above). If you mean that the user played 5 of the tracks and the user then clicked the auto-playlist then nothing should happen. On the other hand, if the user had chosen: [x] Limit to: [5 files] Selected by [least recently played] and the user played 5 of the tracks, and then clicked on the autoplaylist, then it should show 5 new tracks. Re. how iTunes implements this: it seems to be almost the same as your current implementation. The only thing that I don't like about the iTunes implementation that I prefer about yours is that if a track no longer matches a constrained autoplaylist, iTunes replaces the track with a new one, whereas your implementation deletes the non-matching track and adds a new matching track to the end of the playlist. As to your idea of selectively allowing MM5 playlists to behave like MM4, this is similar to option 1)i): . i) For each auto-playlist, include an option to [ ] Auto-refresh/reset The advantage of your approach is that MM4 playlists could be migrated to the new setting in a way that existing users would easily understand. Also, afaik, the Auto-refresh option is only valid for Random Playlists, so your approach should keep the UI cleaner. The disadvantage is that it might be confusing for other users as the best that I can think of is: Random track / Random track (refresh all) Random album / Random album (refresh all) What do you think? |
|
|
1i) The reason why I don't like the '[ ] Auto-refresh/reset' is that it would rather look like (with the checkbox disabled) the auto-playlist isn't refreshed once the tracks no longer matches the criteria. I guess it is what the '[x] Live updating' checkbox in iTunes does ( https://support.apple.com/kb/PH19487?locale=en_US&viewlocale=en_US ) ? The same problem I see with 1ii), 1iii) B)iii) OK, we could refresh/rest it on F5 hit, the problem is that majority users won't never realize what 'F5' does (probably only by accident) and the Refresh button would be confusing in the same way as items 1i), 1ii), 1iii) for the reason described above. Therefore I tend to something like this (combination of A and my last proposed idea): Select and sort by: ['Random (permanent)', 'Random (variable)', 'Random album', 'Title', 'Artist', ...] ...though the optimal wording could be discussed. Further candidates could be pairs ['Random (stable)'/'Random (changing)'], ['Random (once)'/'Random (anytime)'] Also the text 'Select and sort by' should change just to 'Sort by' once the [ ] Limit to: checkbox gets disabled, i.e. the text should toggle based on the checkbox state. |
|
|
1) I agree with you that 1)iv) modified with the mechanism you suggest to allow auto-refreshing playlists via 'Random (modifier)' is the best approach for allowing some playlists to behave like MM4. i.e. . [ ] Limit to _____ [[Files]/Minutes/Hours/MB/GB] Selected by: [Random track, Random Track (refresh all), Random album, Random album (refresh all), Highest rating, Lowest rating, Most recently played, [Least recently played], most often played, least often played, most recently added, least recently added] . Sort by: [None, Random, Artist, Album, etc...] Note: - afaik, iTunes uses a different approach (static vs live) than what has been implemented and considered here (live vs live with complete refresh). - re. the wording, I think that Random track / Random track (refresh all) is the most understandable, but agree that this may have to be revisited. - in the implementation I'd proposed, 'Select and Sort by' is superceded by completely independent 'Selected by' and 'Sort' settings, and the 'Sort' setting is always active. i.e. regardless of whether or not a limit has been set, users may want to sort the resultant tracks in an order that differs from how they were selected. Re. B)iii) F5 is already used to do a reload of playlists (to do a reload of Auto-playlists OR a reload of static playlists that have been sorted differently). The only change here would be that a 'Reload' button would be added so that users would be more aware of the existence of the function. EDIT: when users upgrade to MM5 from MM4, 'Random' auto-playlists should be converted to 'Random tracks (refresh all)'. Default 'Selected by' option should be: Least recently played. |
|
|
1) OK, I agree that completely independent 'Selected by' and 'Sort' settings would be a further improvement and probably also more understandable than the current solution. I also agree that existing MM4 random auto-playlists should be converted to 'Random track (refresh all)', but for the default auto-playlists ('Favorites 1 Audio CD Worth', 'Favorites 1 MP3 CD Worth', ... ) we should rather use 'Random track'? Although watching the default auto-playlists they all seem to be quite outdated and should be replaced another default? Especially the "Audio CD" or "MP3 CD" playlists should be either removed or replaced by something modern. But that's probably for another issue -- entered as 0014566 B)iii) yes, F5 is there and existing MM4 uses knows it, but with MM5 the auto-playlist content is auto-refreshed on any track property change so there shouldn't be no longer a need for F5. Introducing 'Reload' button would be confusing then. Assigned to Jiri for a review of the above proposals and sharing his opinions and ideas. |
|
|
1) Independent 'Selected by' and 'Sort' settings implemented in build 2086. Resolved for testing. Some testing notes (of how it is supposed to work): Sort by: 'Random' works similarly like Selected by: 'Random track' i.e. the random sort is re-generated only once the settings for "Selected by" and "Sort by" is manually changed by user in some way. While the "(refresh all)" variants in the "Selected by" dropdown behaves like in MM4, i.e. it is always regenerating content. |
|
|
Closing as I re Verified in 2183 This works as designed, rest is handled in 0015777 |
