ROCK on Cirrus7 Nimbini v3
Intel NUC Comet Lake i5-10210U, 4x 1.60GHz - 4.2GHz
8GB DDR4 SO-DIMM (2x4GB)
Samsung SSD 970 EVO Plus 250GB M.2.
Networking Gear & Setup Details
All ethernet, networked using local telecom (Meo/Altice) standard router/switch. High speed optical fibre internet.
Connected Audio Devices
Variety of endpoints, including multiple Raspberry Pi and Oppo. All hardwired via ethernet.
Remotes are Ipads and Iphones (wifi)
Number of Tracks in Library
180,000 tracks / 9900 albums
Description of Issue
ROCK crashes and automatically reboots several times a day. Typically this happens when I am looking at metadata and related artists whilst playing music to a single zone, with headphone convolution applied. Also happens when adding new albums from Qobuz. Typically ROCK shows capacity between 70-100 so processor load is relatively low.
Logs have already been submitted via your website.
Any idea about temperatures? Is it overheating and shutting down on the limit?
How old is the device? When was the last time you cleaned it?
If you turn all DSP does it make a difference?
The Cirrus 7 Nimbini is a fanless NUC, one year old, has huge heat sinks (similar to a power amp) and runs cooler than any of my Macs (with fans).
ROCK doesn’t allow temperature monitoring, but it is cool to the touch - perhaps just above room temperature (25 degrees in Lisbon today)
Turning off the minimal DSP had zero impact. This mainly happens when I am playing to one zone and scrolling through album covers or pdf booklets - seems to be database instability related.
Waiting for a Roon @Support person to review the logs…
You are right on the minimum required RAM to run a library of this size, it is possible that your ROCK is rebooting because it is running out of memory.
I’ve enabled diagnostics for your ROCK Core, but I am not seeing any logs come in, it doesn’t appear to have been active for the past few days. Can you please power your ROCK on? Hopefully it will then deliver a log set so we can check for clues, thanks!
Thanks for your response. I am currently traveling but I uploaded logs to your website, about 10 days ago, before I left. Check for a zip file with Gimlet in the filename.
Hi @noris I have just re-uploaded the logs to your Logs Upload Server. Please check for file gimlet_Logs_reupload.zip, uploaded by Anthony Dell. Thanks.
Thanks. I think you are probably right. When I originally looked at the Roon NUC specs for ROCK, I got the impression that 8gb was more than enough, but this clearly isn’t the case. Hopefully this will be a quick fix - and RAM is now relatively cheap, fortunately.
Rename the “RoonServer” folder to “RoonServer_old”
Restart the RoonServer in the WebUI to generate a new Roon database folder
On the Roon Remotes, press “Use another Core” and connect to the new database
Before restoring a backup, or adding your entire library - test out streaming content through Tidal/Qobuz or adding a small portion of your library for testing purposes.
Hi @benjamin , thanks for the advice. I have created a fresh database, and so far everything is working well. However, I have come across a curious anomaly on the database sizing, see screenshots attached.
The old database core is 14.68GB. The new one, based on a backup with the exact same data, including everything I had before, is 26.78GB. Almost double the size, for the same dataset. I would be interested in your comments.
Meanwhile, should I proceed with increasing my RAM from 8GB to 16GB? Or is 32GB the new recommendation for 10,000 albums / 180,000 tracks? Please advise.
Interesting indeed! Did you restore from a backup? Or, is this a fresh database without any prior restoration?
Increasing RAM certainly wouldn’t hurt! 16GB should be fine - if you’re planning on increasing the size of your library significantly you could increase it further to save you time down the road.
Interesting indeed! Did you restore from a backup? Or, is this a fresh database without any prior restoration?
Restored from the most recent backup - hence my surprise at the increased size.
Increasing RAM certainly wouldn’t hurt! 16GB should be fine - if you’re planning on increasing the size of your library significantly you could increase it further to save you time down the road.
Thanks - I will definitely increase RAM - probably to 32GB to future-proof for any growth in my library size.
Thanks @benjamin . Yes. Tested first as you advised. Worked perfectly, first on Tidal and then Qobuz. Then I restored a recent backup and it currently seems to be stable and working fine.
The automated backup routine ran overnight and everything worked with no errors (and I think Roon now has a database corruption checker built into the backup process). Having said that, I never had a corrupt database warning in the past, so something else seems to be going on here.
Update 1 - the old and new databases are now reported as approx. the same size - 26.7GB. Not sure what is going on, but probably not worth investigating further.
Update 2 - just had another random crash at 14.52 today local time. Was looking at metadata and playing to a single endpoint, with volume levelling but no other processing.
Thanks for the update! Glad to hear things have improved slightly. We took a look at your ROCK diagnostics and unfortunately didn’t see anything out of the ordinary based on the timestamp you shared. I’d be curious to take a look at your Nuc system logs around that time to see if there’s more information around the crash.
If possible, could you zip up a set of system logs and send them over to our File Uploader?
Sorry for any confusion here! I meant the system logs for the Nuc, not Roon logs specifically. Your system logs may contain relevant information about the crash that could point us in the right direction for troubleshooting.
Have you experienced any additional crashes in the last day or so?
Hi @Benjamin . Thanks for your message. I assume system logs are held in the RAATServer directory. I have just uploaded a set of system logs as Gimlet_System_Logs.zip.
I haven’t used Roon much today, so the most recent crash is still timed at 14.52 yesterday (Lisbon time).
Thanks for sending those over! We took an extensive look, but wasn’t able to pinpoint anything relating to the later-on crash. That said, we are still seeing OOM traces here and there, and so I’d be very curious to see how things function when you upgrade your RAM.
Let me know if this is something you’re still in the process of doing.
I am still waiting for the memory upgrade to arrive, but I agree with you that memory is the most likely problem. Let’s mark this one as “solved” unless I have a recurrence of the issue.
