Roon server keeps using more and more RAM even sitting idle

Understood. I’m glad your ROCK has never had issues. But it’s merely anecdotal - and to your point - no guarantee of future poerformance. :slight_smile: Just take a moment, if you care to, and do a search for “ROCK unresponsive” or similar and see the plethora (literally pages upcon pages) of problems people DO have with ROCK.

Again, if this is some Roon problem or a problem in context with my local enviroenement, surely getting to the bottom of it is more beneficial to the Roon team and other Roon users in the long run than seeking time-consuming workarounds. Either Windows is supported or it’s not. Frankly I’ve never understood the reaction to dismiss criticism of the product and start suggesting workarounds beyond what the manufacturer states as being supported. In my line of work, when these kinds of things come up, I’m immediatly curious to find out if this is a problem with the product and look at it as healthy to investigate these issues because there’s no such thing as a purely isolated incident and often looking into one problem can lead to discovery of a larger issue.

All the best to you as well.

1 Like

You can run desktop and server concurrently. Desktop will discover the Core on the same machine and be happy. From a user perspective its the same experience. The advantage is, if you need to kill the desktop because of some issue, server keeps running. Additionally, if its some UI bug you close the desktop when not using and Server keeps going.

But, yes, you’re right in that what you describe is mostly likely one or more bugs Roon should work towards fixing. But, until that happens, splitting desktop and server may make some of the pain go away. It’s the best the community can suggest on a US holiday weekend.


Thank you and I appreciate that. It’s a good point. And as I’m likely doing the uninstall/reinstall dance anyway, perhaps I’ll install Server and go from there as it seems there’s relatively no downside.

1 Like

Here’s another user with a current problem that sounds strikingly familiar to my problem (e.g. new, creeping memory usage problem that clears after reboot).

1 Like

Clearly there is a problem here…

Looks like this consolidated thread was closed with no real resolution.


1 Like

Will try this as a fix and report back.

Fact is, many people are currently having high memory use problems - and on various environments.

1 Like

Well unfortuntaley the .NET framework repair made no difference. Getting tons of endpoint disconnects so i went and checked the server and sure enough, it’s using like 9GB of RAM and counting. Close it and restart and it’s fine for an hour or so and then it just repeats the process all over again. But the real problem is this…

It’s been nearly two weeks now and not a word from “support”. In what universe is this acceptable? I’m just looking for even a teeny tiny bit of guidance as to how to solve this problem. Frankly, it makes me feel like a schmuck for accepting the price increase and buying another year.

I’m one of those guys that is always telling his friends about Roon. I’m a textbook customer evangelist. It just can’t be good business to flat-out ignore loyal, multi-year customers that are practically begging for help. Clearly the extra revenue from the price increase is not going into customer service. Sorry to say, but getting support just feels like an uphill battle against an adversary at this point. No chat, no phone, no formal tickets…just post on a forum and…wait. For how long? Well nobody knows for sure. Maybe idefinitely.

It’s just indefensible.

Plain and simple, as much as I love Roon, I just can’t stomach continuing to pay for a service from a company that clearly doesn’t care about me enough to even acknowledge that I’m having trouble.

(And I’d like to make it clear that this is not a personal attack on the support staff who I’m sure are working hard to do everything they can to keep up. And I’ve had great interactions with professional people like Connor and others in the past. This is a company dynamic that I’m being critical of).


My logs show numerous and repeated reports of “Network reachability changed”. Could this have something to do with it?


Another weird thing:

When i open my main remote (Windows 11 desktop) I often see my previous focus terms duplicated. So if I was focusing on “Jazz”, when I open Roon remote again it has “Jazz” listed twice in the focus area. Only started seeing this in the past couple months around the time this other nastiness started. No idea if they are related but it’s still odd.

I just closed and reopened and it looks like this…


14 days. And not a peep.

Hi @Brandon ,

Thanks for your patience here. I activated diagnostics mode and I noticed that you are getting quite a lot of network reachability errors in your logs.

This error can happen if you have a faulty cable/driver/switch and the connection keeps being re-negotiated over and over again or if your switch has some kind of Energy Efficiency setting where it turns the connection on/off.

Do you only have one networking interface active at this time? These network reachability messages come from the Operating System itself:

Line  4907: 06/05 22:55:15 Trace: [broker/accounts] network reachability changed. refreshing
	Line  4927: 06/05 22:55:15 Trace: [client/roonbridges] network reachability changed, sending discovery query
	Line  4935: 06/05 22:55:15 Debug: [tidal] network reachability changed. refreshing token
	Line  4950: 06/05 22:55:16 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
	Line  4954: 06/05 22:55:16 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
	Line  4979: 06/05 22:55:17 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle
	Line  5007: 06/05 22:56:20 Trace: [broker/accounts] network reachability changed. refreshing
	Line  5032: 06/05 22:56:20 Trace: [client/roonbridges] network reachability changed, sending discovery query
	Line  5040: 06/05 22:56:20 Debug: [tidal] network reachability changed. refreshing token
	Line  5056: 06/05 22:56:21 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
	Line  5057: 06/05 22:56:21 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
	Line  5071: 06/05 22:56:22 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle

