View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015777 | MMW 5 | Playlists (Auto) / Search / Filters | public | 2019-06-19 00:32 | 2021-02-03 18:02 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015777: Auto-Playlists: 'Selected by' doesn't support all fields that users would expect | ||||
| Description | For Auto-Playlists Selected by in Limits can't be disabled or ignored there should be an option to Select NONE as User wants to handle that using Sorting. eg. Limit 100 -> Selected By -> NONE -> Sort -> Title -> Random | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2186 | ||||
| related to | 0014553 | closed | Ludek | Make auto-playlists with random order more persistent |
| related to | 0015773 | feedback | rusty | Auto-Playlists with multiple criteria limits are not supported or imported from MM4 |
| related to | 0015776 | closed | peke | Auto-Playlist: Criteria Query order (Regression MM5) |
| related to | 0017365 | closed | Ludek | The new "Selected by" option is limited |
| related to | 0017486 | closed | Ludek | Auto-Playlists selected by random (auto-refresh) don't refresh in some cases |
|
|
Selected by 'None' would imply that the first x tracks that match the selected criteria would be chosen. However, I'm pretty sure that in most cases that's meaningless. e.g. if the query is Tracks > 4 stars, restricted to 100 tracks, selected by 'none': what does that mean? Does it mean that 4 star tracks are shown first? Does it mean that 5 star tracks are shown first? That's why this option wasn't shown. It might be a good idea, though, to add a couple of other fields. e.g. Date (most recent) Date (least recent) Original date (most recent) Original date (least recent) If we find that users consider the above insufficient because they can't select on certain other fields and/or because their MM4 playlsts don't work as they did previously, then we can change the implementation so that users can Select by the same fields as they can sort by. e.g. [ ] Limit to x . . . Selected by: _ Date_ _A..Z_ - + Sort by: _Random_ - + I personally think this might be overkill, but I can understand that some users may be annoyed if their autoplaylists don't work the way they expect upon upgrading, and with this change mm4 auto-playlists could be imported and work the same way in MM5 by having the MM4 sort used for both MM5 Select by and Sort. |
|
|
If I got this Correctly then after change MM5 will translate MM4 Search/AutoPlaylist in this way. If that is True then 0015776 , 0015773, 0015774 will be resolved? |
|
|
That's not quite what I was suggesting. I was saying that _if_ we decide to implement this (Ludek will have to look at this), that MM4 sort settings that are imported into MM5 would appear in _both_ Selected by: and Sort by: (which would result in the exact same behavior as MM4). |
|
|
Yes, transferring the first sort order into the "Selected by" (while MM4 > MM5 migration) makes sense, or at least transferring for the fields that currently exists in the "Selected by" list. Enhancing the "Selected by" list by the suggested fields also makes sense. |
|
|
Ludek, that is exactly, what I pointed. None would be used for fields that do not exist in Selected by so that Sort takeover as it would behave like in MM4. Later we can easily expand behavior if more fields were needed. |
|
|
Date (most recent) Date (least recent) Original date (most recent) Original date (least recent) => added in 2184 The conversion from MM4 is also implemented and currently works this way: If the corresponding 'Selected by' is found for the corresponding MM4 sort then it is used, otherwise the default 'Selected by' is used (which is 'Least recently played') I just think of whether we shouldn't add also further fields?? Namely we should consider at least these three: duration (song length), bitrate, BPM I can imagine that DJ wants to select by "highest bitrate", "highest BPM", "lowest duration" Assigned to Rusty for wording and evaluation of these three fields. |
|
|
Rusty's reply over IM: Re 15777, sure, just use the same convention as for the others e.g. Duration (longest, shortest), Bitrate (highest, lowest), BPM (highest, lowest). Assigned to me for implementation. I'll also add 'Skipped (most often)', 'Skipped (least often)' => added in 2186 |
|
|
Verified 2186 I would also add "Initial Key (highest, lowest)" as it is new Metadata field supported in MM5 and is essentials for any user that wants to use MM5 along with DJ apps and or create playlist that contain tracks for Harmonic Mixing. |
|
|
Verified 2223 For now more than enough. Moved Initial Key to 0016308 |
