I think not.
After update to 2.66, Roon was behaving great for 48+ hours. I made some changes to the library, e.g. removed some obsolete Qobuz albums and replaced with newer versions. Now Roon is slow again. So how come Roon seems to work great after almost every update and then grinds to a halt after a few days when there are changes to the library?? My local network and internet connectivity are fine and no other applications have issues except Roon…
Getting ready to update. Has anyone had any issues addressing an VSSL multichannel Amp with airplay 1? Thanks
Have I misunderstood , I thought Roon at start up pre-loads “large portions” of the database so that requests, queries etc use in memory stores rather than reading from disc. Doesn’t this constitute a cache . After that any commands are to load the selected track/album and play
Equally my understanding is that Roon maintains a minimal buffer so as to better sync zones. For example you can set up JRMC to load a whole album to RAM and then play from RAM
In my case the subject of server restarts is moot , many years ago I lost most of my Hi Fi to a direct lightening strike on a neighbours tree, whenever it gets imminent every thing is unplugged . This means in our (South Africa) summer Roon is restarted daily. In view of overnight storms it is powered down overnight as well.
Honestly I have put down my trouble free experience with Roon to this practice.
It begs the question what harm can be done to Roon as long as the shut down is done properly , ie not just yanking the plug. The only harm I can see is if you are in the middle of a database write ?
ROCK/NUC is a musical appliance NOT a production server .
But it is still pulling much off servers through network traffic - whether that data is served directly or through CDN. My thought was to see if much more could be cached, outside of the Roon database to avoid that becoming corrupted etc., but a separate cache on the remaining part of the on-board SSD.
The thread auto closed because you didn’t respond within 7 days…
This is the last post.
If you wish, I will reopen the topic.
I hadn’t realized monitor for a few days meant that the topic would be closed after 7 days with no response, but thank you for paying attention to my feedback. 2.65 definitely improved things, but my sense was connecting was gradually getting worse again. 2 days ago the lag became ‘I give up’ and last night I ended up having to do a hard reboot since a soft reboot didn’t work. Connection pretty good again with the endpoints I’ve tried. It does seem I’m not the only person experiencing similar issues.
I’ll reopen the thread so Roon technical support run another diagnostic report for you. Be sure to provide an update there.
You’ll see this after the last post in all open Support requests.
This is not a technical report, but I have gathered based on my own usage that certain database like functions still create a slow down, even though I didn’t see that there was a drastic uptick in resource usage in terms of memory and CPU.
for example, Roon seemed to be behaving reasonably well until I ran a backup. Clicking start on the back up immediately disconnected all of the remotes and Roon never really recovered. It was very slow and laggy until I restarted the software. It is odd that resource usage didn’t seem to spike while it was so slow, but it definitely was slow and actually struggling. Roon does some really flaky things in that state…
Hello!
Since the issue still exists and I hope it will be fixed in future versions, I’m looking into automating server restarts.
There’s no native feature for this, but you can control ROCK using terminal commands, for example:
curl -d "{}" http://rock.local/1/poweroff
to shut down the server.
So, all you need is a server on your home network that can schedule the required terminal command to the ROCK server.
In my case, this role will be played by NAS Synology, which has a convenient Task scheduler capable of executing terminal commands.
I configured the command
curl -d "{}" http://rock.local/1/restartsoftware
to run early in the morning, after the server has completed background tasks and backups.
This resolved the issue with Roon gradually slowing down, without having to manually restart the ROCK server.
But I still believe and hope that this issue will be fixed in future updates!
My NAS running Roon Server is on an energy schedule so shuts down most of evenings (whenever I am not manually stopping from that) and reboots every morning. So I am not the ideal user to judge performance degradation over time, but I noticed two things:
Yes, when my server was hosted on nas and had a scheduled sleep schedule, I didn’t encounter this problem.
After moving to nuc, gradual slowdowns began.
I built a small local Roon Log Watcher specifically to be executed on macOS. Linux should work as well, but I mainly developed and tested it on macOS.
The purpose of the tool is to provide near real-time monitoring of all major Roon logs on your Roon server (in my case a Nucleus). If you experience issues while using Roon, the watcher shows what is currently being logged and can help identify potential causes that appear exactly at that moment.
The tool monitors:
RoonServer
RAATServer
RoonGoer
Features:
Near real-time log monitoring
Optional display of all log entries
Configurable polling interval (down to 1 second)
Detection of anomalies and warning situations
macOS notifications for important events
Special events such as:
Server restart / startup / shutdown
Database issues
RAAT disconnects
Audio device lost
Network issues
Exceptions or crashes
are routed to the macOS messaging/notification service and displayed in the upper-right corner of the screen. I do not know if and how notifications behave on Linux desktops.
Requirements:
Node.js installed
SMB mount of your ROCK/Nucleus Data share:
smb://NUCLEUS/Data
Installation (run once):
npm install
npm run init
npm run diagnose
Execution:
npm run start:all-fast
Alternative example:
node app.js --all --interval 1
This is an unofficial hobby project without any warranty or support, but maybe useful for troubleshooting and understanding what is happening inside a Roon environment in real time.
Link to Github: Roon Log Watcher
I agree completely! My experience is that initial performance was much quicker RAM usage on my M1 silicon Mac Mini core with 16GB RAM dropped from aan average approx. 2.65GB for the Roon Appliance (plus change for the Roon Server and RAAT Server) but crept up steadily to higher RAM usage than before 2.65. An one occasion when Roon was unresponsive the Roon Appliance was consuming 30GB RAM on the core!!!
I have to reboot regularly and get frequent login failures to Tidal & Qobuz after COre reboots. There are also regular issues when switching to different content, e.g. Roon Radio is playing and then I switch to an album or other playlist and Roon just hangs with horizontal oscillating blue line of death. I regularly get Tidal media loading slowly yet have no issues using Tidal Connect for the same content to the same streaming path.
I really want things to improve and had such high hopes for this massive update, but there appears to still be issues with Roon prioritising it’s core (sorry!) function of takling music from the service and delivering the stream to the endpoint. If the library isn’t being updated or referenced there should be no impact on streaming content - if I was in a library reading a book I would fully expect others also to be able to read a book.
Hopefully what look like ongoing memory leaks will be fixed in an upcoming release. I consume all media from the Internet (Apple TV+, Netflix, Prime, Diosney+, network TV on demand and have near zero issues streaming 4K HDR content. If I stream the sam content using Tidal Connect when Roon is unresponsive there are no issues either.
The Mac Mini core and Auralic Aries G1 streamer are both hard wired at 1Gbps on the same switch and this is way more bandwidth than this requires.
This is not a network problem 
I am using DietPi (DietPi v10.4.2, Debian 13 “Trixie”, Kernel: 6.12.88+deb13-amd64) on an NUC13ANHi7 and have so far no performance problems with Roon.
Torben
I run Roon Server on a dedicated M4 mini with 16GB of RAM, set to reboot daily at 3 a.m. All my music is local now, just under 45,000 tracks on an SSD directly connected to the mini, though for years I had Tidal, then Qobuz.
I have zero issues and am seeing a significant speed increase in Roon’s performance. I have no doubt that the issues discussed here are real and wonder whether they are related to library size and data from streaming services.
Would say from own experience, streaming services rather not. Their data is integrated, and roon handles it well. Haven´t tried crazy numbers of added albums, though, and I noticed adding a lot of albums from Qobuz, might slow down roon temporarily, until the next metadata background check.
I am far from having a formula what puts stress on roon´s performance, but it is definitely not only the library size, but rather the structure. Albums with lots of tracks, zillions of assigned credits, interdependencies (typical for classical boxsets), lots of unidentified albums and artists, lots of merged artists, complicated folder structure, lots of non-music files like covers in the folders, these for me turned out to be library properties driving roon to despair overproportionally. There might be more factors.
Came to the latter conclusion about folders and lots of unrelated files, when in Support category, there was someone letting roon accidentally scan system files in the folder, which was bringing even the strongest machine to its knees.
Though some have libraries with over 100,000 albums and millions of tracks.
With Rock on an 8GB i7 NUC SSD, I have 5k albums and 40k tracks, including about 2k bootleg tracks which obviously can never be identified by Roon. Zero skipped files though.
With the latest version, audio still begins to drop out on my wired Linn endpoint just after 24 hrs of Roon uptime. Any use of Remote compounds the problem, whether clicking on Queue, or Album, Artist etc, the audio chokes, whether source is local or streamed. We usually have radio stations playing to 1 or 2 wifi endpoints throughout the day too, and they are generally reliable, unless/until Remote is used.
Since using the script referred above, to reboot every morning at 0500, Roon is running perfectly. With a trip away coming up soon, I needed Roon & Arc to be reliable in my absence.
I think it could be helpful to have a simple ‘Resource Monitor’ embedded in the admin webpage, to enable the user to monitor system health in real-time, rather than having to upload log-files and await analysis.
How about unidentified albums, that has always been blamed for slow running , I currently have only 47 albums but I have seen quotes of 20% or more where big bootleg collections are involved
The planned maintenance window should have fixed that as the re-ID process should happen in that window