This is a known-issue, being investigated here:


Thanks Noris, much appreciate your response and looking into this. Not sure off the top of my head why this would be happening. I’m going from my router through a simple unmanaged switch to the NUC. No other devices connected to the switch seem to be having problems, but now that I know what to look for in the logs, I’ll troubleshoot this a bit and see if I can fix or narrow down the error. Will try different cable, move the NUC to directly connect to the router, check NUC and router networking settings again, etc.

Quick questions, could this be an ipv6 problem? Also, could this “reachabilty” problem be with the wireless network that Roon is accessing via the router?

Thanks again for your help and I’ll report back with any useful info.

@noris Since I didn’t hear back I went ahead and investigated ipv6 since a search of this forum shows some other cases of potential “reachability” problems and ipv6. Well lo and behold I turned off ipv6 on the NUC running Roon Core and there are now no more “network reachability changed” messages in the logs. This has also resulted in no more disconnections or dropouts - which is great.

However I’m left wondering if there is a known problem with Roon and ipv6. If so, is there a fix on the horizon? And shouldn’t this be a first point of suggestion for people having this kind of problem versus testing for bad cables or switches? It sure would save someone in the same boat a lot of time and effort troubleshooting. FWIW: ipv6 is enabled everywhere else on my network and I don’t have any problems, even with very demanding applications such as 4k cloud gaming, long video calls, and a lot of simultaneous high-quality streams, etc. Tests show high throughput, sub 3ms latency, no jitter, etc. This is the first time I’ve had to disable ipv6 on any device on the network. Of course I’m willing to consider and/or accept that this is specific to my Roon environment and perhaps ipv6 is working fine for others.

On the downside, this has not fixed what seems to me to be abnormal and/or excessive RAM use. It’s currently up to nearly 9GB after one day (from 2GB at Core restart). I will leave it again over night to see how high it goes. I guess the questions are:

How much RAM should Roon be using?
Why does it increase over time?
Since this is new behavior (last few months maybe), what would have changed about my use of Roon or my Roon environement that would cause this?

Much appreciate the help. Thanks.

1 Like

The Networking Best Practices article has this:

IPv6 has been known to cause issues with network communications. Some ISPs have started rolling out IPv6 support, and customers in those regions have had issues communicating with our services. We recommend disabling IPv6 on the router and all devices.

However, since Roon Labs are developing the use of IPv6 for Roon ARC, this may change in the future. For now, it would be best to disable IPv6 in your local network if you can.

1 Like

Hi Geoff, many thanks for the tip and for pointing me to the official ipv6 info. I’ve now disabled ipv6 across my entire network to rule out any other problems caused by it. Playback is stable and responsive at this point, but I woke to find the NUC unable to show video, requiring a reboot, perhaps due to increasingly high RAM use. However, now that ipv6 is off across the entire network, I’ll watch the Roon Core on the NUC and see what happens throughout today with RAM use. Perhaps the ipv6 and increasing RAM usage are unrelated problems.

Thanks again.

I’m having exact the same problem on my system. The RoonApliance slowly grows in size

this happens even if Roon was not used after system reboot. After the memory usage goes into 15GB+ I have to restart it. Sometimes it will start growing again and sometimes not (usually not). Suggestion: The server should restart after hitting specific memory usage e.g. 4GB.

1 Like

Hi @Brandon ,

Apologies for the slow response here, I’ve been out of the office and just returned.

Thank you for the update here! I just re-checked your logs and indeed, there are no more network reachability changes of note in your logging.

We attempted to reproduce this RAM increase issue in the QA lab by simulating network reachability errors but were unable to do so, perhaps the IPv6 was the missing part of the equation. I’ll mention this to QA and see if we can do more testing here.

Has the RAM usage remained stable since your last restart?

Do you have any network switches in this setup? Is the NUC using multiple NICs or anything else that could be helpful to note in trying to reproduce?

1 Like

The whole network reach-ability messages may be a red herring. It could be that the software becomes slow/unstable due to the memory leak and it (falsely) reports this as network instability. You really need to ask devs with access to the code to look at the precise conditions that can cause this particular log message. It may well turn out that a timeout (due to excessive garbage collection cycles e.g.) is causing the software to reset the networking component of the service.

We can come up with circumstantial factors all day, which isn’t helpful unless of course it happens to allow the bug to be reproduced (enabling devs to figure out the causative element that explains the correlation).


I have similar issues running Roon Server under Linux. After a few days Roon becomes unstable and I intermittently lose connection to the core. If I restart Linux on the machine hosting the core Roon will then run flawlessly for a few days until the instability returns. This behavior is consistent and repeatable. It’s not that big a deal to reboot the core every few days, but I shouldn’t have to.