Roon Slows Down Over Time, Core Server Reboot Temporarily Fixes Problem

Ubuntu Server 20.04.2, 25k tracks (mostly local):

$ du -s -m ./RoonServer/Database/
4528    ./RoonServer/Database/

No evidence of memory leaks/slowdown over the last year.

Thanks for the feedback Fernando and I am glad to hear you haven’t had any slowdowns. How much space does your Roon Database take up? Mine is taking up 10.4GB of disk space and @noris 's example is 114MB.

Fernando’s Roon Database is 4528 MB… Mine is 7710 MB.

FWIW, I have noticed that when using Roon mainly for music playing, with only the occasional new album being saved into the database, the memory usage maintains itself quite stable. It increases along the day with Roon usage, and goes back down during the night.

@noris I am still awaiting troubleshooting steps. This morning Roon is painfully slow again after a few days of good performance. I did add 3 albums to my library yesterday, 2 composed of local files and 1 from TIDAL. I imagine this initiated a meta data update on my library, maybe that is what is causing these slow downs?

Here are two screen recordings from my iPhone. One shows the Artist page taking 22 seconds to load. The other shows an album taking 22 seconds to start playing after pressing “Play Now”.

Artist Information

Playing Album

At the present moment, Roon is taking up the most memory I have recorded, over 8GB of my 16GB available.

It’s been several days since my last restart. I also noticed last time simply stopping the server and starting it via the Terminal didn’t seem to help but restarting the whole computer did bring back peak Roon performance.

These are the commands I used to start and stop the server in Ubuntu:

sudo service roonserver stop
sudo service roonserver start

Please help.

Bryan, in Ubuntu restarting the roonserver process will release all this memory and speed up all interaction with Roon on the Remote. I do it every 4-5 days.

The correct command is

sudo systemctl restart roonserver.service

1 Like

Thank you @Andreas_Philipp1! That command worked much better, and as an added bonus it’s only one line of code. Memory usage went from 8.2GB down to 4.9GB simply with your restart command and Roon is much more responsive.

Ironically a user in the “Roon Enthusiasts” Facebook Group posted today about Roon’s recommendation for large library sizes which I was not aware of. The user linked to this article which includes comments from Roon’s CTO Brian Luczkiewicz @brian where he recommends running Roon Server on a fairly robust Intel i7 (newer generation) PC with Windows 10:

“Get the fastest consumer-grade i7 you can, at least 4 cores, 16GB of RAM, a 256GB+ NVMe SSD, a big fan to cool the thing, a nice closet to put it in, and a locally connected storage array for the content, and then run Windows 10.”

The user who posted on Facebook today has a library size of over 780,000 tracks and just finished a custom PC build for the task.

I may attempt an experiment when I have time, restoring a current Roon backup to my video editing workstation which is a robust Windows 10 PC, and see if that has any effect. Long term I don’t want my Roon server on my work PC, but if it can help me narrow down these issues it would be worth it. Here I was thinking ROCK on an i7 NUC was where I might need to go, but based on that article perhaps I may need more? Especially as my library grows.

Hopefully support will weigh in soon.

Hello @Bryan_Nieman ,

Thank you for your patience here while we’ve looked further into your case!

Upon review of the logs again, our QA team is noticing that there is repeated connecting/disconnecting of your Chromecast zone (Google-Cast-Group), and we wonder if this is perhaps related to the main issue.

It looks as if there may be something in your environment causing these device to drop off and re-appear again.

Can you please confirm, does the same issue occur for a few days with your Chromecast group turned off (so that Roon is unable to detect it)?

I do have a Chromecast Audio on the fringe of my Wifi’s capabilities. Per your advice, I’ve unplugged all Chomecast Audio devices and then performed a sudo systemctl restart roonserver.service.

I did leave my Chromecast Gen 1 device in play, this is used solely as a Roon Display and it lives about 16 feet from my Wifi Router. It was not part of the single Google-Cast-Group I had setup.

I will monitor Roon performance and report back with any notable changes good or bad.

Thank you

1 Like

@noris The Chromecast Audios are unplugged and right now I am getting terrible performance again. It took over 30 seconds to perform the search “Keep Yourself Alive” and nearly as long to start a song. I am right back at peak worst performance and the last server reboot was only yesterday (due to the latest Roon build update).

I took a look at the current RoonServer log and the system is currently doing, what looks like, a lot of metadata updating. Which is resulting in a plethora of “CouldNotIdentify” results from rarer releases, live albums, etc. which I have quite a bit of.

