Yah I get that you want to choose how the algorithm works.
I’m trying to find what the practical difference between your algorithm and what it does now.
If you want the surprise, you can chose to not look. For those who don’t want the surprise, they can look.
Ok, I must be driving you nuts.
Imagine a list of your tracks in a bag. You reach in, mix it up and select one and then play it and discard it. Now this track is no longer in the bag.
You reach in the bag again, mix it up, and pull out another track to play.
Remove the track from the bag and play it. Repeat until you are done for the night.
I don’t understand what you mean, because there is another unrelated issue at the bottom of the thread.
I’ll try to explain. I have tracks in the queue, already been played or not played, anyway I don’t want to lose them for at least a couple of days. But if I click Shuffle two times (including by mistake, because now Roon takes more time to start shuffling) all these tracks are gone and in the previous queue I can see only 3000 tracks from the first Shuffle click.
Another example: I used to love to shuffle all 1970s for a couple of hours, and then all 1980s. And it was a good queue without anything unnecessary. But now every time I’ve got these 3k-4k tracks skippings and losing all previously played tracks.
And it definitely works slower now.
@George_O_Brien Believe me, I understand what you are doing. We are doing the same thing in the backend now. Then we go 2 steps further. First, we grab all the tracks using your method immediately, without waiting for playback, which doesn’t change the randomness at all, it just changes when it happens. Then we line up the random pickings, and then we show you the first 5000.
It’s no less or more random than doing it your way, since fundamentally it IS doing it your way. The only difference is whether you see the list or not and what happens after 5000 track plays.
After hearing your way a few times, I’m thinking the thing you dislike is “knowing” that the order is pre-chosen, even if it was random.
If I have 1000 tracks in my library, and I hit shuffle once, you should see 1000 items in the queue. If you hit shuffle a second time, you will continue to see 1000 items in the queue, because the first 1000 are blown away. This is just how our queue works.
In your example, you should not see the 3000 from the previous shuffle, you should see 0 from it. If you see any of the previous shuffle in the queue, there is a bug. I just tried, and I get the behavior I specified.
If you shuffle in the 1970s, it’ll add a large number of tracks… after a few hours, you shuffle in the 1980s, and it should blow away the 1970s queue. I’m not sure I understand the behavior you want. It’s also unclear to me if you are trying to redesign how the queue works or if you are saying you want it to go back to the same behavior it was before the elimination of the shuffle mode of 1.7.
5000 tracks in your queue should not be slow if your system meets our minimum specs. This number was chosen specifically because the experience was good on our minimum spec Roon Core. What type of machine is your Core running on?
Let me check with support whats going on.
Danny, what I am trying to say is very different from what Roon is doing now. I understand Roon grabs all the tracks randomizes the entire source, and subset list of 5000 randomized tracks is delivered to the queue. What I am proposing is that you randomize the entire list as you are now, and present a single track to the queue - say the top of stack. Once that track is played, the track is no longer on of the original randomized list. You then randomize the remaining tracks again and serve up the top of stack track to the queue. Repeat the process until the list is empty of tracks.
I’m not sure what to say here, other than showing you the list and what happens after 5000 tracks, I don’t see the difference. The shuffle experience is the same.
Just don’t look at the queue. Problem solved. This is such a non-problem not worth Roon spending time on.
Though perhaps a way of customizing the amount added to the queue would make you feel better - increments such as: 0, 100, 1000, 5000.
it’s not a bad setting… it would let people with slower machines have better performance by adding less music to the queue.
i’ll bring it up with the team.
ok, last comment and I am done. I don’t expect this to be part of the product but Danny me to clarify so…
It’s not a matter of not looking at the queue. What I proposed means you never know what track is coming up next as randomization takes place between tracks. With each successive play the source list gets randomized and one track smaller. Perhaps this would be too heavy and non-performant.
Hmm, the queue always showed not only upcoming but also previous tracks, and it still shows them now. And all added to the queue remains in the queue. But since Roon adds the list of shuffled tracks to the queue and, I think, there is also some kind of global queue limit, now the queue shows not really played tracks but only the last 3000 skipped tracks from the previous shuffle list.
Normal queue:
“Twice Shuffle” queue:
I want to see the tracks that I’ve just played from the 1970s, a minute ago. But instead of this I only see the last 3000 skipped tracks from the 1970s shuffle large list.
Yes, my point is that it worked better for me in 1.7. And I’ve never experienced this problem with the queue before, because there were no such large shuffle lists in the queue. And I could shuffle from multiple bookmarks many times a day and could see in the queue all the tracks been played during the day.
My Roon Core machine is Mac mini MD388 (16 GB 1600 MHz DDR3 RAM, 240 GB SSD, macOS Catalina). But I mean that it also takes more time for Roon clients to open the queue now, on another Macs or iOS mobile clients.
Thanks a lot! 
go to sidebar → history – that’s your play history… the queue has a history that is quite short, as it includes skipped tracks. it’s mostly meant for “previous track” action to work… the sidebar → history is the full history.
Yah, I like @Charles_Peterson’s suggestion… that system should absolutely use a length less than 5000. It’s a 9 year old Mac Mini!
Of course I know about history, but it’s not the same. I’m used to seeing everything in one place and going back to some of the recently played tracks. And I never had so many skipped tracks in the queue before.
Yes, perhaps this option will solve both problems.
I appreciate your patience, Danny. Have a great weekend
