I have 5900+ albums, including 860+ which are unidentified (mostly bootlegs), and I think my performance has always suffered because of that. Roon 2.66 seems much better, though. It’s been running pretty well since the update. I added a few albums and it was slow for a day, but after rebooting, its been running fine for almost 3 days.
I always thought that Roon should have an album flag that would cause it to skip the metadata update for content that will never be found, e.g. bootlegs. That would go a long way I think.
Yeah, went away for a long weekend and came back to the forever dancing robot. Server restart took care of that.
Perhaps there should be a “I’m good” mode: in other words, I’m fine with the current metadata of my collection, no need to ping home all the time, with the ability to turn it on or off, or schedule once a week/month/etc. I don’t use or need daily playlists either (have enough saved that rarely get listened too) or discovery.
I’m on 2.66. Performance has degraded to the point it can take 10 seconds to play a track. Library is 25k songs. I restarted the container and it’s fine again but I shouldn’t have to do this. Was not a problem on prior versions
I too have a modest sized library and 2.66 is frequently grinding to a halt using the container version on my Synology 1520+. There is plenty of spare RAM and the container files are on an nvme volume. Performance with RoonOnNAS was much better.
From everything I can tell, this would be a problem with Roon on NAS as well. It seems to be due to the underlying shift to .net 10. The developers have admitted that there are a lot of performance optimizations they’re working on.
I also have to restart the server about every two days. Starting / skipping tracks take about 4-5 seconds, while it was instantly before. After restarting the Roon service all is well again.
I am on an i7 Nuc (with ROCK), 32GB of ram and music on a 2TB internal SSD.
Neither my library nor my setup are really representative of what I would imagine to be a common roon use case, but I noticed one aspect and would like to ask those experiencing performance issues despite decently-sized library and powerful hardware:
Is the degradation you are experiencing, anyhow connected to changes in library or credits, like after adding/removing albums?
Any degradation I see these days is in regard to slowdowns after large queues are created (from randomizing playback of playlists with 1,000+ songs, typically). I also had some initial slowdown after restoring from a database backup in after switching to the Docker solution, which I didn’t do because I needed to but because I was encouraged by others to forge through and document the process This particular slowdown, which lasted a week and a half or so, was caused by all 65,000 of my files (2.8TB) needing audio analysis re-done on them.
No. It’s been about two week since I shifted to the Container Station version and using Roon is like wading through molasses. Doesn’t matter if I use iPhone, iPad Pro, or MBP as remotes. Everything is Ethernet and no other problems on home network Lightning DS app is the alternative for one room when frustration with Roon mounts.
Library is about 700 albums on server and about 400 Qobuz. Roon running on USB SSD attached to NAS and local drive with spinning drives on same NAS. Eight GB memory. Not running multiple zones at the same time nor any DSP.
I’m going to stop/start Roon later today to see if that makes a difference.
For those having persistent issues with Roon since upgrading to 2.65 or moving to a container, please open a technical support request.
To equip the Roon Technical Support team to assist you directly, please follow this link to provide the details of your case to Technical Support: Technical Support Request
Respond to the prompts there to ensure that you’ve performed basic troubleshooting and to ensure Technical Support has the full details necessary to expedite Technical Support’s investigation into the case.
Your responses will create a ticket in Roon Lab’s support tracking system and auto-generate a Community thread in the appropriate section.
Because this Community thread will be in a public forum, please do not include any personal information, such as your email address, postal address or telephone number in your submission.
So your whole /Roon folder with the container is located on an external drive via USB3.2?
I am running such a setup as well (with a much bigger and pretty complex library), and noticed that the containerized roon seems to be more prone to slow/unreactive flash drive performance than previous RoonOnNAS. You might want to make sure you have a really, really fast drive in terms of writing, and that this one is relatively fresh. Had several cases of flash drives (particularly expensive USB sticks) showing degrading performance over the years.
The good news: we’ve found a significant memory leak that is exacerbated by
maintenance. The issue compounds any time there are modifications to anything
in your library, so updating metadata is a significant trigger of the problem.
The not great news: we hoped to include changes as part of the next production
release, however this is a significant change in the heart of the system.
We’re taking care to make sure we don’t make things worse in trying to make
them better.
The ask: Due to the way the issue manifests, it would be super helpful to get
real-world libraries and play histories from users specifically experiencing
the performance degradation. If you’re willing to volunteer to share your DB
with us, let us know here on this thread and tech support will reach out to
coordinate with you on how to go about it.
Though I can’t say with certainty, it is possible that this is the key issue
degrading Roon’s performance over time and through the maintenance window.
We’d really appreciate your help in being able to test against your libraries
to make sure we’ve got it.
Thank you for the initative, @Steve_Becker ! Same here: I can provide files/information upon direct contact/instructions from support. Library of 12,000 albums/140,000 titles, with even split local/ Qobuz/ Tidal.
This particular slowdown, which lasted a week and a half or so, was caused by all 65,000 of my files (2.8TB) needing audio analysis re-done on them.