|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004669||MPD||Playlist||public||2017-03-19 12:52||2017-03-19 14:19|
|Platform||armhf||OS||Raspbian||OS Version||8 (jessie)|
|Target Version||Fixed in Version|
|Summary||0004669: Reset song priorities when re-shuffling the queue|
|Description||If priorities are set, they are not cleared/reset when re-shuffling.|
This means that the re-shuffled queue follow the same priorities again.
This feature request suggests to clear existing priorities when a new shuffled queue is set up (or maybe directly after playing a prioritized song).
|Steps To Reproduce||Have a playlist playing on random, currently playing song A.|
1. Make use of song priorities:
1a. Raise priority of song B and song C (with priority of Song B > C).
1b. Song B will be played next.
1c. Song C will be played next.
1d. Some arbitrary song D will be played next.
2. Reshuffle the playlist (e.g. toggle the random mode off and on or let the queue play completely, then start over).
3. In the new queue, the songs B and C are played first, then the rest of the queue is played in a random fashion. Steps 2 and 3 can be repeated infinitely.
|You did not explain why you believe your feature request is an improvement. I think the current behavior is just fine, and deleting priorities would be a surprising loss.|
Good point, I guess it comes down to what the idea behind the priority feature is in general.
For me personally, it is an on-the-fly, temporary "I like this song, so please play it now" modification of the queue that should not persist through multiple play-throughs.
The current behaviour suggests that some songs can generally be more important than others, so they should be played first every time. In this case, the priorities currently do not persist through a playlist change (since they are not stored on the hard drive).
This is about priority, not about importance. And yes, this is for the quick "play it now", which is volatile. Volatile as in: the priority gets dropped once that song has been played.
But you're trying to make it one step too volatile, and you still havn't named one single reason why it should be that way. You pretended to say something about it, but I just can't find a real argument in your pst.
I can see what you mean by "no real argument", it seems like this is a case of personal preference - I can't find a real argument for the current behaviour either.
My current use case is a small client that monitors the queue's next song and uses priorities to play songs that belong together (e.g. Song A's Intro and Song A itself) in the desired order.
So when it sees that either Song A's Intro or Song A are up next, it sets the priorities so mpd plays the Intro, then the song and continues with the queue afterwards.
However, when a re-shuffle occurs, the problem described in the feature request occurs. While this is not really a problem, I figured this request might be an improvement.
So the only argument is that for me, it is more intuitive if the priorities are dropped somewhere between the playback of a prioritized song and a re-shuffle.
The "re-shuffle" you're talking about doesn't exist externally; it is an internal implementation artefact. If you disable and re-enable random mode, MPD does not know (or remember) whether the internal ordering is already sufficiently shuffled, therefore it just shuffles it (maybe again). This implementation detail has nothing to do with song priorities, which is externally visible.
And remember: song priorities are re-shuffle input parameters. The operation shall not delete its input parameters...
There is one place where this "re-shuffle" IS visible: when the whole queue has been played completely. Then the user expects MPD to use a different order the next time he plays the queue. And that is exactly the situation where MPD already resets all song priorities! (They have already been reset when each song has been played.)
I just tested the priority reset when the whole queue has been played completely, it does not happen for me. I did the steps to reproduce and used a complete play-through in step 2. In the next playthrough, the priorities were still there. I am on 0.20.6.
Regardless, I think that toggling random mode off and ending a complete play-through should have the same behaviour regarding priorities (and the random mode in general).
A different situation would be when the user sets priorities while mpd is not in random mode. Since priorities only apply in random mode, the user expects the priorities he set in non-random mode to be followed once he turns the random mode on.
This case would still be as expected when priorities are dropped once the random mode is turned off (or the play-through ends).
In my case, with the current (intended) behaviour, I have to drop the priorities after playing a set of joined songs manually. I have to ignore the fact that priorities are dropped on complete play-through.
|2017-03-19 12:52||Fluggonaut||New Issue|
|2017-03-19 12:52||Fluggonaut||Status||new => assigned|
|2017-03-19 12:52||Fluggonaut||Assigned To||=> cirrus|
|2017-03-19 12:52||Fluggonaut||Tag Attached: queuing|
|2017-03-19 12:55||cirrus||Note Added: 0010438|
|2017-03-19 13:14||Fluggonaut||Note Added: 0010439|
|2017-03-19 13:22||cirrus||Note Added: 0010440|
|2017-03-19 13:40||Fluggonaut||Note Added: 0010441|
|2017-03-19 13:47||cirrus||Note Added: 0010442|
|2017-03-19 14:19||Fluggonaut||Note Added: 0010443|