Open Waffl3x opened 3 years ago
There's one major problem with this idea: by its current implementation, "random" mode doesn't actually choose a random next song; it only (internally) shuffles the queue. Each song gets played exactly once (a detail which is very important to many MPD users), just in random order. Even the priorities don't change that - they are a kludge so a MPD client can give some specific ordering, and override the "random" thing a bit, but still stay in "random" mode. So we can't say "play this song more often", because every song in the queue gets played exactly once. But what you can do is add popular songs twice, so they're going to be played twice in each queue run.
Thanks for the reply, and sorry for getting back so late. The way random mode currently works is important to me as well, and I wouldn't want this feature to change that. What I would want is for songs with a higher rating (weight) be more likely to be at the top of the internal queue when shuffled, and lower rating (weight) be lower in the internal queue when shuffled. When I have a chance I plan on submitting a pull request with the feature implemented, I'm just very much an amateur so I imagine that what I submit will only be good enough to serve as an example.
I guess going on about the priority feature made my request confusing, with the way it works currently does adding a new song to the queue reshuffle the queue, or does priority put a song to the top of the shuffled queue preserving the current ordering?
edit: I'm realizing where the miscommunication was, my playlist is several hours long (26 hours currently) and if I switch playlists it gets reset (obviously) so thats what I meant by more often/less often, since the higher in the shuffle a song is, the higher the chance is it gets played before the queue ends up cleared. This also makes me realize that this feature's usefulness is fairly niche as it assumes the queue is being cleared before all the songs in it are rolled over, perhaps I need to think about a better solution, especially considering that the longer the queue remains unreset the more frequently there will be lower rated songs.
Looking at this feature request and tools like ashuffle I wonder whether it wouldn't be helpful (and possible) to have a command that adds a random song to the queue (this could also be very powerful as an option for the findadd
command). I am trying to implement something similar to ashuffle and stumbled upon the same problem: without loading the whole library using listall
(which for good reasons is deprecated) it seems impossible to fill the queue with random songs.
myMPD has a jukebox mode that inserts random songs from the database in the queue. It uses reservoir sampling while iterating in steps through the database. This method avoids reading the complete database in memory. It uses the search interface with a window parameter.
Feature request
https://www.musicpd.org/doc/html/protocol.html?highlight=priority#queuing I spotted this while reading through the docs. I now realize it's intended purpose is more for promoting songs to the front of the queue. I initially considered developing a client to take advantage of it to play higher rated songs more frequently than lower rated ones. However, I realized it wouldn't work the way I wanted even if priorities were handled and saved by a client as it's specified to play higher priority songs first all of the time where I would want it to be played more often before a lower priority song, but not always before a lower priority song.
Once again in short, I want a song with a higher rating to be more likely to be selected, but lower rated songs to still be able to be selected over a higher rated song.
I would prefer this setting be stored with a playlist, but perhaps it could optionally be applied to the database. I also would not mind if it was non-persistent as it could be handled by a client and operate as I desire.
I'm reluctant to suggest this last part as I am not experienced enough to be sure this isn't the case already, but perhaps random song selection/separate song selection modes could be separated out to a plugin system.
For context on why I want this feature, I run a twitch stream and I had the idea of giving viewers the option of up voting songs they like to have them be played more often, and down voting songs they dislike and not have to hear them as often. This should have the added benefit of crowdsourcing playlists for myself as well. ;)
I wouldn't want this to conflict with the current priority system as I am going to implement queueing with the already implemented priority attribute. (Just as it was intended to be used.) I want my requested feature and queueing to be able to coexist as I will likely put immediate queueing of songs behind some sort of constraint while leaving voting open to everyone.
edit: I realized that random already functions in the manner I desire, I thought I had tested it but it seems I was mistaken.