I’m sorry for the intrusion, maybe it was static as well under the hood but anyway it had the ability to shuffle the whole tag with all non-library tracks in playlists in this tag. And now it can’t.
That tag issue is a bug, and being addressed in that other topic you linked. This topic is about the 5k limit and has nothing to do with that bug.
The practical difference is that I want a random track delivered to the queue from a source and then removed from the source. Once the track is played another random song is delivered real-time to the queue until the source is empty of tracks. I don’t want a randomized static list. I truly want to be surprised with each delivered track. Does that make sense?
If we didn’t show you the queue, you’d be happy? You’d probably never make it through 5000 tracks, so is there any difference other than the fact that we show it to you?
The old behavior was static as well.
Both old and new implementations are the same random, and both were predetermined.
Even toggling shuffle on the queue predetermines the order. It’s still equally random, but you can choose to see what’s coming up if you want. If you don’t want to see it, don’t look
I am not doing a good job of explaining myself, so my apologies. I want roon to re-randomize between each delivered track and deliver a single track to the queue. I should only see one track in the queue. Before the next track is delivered to the queue, roon would randomize the source again to server up another track. In this way, I never know what’s coming next. I guess it’s like Bingo. The container is spinning, a number is removed from the container and delivered. The container spins again and another number is delivered until the container is empty - or in the roon world until I stop listening.
Sorry again, but I got the answer that you don’t consider it as a bug.
And what about 5k in the queue, I’ve already written before about the misadvantages of this approach:
- much slower and less responsive queue (in comparison with track-by-track shuffle);
- and if I click shuffle twice then I loose all my previous queue (only 3000 tracks from first shuffle left).
Yah but look at the bottom of the thread, it looks like a different report has nailed the issue, which is related to the add.
Shouldn’t that blow away all of the previous shuffle? If it keeps it around, that’s probably a bug.
It’s heavier on the display, but the point of the new method is to show the list.
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.
“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