Since some months I experience long delays as indicated in the title. No changes in my setup that could explain that. I play music every evening for ~ 2 hours. After some days, the delays start randomly: sometimes no delays, sometimes long delays. Only way to resolve from this consistently is reboot my NUC. Problem is then gone for some days before it starts building up again. During playing, no audible hickups or whatsoever.
My system: Headless Intel NUC, latest ROCK, Roon Ready device Weiss DAC501, all connected to an English Electric switch. Background Work set to default 1 AM - 5 AM while I am not listening.
For example, start playing Bullet Proof from Radiohead took very, very long. See below, not sure if it really was a delay of 38 seconds, but long enough to decide to report this.
I checked the logs and noticed this:
RoonServer_log.03.txt
19:04:53 Added Bullet Proof from Radiohead to queue (FLAC from local attached USB disk)
Other song was playing and I closed the remote app on iPad
19:08:39 [LOADING @0000:00] Bullet Proof
19:09:17 [PLAYING @0:00] Bullet Proof
Is there a way I can upload the logs for you to investigate further?
Iâm in the same situation. After reboot Roon is snappy and everything works as expected. Then after 8 - 10 hours it starts to get slow. After 15 - 20 hours of playing a reboot has to be done. In my system this behavior started with 2.57 update. Before that I could play music in 10 - 15 days without rebooting. Something happened in that update and itâs not been fixed after that.
I just started a thread for a very similar problem. I have seen track load times, even for local files, in the 90 second range routinely. Nothing seems to help. Here is the thread if you want to monitor both: Slow load times for tracks and app with ROCK server (ref#RQ3CDH)
Thank you for reaching out and providing such precise details.
I took a close look at the log snippet you provided, and we also reviewed your system diagnostics on our end. Your NUCâs specifications are perfectly healthy (you have 8GB of RAM and over 100GB of free space on your internal SSD), which is more than enough to smoothly handle your 54,000-track library.
However, thanks to the exact timestamps you provided, we were able to pinpoint the exact cause of the delay in your logs. Right at 19:08:37, just before âBullet Proofâ was supposed to start playing, your Roon Server performed a routine database save (recorded in the logs as an endmutation). Normally, this takes a few milliseconds, but your server took almost 40 seconds (endmutation in 39399ms) to complete it. During this time, the Roon core was essentially frozen, which perfectly matches your experience of a 38-second delay.
Since your RAM and storage space are fine, a 40-second lockup during a database write operation points directly to a read/write bottleneck. This is typically caused by one of two things:
Database Corruption: The Roon database has accumulated hidden damage over time, causing the server to âchokeâ when trying to sort or save data.
Failing Internal SSD: The internal M.2 SSD inside your NUC (where the Roon OS and database live) is beginning to fail. As flash memory degrades, write operations can cause deep hardware-level freezes.
Before we escalate this ticket to our R&D team for a deeper investigation, we need to make sure your SSD is healthy and rule out a broken database. To do this, please run a test with a completely fresh database:
Access your NUCâs Data folder over the network (directions here).
Find the folder named RoonServer and rename it to RoonServer_old.
Restart the RoonServer in the WebUI. This will generate a fresh, clean database.
Open your Roon Remote, click âUse another Roon Serverâ, and connect.
Note: Please do not restore your backup yet. Just log into Qobuz, let Roon scan your music, and test playback for a day or two.
If the fresh database is snappy and the delays completely disappear, it means your old database was corrupted. If the 40-second freezes return even on the fresh database, it is strong evidence that your internal M.2 SSD is failing and needs to be replaced.
Would you be able to run this test and let us know how the system behaves?
Thanks for your clear explanation and advice, much appreciated!!
My NUC is 8 years old and running ROCK since then continuously, so the SSD might be the problem but lets wait for a few days to be sure. I just followed the steps you suggested and a new database is running right now.
I noticed many ~40 second endmutation delays, in the same logfile, they typically occur after around 150 of these lines:
Most other endmutations take around 100 - 200 ms each
Does this ring a bell? Maybe related to smart playlists? I have smart playlists of a few thousand songs tagged with either â4 Stars not played in the last yearâ or â5 Stars not played in the last yearâ, but I explicitly did not âviewâ them last week to see if that would help. But apparently not
Anyway, in case the SSD is the problem, can you point me to instructions how to set up a new SSD from scratch?
In case the database is corrupted, will a restore of a backup automatically resolve this, or is there a way to rebuild the database and get rid of the âaccumulated hidden damageâ? Or will that be restored too??
I just hope my playlists, tags, ratings and play counts wonât be lost thenâŚ
Running for 3 days with the fresh database now (Qobuz + imported my local albums, 54k tracks) and there are NO delays anymore.
Additionally, the iPad remote is MUCH, MUCH snappier now, My Albums view now load almost instantaneous, also when clicking an album. No delays when start playing a track.
I do not recall having this performance for some years. I think things got less snappy slowly over time and I may got used to that and accepted that (âwell, I have an old NUC and an old iPadâ).
What would be the next steps?
How can I rebuild my old database, without losing my tags, favorites etc.?
Yes, I am having the same issue as the OP and am going to try the fresh database approach. Assuming it works for me like it did for @Gerard_Burgstede , can you tell us how to recover our favorites, etc. from the original database, once weâve created a new one? I hope thatâs is possible!
I, too, have done the fresh database procedure and I can confirm that it is a huge difference - Roon has not performed like this for me in a long time. BTW: I am running a Roon-spec NUC with ROCK, and everything is connected via gigabit Ethernet, on a new router and switch.
I must ask: this sure seems important. So shouldnât there be something happening internally that would keep the database efficient and not âcorruptâ?
But again, thank you @vadim for identifying this fix. Is there any way to recover favorites, etc.?
Just adding one more data pointâI too have been frustrated for weeks by slow app startup times, tracks not loading for 30+ seconds, tracks buffering and getting skipped, etc. Followed the new data folder steps and everythingâs speedy and working great again today. Grateful for that suggestion and, like others, would like to know 1) how to prevent corrupted data and 2) how to restore âoldâ data.
ETA: Almost everything I play is from Qobuz, which seems to be creating issues for a number of folks lately, but I also have Tidal, and thatâs been laggy too (less so than Qobuz). In case this is useful, Iâm also using a NUC for my ROCK and typically stream to four endpoints (Bluesound Nodes and a Roon Ready Marantz AVR) at once.
I too have had exactly the same issues, which started a few weeks ago. I find it very suspicious that a bunch of database corruptions seem to have hit a number of users at the same time. Coincidence, or something else ?
Rather than try the âfresh databaseâ approach, I went the other way: I took a backup of my current âcorruptedâ ROCK database (which covers over 10 years of trouble-free usage, by the way) and then set up a completely new server on entirely different hardware (Mac mini, fwiw). After restoring the âcorruptâ database, I found all my historical data was intact, and that Roon performs perfectly, with no sign of the slow responses that I and other folk have encountered previously.
To my mind, this does not really tie in with the findings reported by @vadim , unless a corrupted database is somehow magically repaired during the backup & restore process (which I donât believe is the case). I am very happy and relieved that my 10 years of data still appears to be intact, but I am sure that there are many others who will be concerned about the potential loss of years of updates, and I believe that this case warrants further investigation.
When it comes to restoring your database, there isnât an option to partially restore or select specific items. The backup restore process is all-or-nothing, so it must complete in its entirety or not at all. At this point, hereâs what I recommend:
Please try restoring your backup.
Export your playlists to M3U files, so you'll be able to import them later if needed.
Stick with the restored database for a while, as it may not cause any delays after the restoration process.
Gerard, I have been having ROON stability issues too so I tried rebuilding RoonServer DIR as suggested. Roon booted back up and started rebuilding that DIR. However, after a half hour or so of streaming a burnin track, I got a black screen saying âTrouble rebuilding databaseâ or something like thatâŚand prompted for a RESTORE, which I ran and now back up and running. Assume since it was a restore, no improvement can be expected? Suggestions? Try again? Glenn L
Can you comment on the database corruption issue? Why does it occur, and is there not a way for Roon to self-correct?
If the underlying cause of the corruption canât be identified/fixed, would it be possible to give us tools to access the old âcorruptedâ database to extract favorites, etc. and then import them the ânewâ database?
As Iâve said elsewhere, this seems pretty significant, esp. given the number of people experiencing similar issues, and experiencing the same drastic improvement with a âfreshâ database (either new or restored from back-up).
I have started having similar issues during this past month over the last couple of updates. I will try starting fresh, restoring backup and see if that changes anything.
. Nâjoying music should be the main goal.