I am having some issues with Shuffle that seems to be a discussion on the boards, but I cannot find a resolution if one exists.
In the Christmas Genre I have 153 Christmas albums. I am noticing that there are many songs that are skipped and never played and there are other songs that play all the time. For instance shuffling Christmas plays a lot of the Mahalia Jackson album “Sings Songs of Christmas” but never the Dolly Parton album “Once Upon a Christmas” There are lots of other examples, but all the same issue. Any suggestions and or advice would be greatly appreciated.
Thanks for that. I will give it a try. Also will try a Christmas focus list and see how that works. Hopefully Roon will work on their Shuffle algorithm. Thank you!
I’m coming from the other end of the spectrum and can’t seem to disengage “shuffle” in order to play the list of songs in the sequential order that they appear in my playlist. Greg
Hey Ged, Happy Holidays! I tried adding all of the tracks to a playlist and shuffle that. Shuffle exhibits the same issue of not playing certain album songs and repeating others. There appears to be a fundamental problem in the Roon Shuffle algorithm. This issue does not occur with iTunes most other players. Hopefully the engineers can work to resolve,
I’ve noticed that when shuffling a bookmark, roon sometimes pops up the track thumbs up/down dialogue, as if it’s using the same Vidalia or Valencia or whatever algorithm that roon radio uses.
Your observation seems to be further evidence of that, because there are numerous discussions about similar behavior in roon radio.
That is what I am seeing in genres or bookmarks. If I take all the albums and put them in a playlist it shuffles properly. Hope they will work on genres and focus bookmarks.
The essential problem is that people should NOT actually want a truly “random” shuffle.
Random outcomes can have clustering.
The chance of throwing snake eyes with dice is 1/36. Some people thus might expect snake eyes (using random outcomes) to happen every 36 throws. But reality is that you should expect short runs of sequential snakes eyes. And gamblers in a game of craps will sometimes bet on that.
Same for tracks in albums. If I have tracks from 15 albums people expect a song from the same album approximately every 15 tracks (even distribution). In reality, with truly random selection, you can have multiple tracks from the same album close together and tracks from other albums not played for a long time.
What I have is a script the shuffles M3U playlists but if an artistname or songname is randomly selected, but was recently played, it is left in the not-selected state and I repeat the random selection.
The result is intentionally NOT actually “random” - but the result is what I personally want in a “shuffle” with more even distribution of the artists.
The confusion between product developers and their customers is that the customers keep demanding purely random, which the developers implement, and then the customer complain about it being purely random (the natural clustering in a truly random selection).
My M3U shuffle script is a hack, written in Perl (my first attempt to program in Perl).
It is not written for general use and actually requires going to the code to change any parameters (such as file identification or the separation between repeats of same artist or same song name. It uses relative paths which makes it dependent on the location of the script relative to the files being manipulated.
The environment requires installation of a Perl package along with the installation of special Perl libraries (I would have to go back and identify the library setup).
And while it appears to function correctly (enough to be happy with playing my large Xmas CD playlist in an acceptable shuffle - though not listening critically), I have not done a complete testing/validation of function.
I am busy with some medical issues right now, but I will try to find time to review, cleanup the script, and write some documentation before sharing it.
Even then, it will take someone with Perl knowledge to get it working for them.
Perhaps someone with better honed programming skills could take this code as a start (or even take the fundamental logic/concept) and develop more of an end-user (non-programmer) friendly tool. It would be great to have this open-sourced.
What I would really like to see is -
ROON (and other digital music library management services) providing a shuffle function which avoids the clustering that would normally be expected in a truly random shuffle.
My basic logic is fairly simple:
(1) code that parses any identified M3U record and assign the fields to variables (one of the reasons I used Perl, along with the fact it would run on Windows)
(2) a “previously written artist” array/queue of limited depth onto which one pushes each artist name for songs that have been added to the output shuffle M3U.
(3) a “previously written song” array/queue of limited depth onto which one pushes each song name for songs that have been added to the output shuffle M3U.
[ The depth of the queues effect the delay before a previously written artist or song can be again written to the shuffled output. When an entry reaches the end of the queue, that oldest entry falls off (deleted) to make room for the next new entry. I set both queues to a depth of 10 ]
(4) An array which gets loaded with all of the entries of the input M3U file (used a special Perl I/O function library to accomplish )
(5) A main loop that terminates when there are no more songs in the input array
… (a) randomly selects song from the input M3U array, and parses it.
… (b) if either the artist_name or the song_name are in the “previously written” queues, new loop iterations with a different random record selected. (delayed-write case). Increment delayed-write count.
… (c) For a randomly selected input record which is not in the previously-written queues:
_____ i) write it to the shuffled output and remove that selected entry from the input array. & zero the delayed-write count.
_____ ii) push the artist name and song-name onto the “previously-written” queues (removing the oldest entry in each array)
…(d) If there are 10 delayed-write cases in a row, the next randomly selected input array entry is automatically written to the shuffle output and the input-array entry removed from that input array.
& delayed-write count is zeroed.
Hey @Michael_Arones, thank you for the suggestion! I’m happy to report that we have something similar in the works. I can’t provide a specific rollout timeline, but we’re on the case.
