@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
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.
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.
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.
@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.
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?
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.
James_I
(The truth is out there but not necessarily here)
50
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.
James_I
(The truth is out there but not necessarily here)
54
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.
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
James_I
(The truth is out there but not necessarily here)
56
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.
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.
@support Please advise next steps. Itās been 5 days since the last response.
Is my hardware simply not up to the task? If so, please let me know what hardware you recommend for my library size (with room to grow). What I donāt want to do is invest in a new system and end up in the same place.
6TB Western Digital Purple HDD 5400RPM (Data - 110,000 Local Music Files)
Iāve let my TIDAL subscription lapse for the time being as Iāll likely switch back to Spotify for streaming and return to Foobar2000 for local playback if I canāt get Roon running smoothly.
I wanted to briefly join the conversation and apologize for taking this long to get back to you. Without beating a dead horse, I wanted to mention that weāre still working our way through the numerous requests weāve received lately. Response times arenāt nearly what we want them to be - I am sorry. Clearly, this has an impact in your life (pause from TIDAL, possible return to Spotify) and we want to be here to help.
Iāve gotten in touch with our technical team. Please, bear with us just a little longer
Thank you for the response. When Roon is working, I love it! And now that Iāve had a taste of a unified system for bringing all my music zones together and bringing together streaming and my local library, going back to multiple applications and different solutions for each zone is a bummer to think about.
I respect the fact youāve been inundated with requests, and from what I understand your team is relatively small and I imagine that can be a challenge with such a large user base. I appreciate the feedback, hopefully the technical team can weigh in again soon.
