James_I
(The truth is out there but not necessarily here)
1
I’ve been having an odd experience with Roon the last few months. The server is installed on Ubuntu server.
There will be extended periods where Roon is perfectly stable. Yes it will slow down because of these odd resource leak type things where a restart helps, but in general other than the occasional slowness it will be stable and play well for extended periods.
Then there will be a day - it may last for 20 minutes or an hour - where Roon is simply flaky. I’ll get the blue spinning circle. Endpoints will pause (and must hit play to restart). After a few of the blue spinning circle “waiting for Roon core” then sometimes the Roon server will restart. During that time Roon will stubbornly remain unstable, pause playback, restart the software (not reboot the Ubuntu server).
Ubuntu doesn’t report anything.
Then it seems to resolve by itself. There’s no correlation with anything on my network as far as I can tell. It happened to me this morning when everyone else in the house was asleep.
My server didn’t use to be like this - it was stable on Ubuntu for a good year. Then perhaps after some update (not immediately) this started. Been going on for a few months.
Yes i have.
When i disabled IPv6 on the Roonserver it was somewhat better.
But, i have a good reason to believe it is due to roonserver program itself.
All diagnostics on my network, the clients and the linux machine point in the direction of the roonserver program.
Just to be clear, i work with linuxsystems on a daily bases and have good knowledge of network routing and routed protocols and configuring Cisco and MikroTik equipment.
I bet it’s performing a full library update of metadata. It’s happened to me it brings the server to its knees when it kicks in for no reason. I created a ticket for it. I checked my logs after it was back to normal and it showed it was a full metadata update happening. It disconnected all remotes and stopped music playing. I could connect via other means to the pc so not my network just Roon maxing out one CPU.
Support seem to think it’s down to Roon tags. Do either of you use Roons tags a lot?
I do not use a lot of features Roon has to offer and i do not use tags.
The most used feature is Roonradio and zonegrouping and transfer.
My library is 114G with approximately 3500 songs.
Also in my case it has worked for years and suddenly i have stability issues.
New installations of roonserver with Ubuntu server 20.04, 22,04 and now 24.04 did not change the issue.
I have installed roonserver on different hardware and that did not solve the issue.
Hardware:
i7-7700T CPU @ 2.90GHz
16GiB
500GiB SSD disk
I will investigate further and open a support case.
I run 3 different locations with Roon server on Ubuntu Server 22.04. Two of the servers are fanless i7-13700s with 32GB main memory, separate SSDs for system+Roon and for music, the other i7-10510U, 16GB, single SSD for everything. 27k local tracks, 4.7k Qobuz. I may have encountered the issue once 6 months ago or so, for a short period, on one of these systems. I’ve not noticed any issue of that kind more recently. Maybe related, I have seen a couple of memory spikes over the last year, but mostly all the servers stay at 2GB (+/- .5GB).
James_I
(The truth is out there but not necessarily here)
6
Yes I use Roon Tags for almost everything. No artist or album isn’t added without at least 2-3 Roon Tags.
Maybe the factor then like it is with me. It shouldn’t really matter, you would think their own tagging system would work optimally with their own software. But alas like so many things in Roon it’s not as well
Implemented to scale as you would think.
Its depends on when Roon decides to do this full metadata update. As we have no controls for any of Roons scanning or metadata trawling it’s a lottery as to when it performs it. Bad luck it happens when you’re actually using it. They really need a schedular that the user can say do this maintenance at this time. Then the resources it hogs doesn’t affect your experience. Why trigger it in the middle of an evening listening session. Plex allows you to schedule different parts of its tasks, I can’t see why they never thought this would be a good thing for Roon.
You are not alone. Yes, I see this often
Sometimes several times a day. Other times it run for a few days without seeing this.
My server is on Windows 10 but if I check the Windows event logs after this happens, every single time I see a CLR stack overflow for process RoonAppliance.exe
I have been seeing this for many months now but only spotted the CLR stack overflow as a cause quite recently.
I see other people reporting similar issues on Linux hosted servers also although I have not tried a Linux server myself yet.
I have tried turning off background audio analysis and on-demand audio analysis as well as turning off Qobuz and disabling storage updates. It still happens.
I do not use Roon tags. I have a fairly small library of around 8000 tracks and I have Tidal and Qobuz servces but I do not add those tracks to my library.
I have tried running the server on a different PC and I see the same problem.
I also see a severe memory leak that accumulates over several hours or days until the server app has to be restarted anyway. I am not sure if that is related but a stack-frame being occasionally not recovered would likely leave in-memory objects abandoned (leaked) and would also slowly creep up stack-memory until it hits the end at 4MB so maybe.
It’s not the track analysis that causes it as that’s purely a one time process when music is added to generate waveform and work out the DR, it’s never done again unless you force it to do so or add new albums.
As far as I can work out it’s doing a full library metadata update and something during this gets stuck and cpu just gets pegged. I have also seen it get like this when restoring database and it’s doing all its initial matching when done it calms down.
As Roon does pretty much all its regular processes via one core of the CPU , audio analysis and DSP being the exceptions it seems to then stop any other communication from happening. It’s why single core speed is more important to Roon than lots of cores being available. But even here this doesn’t help when something is causing it to get the one core in such a state it doesn’t respond to anything.
James_I
(The truth is out there but not necessarily here)
11
I think there is something to this. It happened again last night. Restarting the software doesn’t help. Rebooting the server doesn’t help. It goes right back into the process that is causing the application to lose connection and crash repeatedly. You just have to wait it out. Once it’s done, it’s back to normal. Why it has to do this when I want to listen, I don’t know.
Yet another Roon quirk. I may have to build a second server so when the first one (which is a very powerful machine) is doing this, I can still listen. Or, just go to vinyl.
But why design something to do this? I know there are plenty of people that don’t have this problem, but Roon needs to find a way to not have its metadata processes, whether the issue is unidentified albums or whatever, not bring itself down.
I also have similar behavior and have had them intermittently for years now. It seems to be a moving target. I recall most saying it is a problem of the network or WiFi configuration. Or it was hardware issues. HDD vs SSD. But after that should be sorted it is tags, or unidentified albums, or having Qobuz linked, or having too large of a library or having lots of DSD or multichannel. It leads me to the presumption that Roon is just a finicky software. Works great for many users…and then a cascade of issues for many other users. It works well enough for me at the moment but still quite slow. I use ARC at work, which is much more responsive than the Roon OS at home (when it connects), but at home I play more vinyl and CDs lately. I will still watch this thread closely though. Sorry I don’t have any answers.
1 Like
James_I
(The truth is out there but not necessarily here)
13
It just feels like using Roon for anything more than casual causes it to hit capacity limits. Too many unidentified albums. Too many tags.
I don’t suspect any users have answers other than suspicions about the cause.
I stripped things down quite a bit last night when it was happening. Took all the endpoints offline. Closed down all the remotes but one. It didn’t matter. Roon wasn’t going to work until it was done with its process.
There needs to be a way to pause all database work if it’s interfering with simple listening. And no, I don’t want to post it as a feature request - seems like a useless process with too few votes to be meaningful. And why should I be asking for Roon to be stable…it’s not a feature request.
So, I was chatting with a colleague at work (not about Roon), and he described an issue he had for a while with his gaming computer. It would work fine for a while, and then start glitching. It would get back to normal, then glitch again some time later. He ran all the tests, diagnostics were perfect. Finally, on a lark, he replaced the motherboard SSD, and the problems went away. Not saying this is the case for you, but SSDs have ways of failing partially and intermittently that cause software to misbehave, and yet are not caught by common diagnostic methods.
Not sure unidentified albums has anything to do with it I only have 7 out of 34k tracks. Tags is something they mentioned in my support thread but I don’t really have that many of those either, although Roon doesn’t seem to have cleared up ones I removed years ago and don’t show up but do in logs… Which does raise many questions as to why their own tags cause performance hits like this.
Possible but I would expect it to also exhibit similar behaviour for other applications. I run Plex on mine as well and it doesn’t get this runaway behaviour. I also had occasionally on my other system running Rock. I may look to get another ssd to try and see if it’s this. But I somehow feel it’s not. It’s triggered purely at Roon metadata updates which I guess so have a lot of IO actions. But so does Plex on a full metadata update and I don’t get the same issue. Also only Roon is affected rest of system is fine and all other apps function normally. Surely all would show issues if the ssd has playing up at the same time Roon is borking out?
1 Like
James_I
(The truth is out there but not necessarily here)
18
I’ve done that for issues in the past and I am considering it now.
Main issues with that are (1) support’s suggestions have been, at least for my issues, cumbersome and time consuming - i.e. strip down your network, strip down your library, etc. and let’s see if the problem persists (not that I don’t see the logic in it, but it’s very time consuming) and (2) these problems come and go, seem to go for a while then return, new problems surface. It’s whack-a-mole. This problem didn’t exist 9 months ago.
Indeed. It’s a hard one as it only affects me when Roon does a full metadata update. Which is random and never at same time. No idea even how it schedules this. But I have seen it happen briefly when restoring my library and it does its initial identification. Looses connection for a few seconds then comes back. Checking at this time the same maxed out single core show up. Unlike the full metadata update which stops Roon server responding for a much longer period of time.
