I’ll be listening to music and the music will stop and the Roon client (iPad Pro 12.9) will lose connection. It appears that the Roon server on my Nucleus+ has rebooted (see attached). The client will eventually reconnect but then it is glacially slow as it rescans my library. This morning I was browsing Roon while listening and tried to add a Qobuz album to my library which seemed to trigger the reboot. The other two times it has happened the iPad was laying idle and I wasn’t doing anything but listening. This only started happening since the last upgrade. This coupled with all the blank screens I get (detailed in another support post) are making Roon less than pleasant to use. It used to be pretty bullet proof.
Apologies for the trouble here!
Starting our, can you confirm how many tracks total are in your library? You can find this by going to the Overview screen of Roon.
I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.
However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.
First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.
OK, I will note the time of the next reboot.
Just rebooted @ 9:23 AM Central after over an hour of listening (the past 3 reboots occurred within abount 10 minutes of starting to listen.)
Now that I have the timestamps, diagnostics have been enabled on your account. The next time your Core is active a diagnostics report will automatically be generated and uploaded directly to our servers
Once that’s been received, I’ll be sure to update this thread and pass the diagnostics over to the team for further analysis.
Server rebooted again while listening tonight. 6:21 Central Time.
The diagnostics report has been received and is with the team for analysis. We see where RoonServer is restarting and the team is continuing to analyze the report for more details. In the meantime, we are hoping that you can provide some additional information that might help:
- Can you describe your networking setup? What networking hardware is in use (router, switches, etc.)?
- In both cases, we see this issue occurs while playing to a Trinnov device — Has it ever occurred while playing to a different device?
- Where are your media files stored?
My files are stored on a Netgear ReadyNAS RN51600 that is set to spin down after 5 minutes. My router is an Asus RT-AC3200 and I have a TP-Link 16 port gigabit unmanaged switch. Everything is wired. I really only ever listen on My Trinnov. This has occurred on both my files and Qobuz files. This infrastructure has been in place for quite a while. The reboots only started happening since the most recent update.
A post was split to a new topic: Core rebooting during playback
As a test, can you try playing to a different endpoint, like System Output of a remote, for some time? It would definitely be interesting to know if this is limited to occurring only during playback of the Trinnov.
I just noticed that my Nucleus+ server must have rebooted overnight. I was asleep at the time. This screenshot was taken at 9:49 this morning.
Hi @John_Swanson_Swanson — Was playback happening during this time? Have you had it stop during playback at all since my last message to you?
No, playback was not happening at the time…it was the middle of the night . The Nucleus+ has not rebooted while playing since the last post.
Thanks for confirming, @John_Swanson_Swanson. I’ll enable diagnostics to take a look at the incident from last night, but please do keep me updated if it occurs during playback again too so we can take a look.
Grrrrr! The server rebooted again tonight @ 6:25 while listening. The iPad was lying idle.
Thanks for the update, @John_Swanson_Swanson — Diagnostics have been enabled for this incident as well and I’ll be sure to follow up soon.
Server rebooted again this morning during listening. Approximately 9:08 am.
I’m bringing this to our senior tech team during our meeting tomorrow.
Would you kindly use the directions found here and send us over a set of logs using a shared Dropbox link?
Just to verify, has this only ever happened during playback to the Trinnov? Never any other endpoint?