View Issue Details

IDProjectCategoryView StatusLast Update
0015777MediaMonkey 5Playlists (Auto) / Search / Filterspublic2021-02-03 18:02
Reporterpeke Assigned To 
Status closedResolutionreopened 
Target Version5.0Fixed in Version5.0 
Summary0015777: Auto-Playlists: 'Selected by' doesn't support all fields that users would expect
DescriptionFor 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
TagsNo tags attached.
Fixed in build2186


related to 0014553 closedLudek Make auto-playlists with random order more persistent 
related to 0015773 feedbackrusty Auto-Playlists with multiple criteria limits are not supported or imported from MM4 
related to 0015776 closedpeke Auto-Playlist: Criteria Query order (Regression MM5) 
related to 0017365 closedLudek The new "Selected by" option is limited 
related to 0017486 closedLudek Auto-Playlists selected by random (auto-refresh) don't refresh in some cases 



2019-06-19 05:34

administrator   ~0053873

Last edited: 2019-06-19 06:08

View 3 revisions

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.


2019-06-19 12:23



2019-06-19 12:24



2019-06-19 12:25

developer   ~0053883

Last edited: 2019-06-19 16:07

View 2 revisions

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?


2019-06-19 15:30

administrator   ~0053889

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).


2019-06-19 15:35

developer   ~0053890

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.


2019-06-19 16:13

developer   ~0053891

Last edited: 2019-06-19 18:28

View 3 revisions

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.


2019-06-21 19:54

developer   ~0053923

Last edited: 2019-06-21 20:10

View 5 revisions

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.


2019-07-01 16:47

developer   ~0054034

Last edited: 2019-07-01 17:09

View 5 revisions

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


2019-07-10 21:07

developer   ~0054117

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.


2020-01-28 01:41

developer   ~0056291

Verified 2223

For now more than enough. Moved Initial Key to 0016308