What kind of performance/speed issue are you experiencing?
· The app takes a long time to respond to commands
Please try to reboot your Roon Server
· Yes, rebooting helps, but the issue returns after some time
Please try to reboot your networking gear (Router/Switches/etc.)
· No, the issue is still the same even after a reboot
Is there any change in behavior if you try to navigate to Roon Settings -> Library and set both Background and On-Demand Audio Analysis to Throttled or Off?
· No, the issue is still the same
Does the issue happen on multiple Roon Remotes (controllers) or just one?
· Issue happens on multiple remotes
Router Domain Name System (DNS) change
· I was able to change my router's DNS servers but it did not help
What is the operating system of your Roon Server host machine?
· Nucleus
Which model Nucleus do you have?
· Nucleus+ Rev A
Timestamp of issue occurrences
· Slowness has been occurring constantly for the past several months (Jan, Feb, March). Noticing it right now: March 12 at 5:26pm ET.
Describe the issue
Roon is very slow responding to any command or search, and takes time to react to play commands
Describe your network setup
Frontier 1Gb fiber, TPlink routers and switches and wifi. Nucleus is connected via Ethernet. Everything else on my network works great except Roon.
Thanks for sharing your report! Could you please review your Roon Settings>Library>Clean Up Library / Skipped Files, and share a screenshot if you’re seeing any significant numbers here?
Is your Nucleus connected directly to your router?
Thanks for the quick reply. There are no skipped files. There were 25 deleted files in the library maintenance section and I cleaned those up.
The Nucleus is not connected to the router, it is connected to a switch in another room which is then connected to the router which is in a wiring closet. But I don’t think that is an issue - I remember testing it wired directly to the router a while back and it made no difference.
I have background audio analysis and background work scheduled for 1am-6am (I was hoping this feature would help, but it hasn’t).
I suspect this may have something to do with the large number of unidentified albums in my library. 5931 total albums and 855 are unidentified. This represents a large number of tracks: 104,000 total tracks, and 18,600 of them are unidentified (they are live recordings/bootlegs, mainly from a handful of artists). Performance was an issue for a long time until something changed maybe a year ago (I think that Roon made a change to address the issue of large numbers of unidentified albums). Performance was acceptable for some time, but now it seems worse than ever.
ARC is also very slow. I remember previously, Roon remote was very slow while ARC seemed to be very responsive.
That is a good chunk of tracks, if you temporarily disable your local watched folder, does performance pick back up? You should have more than enough RAM for sturdy performance.
Our team is working on some additional optimiziations around memory related issues for Nucleus and RoonOS that I believe should be included in an upcoming release that I’m confident should also help your case.
Yes, if I disable the local library, Roon performs very well. My Qoboz and Tidal favorites are only 512 albums. I’m also using Nugs. Although the performance problems were going on prior to Nugs.
After re-enabling the local library and then rebooting the Nucleus, Roon is performing well. Although That seems to be the pattern. It performs well directly after a reboot, and then eventually slows to a crawl. Yes, memory issues!
Understood, thank you @HeavyMetalDrummer - if all goes according to plan, these optimizations should hit production soon. I’ll ping you directly once these updates have been pushed and we can see how things perform under these circumstances.
I upgraded to 2.65 on Monday and Roon was instantly much faster! I was excited that this was finally the breakthrough. I went back to Roon on Tuesday later afternoon and it seemed slower, but I didn’t think much of it. And then by mid-day Wednesday, Roon was very slow again. Not quite as bad as before the 2.65 upgrade, but very noticeably slower than on Monday. So I rebooted the Nucleus+ and within 15 minutes of the reboot, Roon was fast again. But now, 24 hours later, the slowdown has returned - borderline unusable.
Seems there are still lingering memory issues and needs a daily reboot to behave in a reasonable fashion. I think a great feature would be to have a “nightly reboot” setting that will restart Roon server every night.
Feel free to continue the conversation in this thread; we are currently investigating the logs you submitted to development and will respond here with more information as soon as possible.
Just an update, Roon was behaving well after I updated to 2.66 on Tuesday morning, it was fine today, and then I made some changes to the library - deleted some Qobuz albums that had been made unavailable and replaced them with different versions. Roon is now very slow and unresponsive again.
Thanks for keeping us in the loop, though I am sorry to hear that the 2.66 update didn’t permanently squash the slowdown for you.
Since the performance tanked specifically after you made those Qobuz edits, I have two quick questions to help our development team narrow down exactly what the database is struggling with:
The Reboot Test: If you perform a simple reboot of your Nucleus+ right now, does the snappy performance immediately return? We want to confirm if a restart still temporarily clears out whatever is bogging the system down, just like it did on 2.65.
Pinpointing the Sluggishness: When the system is in this bogged-down state, which specific actions feel the slowest?
Is it global searching?
General surfing/browsing through your local library?
Loading pages specifically tied to streaming services (Qobuz/Tidal/nugs)?
Or is the delay mostly happening when you press "Play" and wait for the music to actually start?
We really appreciate you hanging in there and providing these detailed behavioral breadcrumbs while the team continues to investigate your logs! Let us know how it reacts after a fresh reboot.
Thanks for the follow up. Roon was sluggish this morning, but now seems very snappy after a reboot. In this 2.65 update, it seems like the sluggishness occurs whenever I make changes in the library, e.g. adding/removing Qobuz, I added several local albums last night. The biggest impact is in general surfing/browsing of the library, using Focus on the album or tracks pages, and its across all content, both Qobuz and local. It will take 20-30 seconds to process a Focus filter in Albums, and its will take 30 or more seconds to load an album after selecting it.
Just an update - Roon is still running well after rebooting almost three day ago, although I haven’t added any content to the library since then. Seems like the issue comes after any library updates, e.g. additions/deletions.
Thank you for that crucial follow-up. This is exactly the kind of “behavioral breadcrumb” we need—confirming that the performance degradation is tied specifically to library manipulation (additions/deletions/Focus operations) rather than just time passing.
To help our team categorize this, I have two points to clarify:
Comparison to previous builds: Is this behavior—where the system slows down noticeably after library edits—something you've experienced in previous versions, or did it only emerge after updating to 2.66?
Database maintenance background: When you add a batch of albums, Roon runs a heavy background process to analyze the files and update the database index. Does the sluggishness stop if you give the system some "idle time" after your edits (e.g., an hour or two), or does it stay in that degraded state until you manually force a reboot?
We are currently tracking a few reports regarding database responsiveness during intensive library indexing, and your observations are helping us isolate if this is a known regression or a new performance bottleneck.
Thanks for the follow up. This is different than 2.65, where it seemed to just degrade over 24-48 hours regardless of any library changes. In 2.66, the slowdown occurs only after adding content. And I noticed yesterday that after adding a few new local albums, it got very slow, but I left it alone and this morning it seemed much better. Hope this helps.
Thanks for the note on the difference you’re seeing with the issue symptoms on the latest build @HeavyMetalDrummer, our team is still chipping away at making some good progress on additional memory-related optimizations.
It shouldn’t be long before they’re included in an upcoming release, I’m confident they’ll help you.
