Roon slow performance and Qobuz albums not syncing after update (ref#QWF79U)

Select your Nucleus model from the list below

· Nucleus One

I'm having trouble with my Nucleus hardware

· Other

Select the option that fits best

· The Nucleus boots up and I can connect to it in the Roon app without issue, but I have a question about configuration/storage/attached devices

Describe the issue

ref#WN3ULF
15 hours after updating to last version playing around with my remote, iPad, adding new albums, checking the queue which are 140 tracks long everything is slowing down. The jellyfish is back and audio endpoint is lost, local time Oslo 10:50, music stops and remote is freezing. 10 - 20 seconds later remote wakes up and the next track is ready to play. So on my end nothing has changed. I’m getting frustrated. And BTW, newly added Qobuz albums are not syncing to Roon.

Hey @BergeP,

Thanks for sharing your report on the latest update, and sorry for the frustration. You’re right that nothing changed on your end, and the logs back that up.

The cause is upstream of Roon Server, on your network. Two devices — 192.168.1.140 and 192.168.1.131, are advertising themselves as RAATServer endpoints, accepting the connection from your Nucleus One, and then immediately dropping it. They’ve done this 226,871 times in the ~20 hours of logs we’ve reviewed, at up to 135 times per second. That churn floods Roon Server with device-state updates it has to buffer for your remotes, and rebuilding those buffers is what drives the memory spike that freezes everything. Neither device ever finishes handshaking, so neither shows up as a usable zone, they’re producing nothing but load.

One reassuring thing: your Nucleus One never actually ran out of memory. There’s no sign of the operating system killing Roon for memory exhaustion anywhere in those logs. What’s happening is that the server gets so busy cleaning up after this loop that it stops responding, and the watchdog restarts it. That’s a meaningful difference; it points at the loop, not at your hardware being undersized.

The one thing that would help most, could you identify what’s at 192.168.1.140 and 192.168.1.131? There’s a third at 192.168.1.200 that’s behaving normally, so it may be a sibling of those two.

If you can power those two down and let Roon run for an hour or two, I’d expect the stalls, the spinner and the endpoint dropouts to stop. That single test will confirm the diagnosis. If one of them is a Docker install, it’s also worth checking it’s set to host networking, bridged networking is a very common cause of this exact “connects then instantly drops” pattern.

On the Qobuz albums: that’s a separate problem, and it is on our side, not yours. Your Qobuz sync is running correctly and Roon is receiving your new favourites, I can see your library go from 5,319 to 5,320 albums during the logs. But the step that publishes them into your library is gated behind a periodic full metadata refresh that last completed on 31 July and hasn’t run since. There are currently 70,129 items queued behind it. So the albums are arriving and then sitting in a queue. We’ll need to look into this further.

Two smaller things worth mentioning:

  • Your queue was 7,999 tracks at the time of the stall, not 140, that’s Roon’s maximum queue length, and shuffle was on. A queue that size is significantly more expensive for the server to hold and to re-send to your remotes each time one reconnects. Clearing it down won’t fix the root cause, but it will take real pressure off while we sort the rest out.
  • Your Samsung T7 SSD is showing as offline to Roon (DriveNotReady). If that’s meant to be part of your library, let me know and we’ll look at it separately.

Let me know what those two IPs turn out to be and we’ll go from there. :+1:

Hi @benjamin , the two IP adresses are my iPhone, …131 and one of my iPads, …140, both used as remotes. I have one more iPad, …200, only used for showing what is playing, kind of passive remote. So it looks like we have a problem between the Nucleus and my remotes. They all use the Roon app for communicating with N1. About the Samsung SSD that is strange because all my local music is on that drive and everything shows up inside the Roon app. What to do?

Should I delete the Roon apps from the two devices that makes trouble?

I have now deleted the Roon app from my iPhone and iPad

On this two devices I also have the Meridian Control app that I control my 218 with. Are you able to see if the Meridian app is causing any problems?

Hello @BergeP,

We owe you a correction, and we are sorry: the advice we gave you was wrong. Please put Roon back on your iPhone and iPad.

We told you two devices on your network were misbehaving. They were not. Your own logs show why: three days after you removed those two apps, the same reconnect pattern appeared on your third iPad, the passive one we told you was behaving normally. It followed whichever device was left, so it was never about those two.

The reconnect loop is not the whole story either, and this is what we should have led with. Your server is stalling because of how it manages memory. On the morning you reported, at 10:49 Oslo time, it stopped for 14.3 seconds inside a single 15 second window. That is precisely the freeze you described, and why the music stopped and the remote came back 10 to 20 seconds later. It was not your network, your remotes, or the Meridian app.

The better news is that your own logs show it easing. Counting the number of measurement windows per day where the server lost more than a second to memory work: 428 on the 7th, then 245, 152, 90, and 61 today. The severe stalls have gone the same way, from 30 windows on the 7th down to a handful. You should be noticing fewer interruptions than you were last week, and if you are not, tell us, because that would be useful to know.

Our development team is actively working on memory behavior in Roon Server. We are adding your data to the thread where we track the memory problems that remain, so your case is counted rather than treated as a one off. There is nothing further for you to test or change, and we will only come back to you here if there is something specific we need you to try.

Hi @vadim and @benjamin

Good to hear. Living with Roon without an active remote is kind of boring.

But what about the Samsung T7 SSD that I was told is showing offline to Roon. I can see all albums, play all albums and see the SSD inside Roon, as a disk in the Backup section and in the Storage settings. Is this a bug fixable from Your side.

I will activate the remotes again on my phone and pad and hope for the best and follow up if something is happening.

The good part is that my system has been running for 4 days and 6 hours without a restart or reboot so something correrct is happening. Hope this is not only because of little activity inside Roon, adding and grooming albums.

BTW. I’m having trouble with editing albums. When I choose another version the album art is not following and Roon’s own stock art is showing. The only solution is to find the right cover online and ad it manually. Please fix, verry annoying and it’s been like this for a long time

Hey @BergeP,

Thanks for the additional info! Good news on the SSD, I went back through your latest logs and the T7 is healthy. It’s mounted, readable, being watched for new files (it picked up and imported a new album yesterday evening without a hitch), and every track played from it succeeded. There are no drive errors of any kind in this set. Nothing to fix on that front, and nothing you need to do. My previous suspicion can be disregarded based on these fresh Roon Server logs.

I’m curious, are you using either of your iOS remotes (triggering the connection storms) as actual audio endpoints?

If not, I’d test disabling their system outputs and see if things continue to run smoothly for you. That way, you’d still be able to use them as remotes.

We’d be happy to take a look into this as well, if you could please share a few specific examples. Thank you!

good morning @benjamin , @vadim

it just happened. Lost audio end point, lokal time 07.23 and the track is Topsy with Buddy Tate. This was after 5 days and 20 hours so maybe the new normal? I did not make a reboot just to see how long it goes to next drop out.

Local time 08:35, Vince Guaraldi - Charlie Brow track, audio endpoint lost for the second time. Time for a server restart.

Non of my IOS remotes are used for audio endpoints. My only endpoint is my 218. So if you can disable their system outputs, please do and see if it makes things any better.

The album problem seems like history. Groomed yesterday and everything worked as expected..

And it happened again, local time 20:40 track Álom with Ferenc Snétberger, audio drop out. Only 12 hours since server restart.

And again local time 07:56, track Terje Gewelt November, audio end point lost wile opening Homepage on Roon for checking the Daily Picks. Before the music stopped the jelly fish was spinning around and it took some time before the page opened. Server been running 1 day and 23 hours.

Is this because of the RAAT communication between the N1 and my IOS remotes?

Thanks for follow up.

Hi @BergeP,

We’ve enabled some additional diagnostics for your Roon Server, if you could please reboot Roon Server twice, and then attempt to reproduce the issue at your convenience, that would be helpful.

Thank you!

Hi @benjamin and @vadim ,

I have now rebooted twice. What is strange is that before the double reboot the system has been running for 3 days, 15 hours and 8 minutes. Had some problems with Daily Picks coming and going a couple of days ago but suddenly everything is running pretty smoothly. The only issue is when opening the remotes on the Home page the jellyfish is arriving and it takes about 20 - 30 seconds before it shows the content and the gap between songs are getting longer.

Have you disabled the system output on my IOS remotes?

Thanks for follow up.