Is the affected network Zone connected with Ethernet or WiFi?
· Ethernet
Does the issue affect all file formats?
· The issue affects *multiple/all* file formats.
Does the issue happen with local library music, streaming service music, or both?
· *Both streaming and local* *library* music are affected.
Do you encounter any playback errors with the "System Output" Zone?
· I don't have a System Output available, but I'd like to keep troubleshooting
How is the affected Zone connected to your RoonServer machine?
· Network - Ethernet
Which network audio protocol is the Zone using with Roon?
· RoonReady
Does the device show up at all in Roon Settings -> Audio?
· The Zone is listed under the wrong protocol
Does the device play audio from another source when using the same connection?
· The device has no problems with another audio source
Have you checked that Roon is whitelisted in any firewalls?
· I've checked the firewall and the issue remains
If the device has multiple output options, do the other options work as expected?
· Multiple output types are affected
Is the device using the latest firmware as per the manufacturer?
· Firmware is up-to-date but the issue remains
Do you have an approximate timestamp of when the issue last occurred?
· Latest is today, 2025-10-19, at 08:58. But there are multiple occurrences.
What are the make and model of the affected audio device(s) and the connection type?
· Bluesound Node N150, using RAAT
Describe the issue
Please ignore the answer in guide regarding System output (it's not relevant). I had to pick it not to get to "Excellent, problem solved!" in this guide. It's really difficult to get in touch with you - and all I want is to tell you that there's an issue that started occurring in build 1559 and that I have all the relevant logs read for you.
Describe your network setup
TP Link Mesh but the affected Bluesound Node is connected via Ethernet to the main mesh node.
Clarification: also this answer is there just to get past the guide.
Does the device show up at all in Roon Settings → Audio?
· The Zone is listed under the wrong protocol
In reality the zone shows up correctly as RAAT. All zones are enabled, there’s nothing strange in the UI.
This started happening in build 1559 and I also notice unusually high resource use (both memory and also cpu) resulting in high ‘load’ values in my Ubuntu Server. They drop instantly as I restart systemd’s roomservice.service.
I have the same issue with my music server since updating to 1559. Music stops playing and I see extremely high CPU usage by the music server. Rebooting resolves the problem for a few days.
Thanks for reaching out. Just to clarify, the symptom you are experienecing here is that some (or all) of your devices are disappearing and the issues occured during the screenshot you provided? You can upload logs to the below link, and please let us know once uploaded so we know to check:
That’s right, the devices are disappearing, which leads to playback being interrupted. The playback does not resume after a while either (so it doesn’t look as buffering issue). My remote devices (iPad, iPhone) can’t reach the server for a while either, it takes some time for it to reappear (I see the “Trying to connect to you Roon Server” message).
In addition, I can see high load values on my music server. (Not sure which logs to provide for that, but I guess you can see RoonServer’s memory usage growing overtime in logs provided.)
Anyway, the logs are uploaded. Logs names have changed compared to my initial screenshot due to logs rotation, you can look in these files:
Given that all this started happening in 1559, I’d love to downgrade to the previous build, which AFAIK is not possible. I really think that you should consider changing your policy and let (your tech savvy power users) downgrade their setup. I think that this could provide you with some valuable A/B-tests.
Thank you for the update. We’ve collected all the necessary diagnostic data and forwarded it to our R&D team for further investigation.
I really think that you should consider changing your policy and let (your tech savvy power users) downgrade their setup. I think that this could provide you with some valuable A/B-tests.
We appreciate your feedback. Please note that this isn’t a matter of policy — there are technical reasons why Roon is not backward compatible.
I don’t want to speak too soon, but after a couple of hours of listening I did not have a single occurrence of playback stopping of itself. Feels good again! (Also, unrelated but it seems like you fixed the start crash that occurred on macOS 26.)
So given this update is what it looks like (keeping my fingers crossed!), I will be hesitant to upgrade in the future. I want nothing else but stability, as you surely understand, and given the fact that there’s no way to downgrade if an update turns out to make things worse, I will have second thoughts before jumping on the update train again.
Glad to hear that there’s been an improvement with the latest Roon release! Yes, please let us know how further testing goes. If you’d like you can make a backup of your RoonServer and Roon folder, this provides a full backup of the installation including currently installed version.
Then if you’d like to temporarily test a new build, you can exit Roon/RoonServer and rename current Roon/RoonServer folders to something else (like RoonServer_old), install latest build and see if that still works as expected, or switch back to the old folders if you are having issues with a new build.
Is the system still working as expected at the present time? Please let us know and we’ll go ahead and mark the thread for closure once we hear from you, thanks!
It does indeed look like build 1582 fixes the issues I’ve been experiencing in 1559. No more lost players and stopped playback.
In addition the CPU (Linux load issue) is gone too. The memory usage for RoonServer does seem to increase over time, day by day, but it’s not a problem on a dedicated server.
Overall: good job and thank you for resolving the very irritating bug in 1559.
