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).
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…
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
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?
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.
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.
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.
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?
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.
I had exactly the same symptoms as you describe here, I implemented the swappiness setting described in the thread that I linked below and the symptoms are now no longer present.
Hello and welcome back. System remains more stable and dropouts aren’t occuring. However, RAM usage is still unstable. I just checked and it has gone from 2.8GB at launch to now at 4.9GB a couple days later. It seems better, but clearly still growing. The growth maybe seems to happen when I’m controlling from my Windows 11 remote (FWIW: my use case here is that I’m often intiating shuffle and reshuffle on focus items, lots of skipping, etc.).
What would be considered “normal” or expected RAM use in my case (Win 11 w/ 32MB RAM and 55,000 tracks)? And should RAM remain stable.
I also notice that CPU seems rather unstable too. Maybe this is normal. But even idle it will go from something like 1% to 11% to 25% to 45% and just do that over and over. While playing a single track it will fluctuate between 0.3 and climb to maybe 30%. The only DSP I have going is volume leveling. Again, maybe this is normal behavior. It doesn’t seem to cause any performance issues as far as I can tell.
RE: Networking
My setup is:
NUC–>ethernet–>4 port unmanaged switch–>ethernet–>TP-Link router.
TP-Link router connected to ATT fiber modem.
Remote is Win 11 PC connected to TP-Link router via 5GHz wifi on a dedicated 160mhz channel.
Thank you kindly for your help and please let me know if I can provide any more useful information.
OTOH, I’ve run RoonServer on Ubuntu Server (22.04 currently) for years, two different systems with different networking setups, and I’ve never seen this. Around 30k tracks, most of them in local storage, the rest Qobuz.
I’ve had the Roon Core installed on my Lenovo laptop. Which ran on Zorin OS. 8th gen quad core i7, 16 gb RAM. And currently my Roon Core is installed on my old 2014 MacMini (dual core i5, 8 gb RAM) running on Linux Mint 21.1
In both cases the RAM usage would continuously increase up to the point where the software would just stop responding properly and failing to play music.
With the Lenovo this would happen after about 13.2 gb of RAM was being consumed. With the Mac Mini anywhere between 6 and 7 gb.
After a reboot everything works again, but the issue reappears after a few days. Whether I am using Roon non stop or have it idling. It doesn’t matter. RAM usage will continuously keep creeping up.
I wanted to add my experience to this thread because I was also having network reachability errors and noticed that Roon was being a rampire (RAM vampire). My Roon core is running on a Windows 10 PC with 8GB of RAM, and Roon would use >3.5GB after being open for just 24 hours. This would render my PC and Roon unusable until I closed Roon. After reading this thread and disabling ipv6, it seems both issues have been resolved; Roon is now only using about 800MB of RAM when sitting idle. Thanks to the community for hunting down possible solutions.
I disabled ipv6 on my core (intel nuc with windows 11) by unchecking it on the properties of the network adapter. Since then, memory usage appears stable. I do hope this gets sorted, I’m not aware of any other programs springing a memory leak when ipv6 is enabled.
I was having high RAM usage as well, 7.26 out of 8 GiB after 27 days of uptime.
After rebooting the machine I was at 2.79 GiB and it slowly increased.
I am running ROCK with the latest OS and server.
My ISP does not support IPV6 addresses and although I’m running ROCK and not windows, as @Bruno_Putzeys I disabled IPV6 support globally, and will continue to monitor. Initial results look as though it has resolved the issue though, and I will leave it deactivated until support is able to resolve the issue with a future update.
