Look into “modern standby.” AKA “connected standby.” This is apparently a win10/intel hidden sleep mode that is difficult to control or turn off.
Even if you specify “never sleep”`in power settings it seems to get triggered if the screen sleeps. Setting the screen to “never sleep” may help but I’m not sure because I gave up on it and moved the server to an older pc that doesn’t have this “feature.”
P.S. I discovered this from looking in event logs and seeing entries for “entering connected standby” even though I had “never sleep” set. The other clue was that if I woke the screen everything started working again.
1 Like
James_I
(The truth is out there but not necessarily here)
23
I am starting to think that using Tags is the performance issue. It seems to be worse when I shuffle a Tag versus use Roon Radio or manually create the queue. I have a suspicion that ANY Tag usage, or use of indirect Tags (i.e. Tag an Artist, then shuffle - it plays Tracks not Artists and thus is translating from the Artist to the Track) in a shuffle as well as a focus could be what is creating that overhead.
Yes, but perhaps not to shuffle them or in queries the way I use them, which is a smart-playlisting type of use.
I get the internet Radio Stops and my network is pretty solid. My primary endpoint is a Bryston BDP but the other day the core would not play anything to my 2 Sonos endpoints. The interface/app indicated it was playing and the device appear on the screen but the DAC is showing nothing coming through. Reboot fixed it.
I’ve ALWAYS experienced the inevitable slowdown that forces me to restart Roon’s core every few days in order to have a responsive system. The heavier the usage the faster the need arises. I’ve also always had a very large library but running on Linux.
James_I
(The truth is out there but not necessarily here)
27
Do you use tags to create your queue? Just trying to zero in on what the restarters may have in common.
The memory leak is well reported and observed by people and I just reboot the Roon server once a week now to get around it but Roon still insist on blaming the network.
There are douzends of threads reporting memory leak issues. Does Roon relly adress them? No. they‘re all still there. Blaming network is much simpler. Quite disrespectful towards the impacted paying users.
Nope. I have tags, but I lay to be able group albums by individuals that recommended them and to rattle off recommendations to them. If Roon gets social interaction among listeners that’ll change.
James_I
(The truth is out there but not necessarily here)
31
I am just wondering if, when one shuffles a Tag, that is basically a Tag focus query for each track, thus what is causing the core to slowly degrade until restarted.
To explain further, my main method of listening is to group Artists by Tags. Something like “Sunday morning easy listening” versus “Friday night thunder” or whatever. So I’ll have a Tag with 200 Artists in it. Those Artists will represent maybe 500-1000 albums and thus 6000-12000 tracks. I’ll shuffle the Tag. I wonder if translating an Artist Tag into tracks that are shuffled are each Focus “queries” that little by little slow Roon down just like how direct Tag focus (using Boolean combinations) slows down Roon very quickly, and how Roon used to completely choke on multiple searches.
The choking on searches seems to be “fixed” but I wonder if all that happened was just pushing the issue deeper into the Roon engine and this is one symptom?
The main point is, there is nothing special about my network. There’s one switch between my Roon Core and my FLAC files. There are two switches between the Roon Core and some of my endpoints. But it runs quite peppy after reboot, and only slows down over time.
If it is a network problem, it would not so TOTALLY RELIABLY slow down over the course of a day, then completely reliably work well after restarting the core, then repeat the process. If it were the network, restarting Roon wouldn’t help.
I never use tags to queue tracks; I exclusively listen to albums which I find looking up composer-artists. Even so, Roon slows down after 4-5 days, using ever more memory, until I restart Roonserver to bring things back to normal. What I have noticed, though, is that the point of unusable crawl is approached much faster, when I search a lot, or insert many new (Tidal) albums into my library.
Thats how it used to be. Now, once you start using filter, you can kill that cat with no more than 2 filters in 3 minutes. But it will take 20 minutes to recover from it…
This is quite interesting, I have quite a few Tags, but most are small groups, so I just used Cntl-A to Queue up all my Tags, let’s see what happens, the question is how long can I go without wanting to break the chain to play something I read about in What We Are Listening to 2021
Memory leaks have multiple sufficient causes. The memory leak reports are taken seriously and they are being investigated. I’m not a programmer’s bootlace but I understand memory leaks can be insidious and difficult to identify. Roon are not ignoring this issue.
If you mean address the reports by responding to them then I’d agree that Roon staff don’t necessarily respond to issues on the Forum. Maybe there could be a more centralised communication to users of issues that are under investigation. In the Support category anything marked [Ticket In] means the issue has been replicated and a fix is in the works. I’m not sure what expectations [Under Investigation] would create. Some bugs have gone for many months or even years before they could be reliably replicated.
