Monterey 12.1 seems like a big improvement. It’s too early to tell if it’s completely fixed the memory leak(s) on my Mac mini M1, but it’s definitely slowed it right down. No appreciable increase in RAM usage for Roon Server, but a marginal increase for the Roon client over the same time period.
My MBP i9 64Gb on Catalina uses 10-25Gb of memory for 900000 tracks (but i have to restart every day, because when start to play it is skipping tracks) . The last big update seems to resolve the track jumping issue , but the next small killed 50% of my artworks I hope Roon will fix all of issues on mac very soon…
I spoke too soon. Roon Server is still chewing its way through RAM, necessitating a restart every few days to prevent slow downs.
Yeah, mine is eating way too much also. When I look at how much Plex uses, doing essentially the same job as Roon, except not only does it have the same music and Tidal integration, but video and pictures as well. Further, there are active users on Plex, while at the time of the below screenshot, no active users on Roon. It seems to be there is some architectural decision limiting Roon’s ability to manage memory properly, or the devs don’t believe it’s a problem. Believe me, over 6G of RAM being used, is most definitely a problem.
Here is Roon (after 5 days)
Here is Plex after months
I am nearly getting to the point where I just want to turn Roon off and use Tidal because it’s easier and the time it takes to start Roon these days is also appalling.
In the chance case someone from Roon comes here, any chance you guys can dream up a way of making Roon use MB’s of data instead of GB’s like the competition does?
I’m also seeing a large rapid memory leak with the latest Roon. Roon Core has been running for years without issue on MacOS High Sierra (old system so can’t be upgraded). Recently, Roon has been triggering system out of memory errors. I just logged it from initial startup of Roon - to the first system message appearing is about 5 minutes - at which point Roon has slowly grown from an initial 2Gb of Memory to just under 10Gb (the amount of physical memory in the system). At this point, the system slows to a crawl and is unusable. I can’t currently use Roon at all. Any suggestions?
I wouldn’t run an old OS. You could try putting a modern Linux on that Mac, and see if you do better. Roon has been upgrading the foundations of their Core software, moving to the official .NET platform from the older Mono base, so I wouldn’t be surprised if older platforms begin to fail.
What kind of Mac are you running the Core on?
Just like What Bill says, it can be a better solution to install your Core on e.g. Linux if it is possible.
A mac mini e.g. i5 or i7 supports this and has proven to be a stable platform.
In general, running applications on old not updateble operating systems is not advised.
I also experience the memory leak issue. It seems it’s getting worse lately. Typically, Roon uses +/- 3.7gb of RAM but slowly crawls up to 5gb or more, even if Roon is not in use. Then switching albums or songs takes 10 sec or more and the app in iOS becomes unresponsive. Things improve if restarting Roon, but problem comes back sometimes over days and sometimes over minutes.
The problem has gotten worse lately, not sure if because of Roon or OS updates.
I’m running Roon (latest version) on a dedicated, headless Mac mini M1 with 8gb RAM and Mac OS Monterrey 12.3
I noticed this too and it seems to be related to Tidal somehow. My linux roon server was using 48GB RAM last week. I resorted to setting up a cron job to recycle the services once a day at 5am. It’s helped, but roon is now starting to crash. I am still looking into the root cause and that’s why I’m here.
Do we have any updates to the progress of this? In my Debian 11 box, Roon is consuming up to 20GB+ when only one endpoint is streaming off of the server.
The worst thing about this is Roon has actually become slow - which is the opposite effect that you would expect from allocating lots of ram. Also don’t know if anyone else has slow initial login times when first starting Roon? Like 5ish minutes. It seems to be related to logging in i.e. if I start Roon and didn’t have cached credentials, then login after a day, it’s still takes 5 minutes or so.
My experience with running Roon Core on Ubuntu 20.04 server has been actually rather positive, since Roon ported the core from Mono to .NET. With my 220.000 tracks it is running very well, with RAM usage between 3.5-6.2 GB, stable, responsive and without need to restart Roon server because of slow-downs as before.
I run scheduled backups in the early hours of the morning, and one thing I noticed is that after a backup run RAM usage drops… there must be some effective garbage collecting going on.
Yes, I’m seeing that too. I’m running on a Synology system with a Linux 4.4 kernel. RAM usage dropped by half overnight (I backup at 3 AM).
Same issue here since the past several month. Before there was no issue at all. I think since a install of a new version this problem was introduced. I run Roon on a QNAP TVS-872XT NAS with 32GB of RAM. After several hours suddenly Roon keeps increasing it’s memory usage and my NAS is using SWAP space as crazy as Roon eats all the physical RAM. My NAS is than almost unresponsive. I am able to stop and start and then memory usage goes back to around 2GB for Roon. Looking at my QNAP grafana two different dashboards it seems there is a pattern. See here the memory explosions (3) of the past 2 days without me doing anything with Roon at all. Note: The 3 little peaks at the right are where I just used Roon (listening to music) and saw the memory usage creep op to around 10GB and I manually stopped and started Roon to avoid Roon filling all RAM again.
I really hope this can be fixed soon as this an unworkable situation. Please Roon team, update us on progress.
Since I stopped swapping since Ubuntu and Linux Mint, I could not share this observation with Manjaro. Is the advantage still there at all? RAM modules have become much cheaper and instead of 32 GB, 64 GB could be so far above that it is enough for 3 million music tracks.
Swapping is meant to harness the benefits of higher levels, i.e. higher speed, and lower levels, i.e. higher capacity and cheaper memory, quasi simultaneously. Usually, the term refers to moving data between memory and disk.
Concrete case here:
It would have to be worthwhile for support to invest time in a clearly recurring problem.
Even some testing could be done in the meantime to see if dormant logins to Tidal or Qobuz, pausing metadata optimization, changed/reduced HiRES settings, turning off audio analysis, or other changes change anything about the memory usage.
Running Roon server on Linux here.
With the 952 build I’ve got regular crashes (every 15 minutes or so) with the following logs:
May 26 16:53:12 prince start.sh: System.Net.Sockets.SocketException (104): Connection reset by peer May 26 16:53:12 prince start.sh: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken) May 26 16:53:12 prince start.sh: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token) May 26 16:53:12 prince start.sh: at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state) May 26 16:53:12 prince start.sh: --- End of stack trace from previous location --- May 26 16:53:12 prince start.sh: at System.Threading.Tasks.TaskToApm.End[TResult](IAsyncResult asyncResult) May 26 16:53:12 prince start.sh: at Sooloos.RnetJsonClient.<>c__DisplayClass65_0.<_BeginRead>b__0(IAsyncResult ar)
Can you look into this? This is super annoying.
@support any response? I’ve reported this 2 days ago and right now I can’t listen without continuous crashes.
Ok, can confirm this is a memory-leak
[ 9441.112703] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/roonserver.service,task=RoonAppliance,pid=984,uid=0 [ 9441.112828] Out of memory: Killed process 984 (RoonAppliance) total-vm:35070392kB, anon-rss:12722048kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:43192kB oom_score_adj:0
I appreciate you bringing this to our attention. I’m very sorry that we didn’t circle back to you before the U.S.-based tech support team signed off for the extended holiday weekend here.
A persistent fatal crash is beyond frustrating. The team is actively investigating this issue and we hope to have more information soon. The moderators have moved your thread into the consolidated thread where we will be posting updates about this issue.