i have the logs i’m stuck at how to share them with support
You can best put them on eg. dropbox and pm the link to @ben (as he was already involved in this thread) with a link to your post in this thread.
They will pick it up from there (looking at their quick responses in other threads).
I watched my cpu utilisation on qnap yesterday for over an hour very closely while letting RoonServer do different things and could not reproduce it here. I think best thing would be if @support can take a look at it. They can give you details on how to send the logs as well.
Support have contacted me directly and I have shared my logs
Hopefully they will shed some light on what is causing this
I am also experiencing high CPU usage and a 5GB+ memory leak earlier with mid track dropouts and skipping. For now, I have temporarily disabled all audio analysis to see if this helps. Previously I was doing it on demand.
Doesn’t seem to be helping with CPU use. This is after an app restart, allowing for a period of stabilisation and playing a track.
QNAP TS-451, 8GB RAM, Roon DB on SSD.
What’s the same with all these QNAP devices that is different compared to other installs? 
It seems that it keeps the cpu load/memory use (leak?) high on these QNAP systems …
I don’t know, it could be a more generalised Linux issue. But if others are running beefier hardware, they may not have noticed any of the symptoms of high CPU load and memory use.
I am running a Linux system on regular hardware (no pre-assembled NAS like QNAP, Synology, etc or so), Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-21-generic x86_64), but haven’t seen any of these issues. Working perfectly fine…
The only thing I can see is there are a lot of RoonServer processes with different PID’s at the same time live…
Can’t that be something? Shouldn’t this be more efficient and not using that many PID’s? But hey, I am not a developer 
OK the news is Support believe they may have spotted the potential culprit and are hoping to release another update tonight. No promises on timing though.
I am not equipped to read the logs and understand - it sure looks like there is a huge amount of simultaneous repeat activity like you say.
To be fair a small team rolling this thing out across such a diverse eco system - looks like in the main its gone really well.
NAS users are among the more niche elements of the community. I was initially expecting to have to deploy the update myself like in previous iterations and would likely have made a mess of it 
I fully agree this small team of Roon developers is awesome looking at what they achieve. 
Certainly most of us are fine with a small hiccup left and right, but the more we help them, the better it will be for all of us. And they are damn quick in their response to our questions, certainly compared to bigger companies!
I am really curious what they have found out that may have caused this. And if this is linked to the amount of processes running at te same time.
(That was the only thing I showed from a screenshot of my current Linux load, no real log actually ;))
Yeah agreed it will be interesting to understand and if there is indeed a slight oversight that is causing this i’m surprised there aren’t more shouting about it.
i meant from my own logs that i shared with Support 
Memory use gone up by about 1 GB in 40minutes CPU remains high, just playing tracks. No analysis.
Definite shenanigans.
You have htop setup to show threads as processes. This is normal as Roon forks off a bunch of threads as part of normal operation.
Hit F2, arrow down to the second menu, and deselect “show userland process threads.” Roon should collapse down to one RoonAppliance process.
1 Like
Thanks! So, we can even learn a bit more Linux skills on this forum 
So, here, when not playing anything, almost no resources used:
Roon 1.3 build 196 includes a fix for people with logs that are just text like this repeating forever:
02/03 17:07:23 Debug: [broker/filebrowser/nassharemaker] rebuildsymlinks
02/03 17:07:23 Debug: [broker/filebrowser/nassharemaker] rebuildsymlinks
02/03 17:07:25 Debug: [broker/filebrowser/nassharemaker] rebuildsymlinks
02/03 17:07:25 Debug: [broker/filebrowser/nassharemaker] rebuildsymlinks
Please try it out and let me know if you still have problems. I know this includes at least @Scott_Fletcher, and I hope it includes everyone else in this thread as well.
1 Like
Ben thank you I will give this a try am sure it involves far more users than me. Hopefully you’ve ID’d the very issue
Much appreciated
Scott
With the new release I no longer lose my connection. Thanks a lot for the quick response.
Thanks Ben, I’ll keep an eye on CPU/mem and report back. If it goes OK I’ll try reenabling audio analysis too.
So far so good for me great thanks for the extra work on this
From being 90% cpu 80% ram with the previous build it’s now running at around 5-10% cpu and 25% ram
For a while was was worried my NAS was lacking sufficient beans!
I find this real world performance pretty amazing on an I3 NAS given I’m upsampling to 384khz and a few other DSP features turned on
Same. It’s looking positive.