Example:
03/25 14:32:59 Debug: [identification] <1993263> status: CouldNotIdentify

Support had previously alluded to metadata updates possibly being the cause and this falls right in line with that thinking. If it is metadata update related, what can I do? Will running Roon Server on a faster PC alleviate these slow downs by giving Roon Server more resources to do its metadata thing while also allowing me to use Roon?

Keep in mind this computer is only used for Roon.

Please advise next steps. Thank you.

What software is that a screen clip of?

The screenshot is of the Resource Monitor in Ubuntu Linux. I was originally on Windows 7 and since I wasn’t getting anywhere with the slowdown problem, I decided to wipe the machine and install Ubuntu (thinking ROCK is built on Linux, so maybe Roon would be more optimized for Linux) and completely rebuilt my Roon database to see if that would help. It has not. I am right back where I was with Windows 7, same performance issues.

I have exactly this issue. My Roon core is a reasonably robust Win 10 machine on a 10g network. I don’t think it’s any metadata update. I think there is some computing overhang any time the DB is taxed.

I have the same problem. Roon Core is on Mac mini MD388 (16 GB 1600 MHz DDR3 RAM, 240 GB SSD, macOS Catalina), database is on SSD. Restarting the core once or twice a day is a must. Otherwise, everything becomes too slow: opening the album page, artist page, adding to tag, etc.

+1… Ubuntu Server 20.04.2. Reported several times by many users. There is a memory leak, and after claimed memory has reached a certain point, all interaction with the system is unbearably slow. Support by Roon for this problem has been terrible. I am beginning to understand the disappointment of some users on this forum.

By the way, I have a 24GB database, and most of the space is taken up by the images folder.

Screenshot 2021-03-26 at 00.37.10

My theory is that certain activities in Roon create some post-processing overhead that never goes away. Whether that is a memory leak is for the coders to say.

In other words, if I do a lot of Tag focus queries, that seems to permanently slow down the core until restarted. I have also wondered whether Shuffling or otherwise playing content by using Tags has a similar effect - i.e. that shuffling or playing content via Tags is the same as a Tag focus query and that creates the same processing overhead that slows down the Roon core.

Just playing Internet Radio through Roon doesn’t have the same impact, which is one reason for my theory. Another reason for my theory is that this behavior is very similar to a prior behavior in an earlier version of Roon whereby using the search function slowed down Roon quite a bit. Roon did something to remedy that quite a while ago, but any use of Tags seems to have a similar impact on Roon - especially if they are “indirect” Tags (i.e. you Tag an Artist, but play Tracks via that Tag).

I suggest we keep at mentioning this on the forum to see how many users really are experiencing this.

I have two separate houses, two separate installs, both on Windows 10 machines of reasonable spec (quad core AMD with speed in the mid 3s, 16GB memory, GB or 10g network, DB on SSD, local FLAC files stored on separate NAS with excellent spects, etc. This happens both places.

Roon is great in many ways. It would be great not to have to restart the Core in the middle of a Friday night when I’m trying to rock out. Albeit it would not be as big of a deal if it didn’t take Roon 5 minutes to reload.

1 Like

I’ve only been using Roon since November 2020, and I have yet to dive into tags or bookmarks. I created my first tag yesterday, after the slowdown was in full effect. I’ve never used shuffle. I’ve used Focus, but not much. I use search a lot and I like to dig into connections (related artists, producers, collaborators, etc.). I check out the Discover section at least every other day. I do have several playlists I add to on a regular basis.

The timing of yesterday’s slowdown with all of those metadata updates from my local library really doesn’t feel like it was coincidence which supports the theory you brought up yesterday which is Roon slows to a crawl anytime the database is taxed. I feel like my taxing of the database is almost exclusively centered around metadata updates.

@noris, please let me know what the next step is. I imagine @James_I and @Alexander_Bashlaev would be happy to try troubleshooting steps as well.

Thanks

Yep I’m happy to help troubleshoot. Just in general I’d like to have the DB pepped up as Boolean logic combined queries also seem very slow.

Mmmmmm. Query Optimization? Certain functions in SQL are more system taxing than others, could be the same in leveldb; I haven’t investigated.

I tend to think of a RoonServer PC, as a database server first and then music playback.

Yep, as you said! I have been rebooting my Windows pro PC and restarting Roon every several days to restore Roon back to speed. I was hoping 1.8 would fix this. But no.

Ken