What kind of performance/speed issue are you experiencing?
· The app is using a lot of resources (CPU/RAM)
Please try to reboot your Roon Server
· No, the issue is still the same even immediately after a reboot
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?
· I only have one Roon remote to test with
Please try to restart your Roon Remote (controller) app
· No, the issue is still the same even after a restart
What is the operating system of your Roon Remote (controller)?
· Windows
Reinstall Windows/MacOS Roon Remote App
· No, I am still having the issue even after reinstalling
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?
· Linux Server (Ubuntu, Fedora, ArchLinux...)
Describe the issue
High recources usage with new BAA unscheduled policy
Describe your network setup
I'm experiencing a high resource usage using the Background Audio Analysis in unscheduled mode. My server isn't ever on h24 and the unscheduled mode seems to force a long background work around every hour. In log file I can see a lot of "[updatemetadata] _ReadyForFullRefresh". I have a big local library. There is huge difference in terms of resources (memory and CPU) used than the last roon version. Using some core (not throttle) it lead to a roon freeze also.
Thank you for the detailed report and for keeping a close eye on your server’s performance.
To help clarify how the Background Audio Analysis (BAA) operates: the scheduling feature was recently introduced in version 2.61. When the BAA policy is left “unscheduled,” the analysis engine actually runs using the exact same default behavior that Roon has always used in all previous versions. Effectively, nothing has changed under the hood regarding how Roon analyzes files when a schedule is not active.
Additionally, the [updatemetadata] _ReadyForFullRefresh entries you are seeing in the logs are part of a standard routine where Roon checks in with our cloud services to pull the latest metadata updates for your library. This happens periodically and is a completely separate process from the audio analysis.
If using unthrottled cores leads to a Roon freeze with your large library, utilizing the new scheduling feature to restrict analysis to specific hours—or simply leaving it on “Throttled”—is the recommended approach to prevent resource exhaustion.
Are you experiencing any actual functional problems during your daily listening, such as playback dropouts, audio glitches, or remote app disconnects, or is the concern primarily the high CPU/RAM usage observed in your system monitor? Please let us know so we can ensure your setup is running smoothly!
I recently often monitored the system because I switched to audiolinux os and I hadn’t noticed this behaviour before. In practice, if unscheduled mode is selected the RoonAppliance (in particolar Broker:Media**)** constantly do “something” about once an hour and log messages are something like:
03/17 15:56:40 Trace: \[library\] finished with 1 dirty tracks 1 dirty albums 6 dirty performers 1 dirty works 1 dirty performances 0 clumping tracks, 0 clumping auxfiles 0 compute tracks, 0 deleted tracks, 0 tracks to (re)load, 0 tracks to retain, 0 auxfiles to (re)load, 0 auxfiles to retain, and 10 changed objects
03/17 15:56:40 Info: \[updatemetadata\] Flush: pending adds=105752, pending removes=0, current q size=0
03/17 15:56:40 Info: \[updatemetadata\] \_ReadyForFullRefresh: last_time=3/17/2026 11:22:03AM (UTC), now=3/17/2026 2:56:39PM (UTC), UpdateInterval=00:15:00
03/17 15:56:40 Info: \[updatemetadata\] \_ReadyForFullRefresh: time_past_due=03:19:35.7960720, is_within_window=False, should_update=False
03/17 15:56:40 Info: \[updatemetadata\] \_ReadyForFullRefresh: last_time=3/17/2026 11:22:03AM (UTC), now=3/17/2026 2:56:39PM (UTC), UpdateInterval=00:15:00
03/17 15:56:40 Info: \[updatemetadata\] \_ReadyForFullRefresh: time_past_due=03:19:35.7961111, is_within_window=False, should_update=False
03/17 15:56:40 Info: \[updatemetadata\] Flush: not ready for full refresh (is_ready=False), keeping 105752 adds and 0 removes in pending lists
03/17 15:57:59 Trace: \[library\] starting cleanup with 1 dirty tracks 1 dirty albums 1 dirty performers , 0 tracks to retain, 0 auxfiles to retain
In this output there is no problem because “trigger flags” like should_update or is_within_window are False (now is in scheduled mode) but in unscheduled mode this happens as described before. In practice there is a constant real “full refresh” (not only the “check”).
When this happens the CPU (and memory) increases until 35-65% for about 30 minutes and then start again after an hour an so on. In Scheduled mode this does not happen (obviously). Seems the scheduled mode has become “time aggressive”.
Thanks for the reply, and apologies for any confusion -
Let me know if you’re able to expand on the above question from Vadim, we’d be happy to take a closer look if you’re noticing actual problems. Thank you!