I’d like to say something like this.
I don’t know which i3 CPU you use, but in this case, I recommend you make it with the headless system, roon rock. The low-power i3 CPU used in the NUC is not good enough to run separate OSs and Roon. If there’s no specific reason, use it as a roon rock.
Try moving the sound stored in the NAS to the local area within the NUC.
Log is not very helpful. You need to check each background program one by one.
I used to serve multiple (5-6) plex video transcoded streams with this little NUC, and it rarely ever cracked 50% CPU. Since I am a tech geek, I did move it to a ROCK just now. Problem with ROCK, however, is I now don’t have a way to see CPU or RAM usage – at least not a way I can find.
If I have to move my media to the NUC, then I will cancel Roon. I don’t want all that media on a single drive. Plus, I still also use plexamp. Regardless, my 350G of music will not fit on the 256G SSD in the NUC.
Yeah, the log is pretty useless for this. It is even more so now that I’m using ROCK. I guess I can listen for the fan tomorrow after my full day of listening.
Checking the CPU, RAM usage, and temperature is a good habit and way to manage the system. As you mentioned, the biggest drawback of Rock is that it cannot monitor how much system resources are being used.
However, if there is no problem with the system operating normally and using it, I personally think that you don’t have to pay too much attention to it except for problems such as temperature and noise. In case of temperature or noise, it can be easily detected by the operating state of the CPU or system cooler, so there is no big difficulty in noticing it.
Lack of CPU and RAM resources can degrade system performance very much. This is the signal that requires replacing the system.
Personally, it would be nice to show the CPU and RAM usage of the server in the Roon UI.
If you need to use an additional NAS, adjust the scan time of the NAS connected to the storage. There is an option there.
Sorry that’s just rubbish I ran one on Ubuntu for years and no issues. It’s recommended to have 8gb min though if not using RoonOS not seen Dietpi use much of my RAM at all it’s all Roon using it.
You likely have not had debugging enabled. Support switch this on remotely to get more info. Mine has tons of info about what’s going on. As they switched it on to get info for a bug I was encountering and it’s not been turned off. I see detailed breakdowns of pretty much all processes. Obviously an understanding of what they are helps but this is how I worked out that metadata service updates are what trigger Roon to get a stuck CPU at 100% in my case.
I think if you have your music on NAS then as mentioned Roon will scan regularly to see it’s still online. This also triggers NAS drives to not goto sleep. This has been reported a lot.
If you use Ubuntu, it’s lighter than Windows, so there’s a high possibility that you won’t have big problems with resources. But not all systems are free from problems, and I think it depends on which Linux you mix and which programs you use. Especially, it will be different from using only a specialized OS like Rock as a headless system. Anyway, I think it’s better to use Rock if it’s a dedicated system for Roon. I respect your opinion when you refute it. Not everything in the world has 100% correct answers.
No I agree, I used ROCK as my primary for a 6 years, Ubuntu was my backup until I discovered Dietpi for x64 but moved entirely to DietPi from ROCK in April much happier as I can see what it’s doing when Roon has its fits which it does even on RoonOS, and I can easily run Tailscale and other music apps as backups. PlexAmp is essential for remote playback as it’s far more mature and stable than ARC also works without a VPN or port forwarding.
I would rather have a dedicated machine to all my media activities rather than one device like one for each as it’s just too many machines and power usage. Which today seems wasteful.
A modern i3 CPU will be easily able to run a Linux desktop and Roon server…
With that I agree. One can suspect that the CPU spikes experienced by the OP might have to do with Roon’s communication with the NAS, but that’s not clear just now. If it were me, I would try to gather additional evidence by moving part of my music library temporarily to the Roon server (USB-connected external HD) and disconnect from the NAS. This will then show if the CPU spikes still occur, or if they are gone…
If you encounter that the RoonAppliance process is maxing out one CPU core, then looking at the Roon log is the natural thing to do. It is there you would expect to see what Roon is doing, and the logging process is very verbose. That in the OP’s case there were no background processes being logged, in fact is helpful information, as now metadata update processes can be ruled out…
I have 32gb of RAM on this NUC, and I’ve run far more challenging workloads on it as well. As software developer of 30+ years, it baffles me how inefficient roon seems to be. Take DSP out of the picture, and all it’s doing during playback is delivering a file (flac in my case) from the server to the player. Even if it has to transcode 24b/192khz down to 24b/48khz, ffmpeg is not a resource hog. It should not take an entire core to perform that operation. This machine’s past life would routinely deliver 5-6 transcoded video and audio streams via Plex and barely break a sweat (all media has always been on the NAS), and it did so for years. Oh, and it had 10 other docker containers doing work on it as well (home assistant, node red, local source control, etc.) Now, I have all those same containers running on the Synology NAS which only has a celeron, and it’s still barely breaking a sweat.
I’m going to keep trying things till Feb when my trial runs out. I do like the ability to easily discover new music, but I want the thing to live up to it’s name and be a ROCK. If roon wants us to treat it as an appliance, then I shouldn’t have to ever pay attention to it, ever. It just works. Otherwise, do what most of my other appliances do (Unifi DM Pro, Unifi switches, cable modem, Plex, Synology, etc.). They all allow me to monitor health and see resource usage. Even my McIntosh processor has a web interface to check on it.
I’m not sure as I think more verbose logging for debugging is switched on by support. As not everyone sees what I see in my logs they don’t turn it off once actioned it seems. Maybe some of this is in the more verbose ones only? I guess as you also had support tickets they activated it on your server to. I could be wrong though.
I don’t think that support staff ever activated logging beyond the standard on my installation. I am quite sure this has never been informed to me or brought to my attention. But, of course, I can’t rule it out.
I have done several reinstalls during the years, and on every instance logging has been very verbose. On the other hand, the OP’s library is small, much smaller than mine when I was running Roon, and these background processes shouldn’t even be noticed. They certainly should never run for hours, as has been stated by him. So I don’t think his observations are due to metadata updates or storage library processing.
It certainly is inefficient, isn’t it? I now run LMS, and the server load (headless dedicated machine) never goes beyond 0,01…
I’d agree it’s inefficient in a lot of what it does, search being an area of high inefficiency, but In fairness though Plex uses GPU acceleration for video streams and this takes a huge load off the cpu, so a direct comparison here isn’t quite fair. Plex when it does track analysis is way heavier than Roon.
Roon will have slight overhead for playback as it does flac to pcm conversion although that’s minuscule on todays cpus.
It’s true that Plex uses the GPU for video transcoding, but it only uses the CPU for audio. That’s where my comparison came from. Even with the GPU, there still is a load on the CPU for video transcoding, and then you add on audio which is all CPU.
I didn’t realize roon went to PCM instead of FLAC. If anything, that might skip a step and put more load on the network. I know when I do command line conversions with ffmpeg, it will decompress the file, convert in WAV or PCM, do whatever bit or sample rate conversions, and then compress again into the format I’m after. Going to PCM would skip the compression step. Like you said, it doesn’t matter much anyway since it’s not an expensive operation for any modern CPU, and the extra load on the network is nothing for my Gig network. Interestingly, I often see Plex converting to audio track from DTS to flac.
For the record, ALL of my media devices except a couple of Sonos speakers are wired. There are 5 video streaming devices (no cable tv, all streaming) and 9 audio streamers in the house. I don’t want to flood my WiFi with streaming.
AJ
I suspect the issues are library/database specific. Those with tiny local libraries don’t seem to suffer this. The same process probably runs but it doesn’t kill a core like it does with a larger local library. So it’s us actual music collectors that take the hit…
What is the cutoff for “tiny libraries”? My local library is about 1000 album, most ripped from CDs and rest are HD.
Interesting: Intel NUC overheating and fan noise since latest Roon update (ref#HMNFG1) - #5 by Wayne_Foster
What peaked my interest was this person’s extra load seemed to be related to latest build and Sonos. Since my office has a Sonos, and that’s where I’ve been doing all the playing during the day. I’m thinking things are related.
I wouldn’t suggest a number. It may be a sliding scale of size and complexity with unidentified albums, box sets, tags, and other items. I don’t think anyone really knows and there could be multiple gremlins.
I’ve been a very heavy Roon user since 2017 and these issues seem to come and go. There are many software gurus who use Roon and there are lots of theories and perhaps more than one is correct.
If you are going to commit to Roon you commit to the ride it entails, including unexpected gremlins with new releases. Most of us who are committed tend to adapt our hardware to the Roon reality rather than the other way around. For example my primary Roon server is well above Roon specs and I have a backup server for when the primary misbehaves, although sometimes it seems the issue is on the Roon network side when they both behave the same way for no apparent local reason…
I’m ok with the ride as long as it isn’t too bumpy. I started this hardware tinker 20+ years ago when I was building HTPCs that upscaled my DVDs and served multiple audio zones via JRiver. Lots of fun for me, but it wasn’t family friendly. I felt like I was in IT support a lot. “Why won’t the movie play?”, “How come the music isn’t working?”, etc. 
I don’t want to be in that position anymore. I just want stuff to work. I had a great combo with Plex/Plexamp when it integrated with Tidal. Since that integration went away, I’m deciding on Roon. So far, it doesn’t look to like that my environment has several Sonos speakers, amps, and a port. My main system, however, uses a Roon Ready player. As expected, that one is solid. So far, the Sonos zones, not so much. Looks like I may not be the only one: Intel NUC overheating and fan noise since latest Roon update (ref#HMNFG1) - #5 by Wayne_Foster
If you love to tinker then figure out Roon and keep it, but just for you. Music discovery and some of the other features are worth it.
Others will get too frustrated so keep them on Plex or a streaming music provider app. None of my family would stay on Roon after the first time it misbehaved. And if it had misbehaved with your collection, it probably still will.