Core Machine (Operating system/System info/Roon build number)
Roon Version 1.8 (build 814) stable
Intel NUC-Kit NUC8i7BEH
Rock Version 1.0 (build 227) stable
Proc: i7-8559U
RAM: 32 GB
Audio files (1.390.122 tracks) on lan connected Synology Raid5 NAS
Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
connection to NAS via LAN
Netgear 10 Gbit Switch, 10 Gbit NAS-Port (Synology Network Card)
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
Oppo HA-2, USB to Raspberry PI (Ropieee, WiFi or LAN)
Pro-Ject Pre Box S2 Digital to Raspberry PI (Ropieee, WiFi or LAN)
Hifiberry DAC+ Pro (LAN)
Description Of Issue
Within a 24h timeframe there are more than 30 not manual triggered restarts of roon server. The Rock-Server runs since more than 5 days, the connected NAS since more then 110 days without interruption.
The problem is caused by the Background audio analysis. if switched off the permanent restarting no longer occurs. I am surprised, that there is no error handling or no complete error handling is implemented. This behavior is new for me and does not exist with v1.7.
Hi, @ivan the situation remains very unsatisfactory. Since i switched off the Background audio analysis the restarts reduced to 3-4 a day. Especially annoying is a restart during music playback. It takes 5-10 minutes till i´m able to hear music again.
Hi, @Berthold, sorry for a late reply. We are still investigating this case. At this point, I put this in the queue to discuss it during one of our next technical meeting. An update will be posted in this thread as soon as we have a consistent answer.
Hi, @ivan, because I can’t see any progress at the moment i´m currently using a linux server. That works much better. At the moment there are no massiv restarts as on the Rock.
If you are interested in an error analysis i can always switch back to the rock server.
Hi, @ivan, may be it was a missinterpretation. The unmotivated restart of the server happens also on linux. Roon is for me nolonger on no plattform (Rock, Linux, Windows) usable.
Hi @Berthold, apologies for the lack of response here previously.
The team has discussed this and we are pretty sure we know what’s happening here. After reviewing logs and looking at your setup, unfortunately, it appears that your library is simply pushing Roon to the limit. A 1,390,122 track library is impressive. Probably the biggest we’ve seen attempted to be used with Roon!
With Roon, we consider over 250K tracks to be pretty large (only .01% of our customers having a library this large). You’ve surpassed that by over a million tracks!
We have some customers who get close to the 1 million track mark and can work okay using that with the right setup, but well over 1 million tracks seem to be too much for the hardware you’re running and would likely be too much for just about any setup.
Something that might work is to divide up your library into a couple of databases so that the database size is more manageable.
Hi @dylan, i was already afraid of that. For me a solution like roon just makes sense with a large collection. What exactly does “divide up your library” mean. Is it sufficient to use several paths and roon generate a database for each path?
Or does a “bigger” server (more RAM, more CPU-Power) makes sense?
Honestly, it’s hard to say if throwing more resources at it will help. We don’t test with any library that size and while more resources could certainly help, it’s not something we can guarantee.
You could have multiple Core machines that have different sections of your library on it. Even if you disabled certain paths on one database, those database entries will still exist and so the database will still be quite large.
Hey @beka, i´m still having trouble with untriggered restards. Currently i´m running the server under linux. That is much better than rock. I´m currently on the way to set up a detailed monitoring. It´s a little bit strange for me, that it restarts if i´m playing a Tidal playlist. I´ll get back to you when i have got some insights from the monitoring.
The Roon server has been running for some time with monitoring switched on. The large collection is not a problem. Less than 30% RAM utilisation and the CPU resources are hardly used.
I have almost certainly found the cause for the restarts. It is due to a RoPieee. However, it is inexplicable to me how this RoPieee can cause Roon to crash. That shouldn’t really happen.
Would you like to investigate the case further? The RoPieee still exists unchanged. I have another one in use at the moment.
By the way, the new version of Roon is extremely well done. The performance has really improved considerably.
So great to hear back from you and wish such encouraging news! Thanks for remembering to keep us updated on this thread
It is wonderful to hear that RoonServer is performing this well in your case
Thanks for sharing how you isolated the issue and discovered the RoPieee is connected to the crash. The only way we’d probably be able to gain more insight into what caused this crash is if we had timestamps & logs from the time of the crash
The restart at 11/03 10:32:55 for example was caused by switching on the RoPieee. The following three restarts at 10:57:27, 11:20:59 and 12:23:03 are part of the same session.
