Since updating to Roon Server Version 2.0 build just before 1223 my Roon slowed down tremendously. It sometimes takes 5 minutes for music to start playing. I have rebooted several times and it says it is adding and indentifying 10,000 tracks, but only about 14 are added. I have not added any music.
I have similar behaviour on my iMac with i9 8core, too. 30 to 40 albums adding takes minimum over night. And all the time when starting and nothing has changed in my library RoonServer has some thousands of tracks to check in the queue where later nothing is added.
885.000 tracks, database is 87 Gb.
This must be a bug. This all started when an update came in the midth of february where Roon worked on the internal database.
Thank you for the reports and I’m sorry to hear you’re experiencing slowness. The tech support team will be pulling automated diagnostics from your Cores to help expedite our investigation - please leave your Core online for several hours at some point in the next few days, so the report has a chance to reach our server.
In the meantime, to clear up the possibility of erroneous audio analysis, can you please share a screenshot of your Library clean up settings window? Navigate to Roon → Settings → Library and click on the “Clean up Library” button. This will open a dialogue box listing tracks that are seen by Roon but not added to the library. Are there are a significant number of track files available to clean?
Additionally, it’s worth refreshing your Roon database (after creating a reliable Backup) to stabilize conditions:
Hello Connor,
thank you you registrated our problems.
First of all, my RoonServer is running from now on for about 9 hours, so you can have a look at it.
Second, here is the screenshot of the Clean up dialogue. It shows 350 tracks, that could be cleared. Some 2 or 3 weeks ago I cleared the library of maybe 2000 tracks with this dialogue.
Does refreshing my Roon database after backing up mean to completely read in all of my 885.000 tracks?
Besides that this will take much much time, I had then again (yes, I did this last year because of the problems with the missing native .net for Mac) to manually restore my playlists with thousands of tracks and the bookmarks, too, right?
This would really be insane… I don‘t want to think about that.
Of course. No need to take the database refresh step if the specter of re-analyzing tracks is too grim. It’s a more procedural step than a surgical fix here.
Do you have any playback delays as reported by the OP, or are your symptoms limited to importing and analyzing tracks? Are slow import times limited to large filetypes, or do you experience this with low-quality tracks, as well?
The team is actively investigating diagnostics and will have a more precise step shortly once we sync with QA. In the meantime, an initial parse of recent diagnostics does indicate your storage location is failing to mount properly, possibly causing IO errors and delays in loading locally stored files through backend or temporary filepaths.
@sandmanct, we’re also investigating diagnostics from your account and will follow up shortly.
Yes, there are always playback delays on really all kind of files. Delay is longer when Roon is painfully slowly adding new albums and I think a bit longer with large filetypes, too. A typical short delay when no background activity is happening is about 15 to 40 seconds. With activity in the background, that means adding new tracks this can take several minutes before starting to play. Mostly, the track with the acoustical graph at the bottom shows up in some seconds but playing only starts like said before. Longer RoonServer runtime often means longer delays.
I tested this with Roon instead of RoonServer on the same iMac. Same behaviour there, just a little bit quicker. It doesn‘t matter which Roon endpoint I use - La Rosita Gamma, the iMac itself or my 2021 iPad Pro - there‘s always a delay like said before.
My latest imports of 238 tracks took 9 hours and still left something to add. After reading in new files, there are typically 2000-3500 additions showing up in Roons activity window, but in the end only adding 500-1000 tracks. This are exactly the new album tracks I sorted in the folders. What are the other additions showing up in Roons activity window?
Maybe I should mention that the whole library resides on 2 volumes:
One is an iMac internal 7.7 TB NVME SSD with 5,65 TB of music. This is an APFS volume. The other is an external 64 TB Thunderbolt raid with 42 TB of music, this is an HFS+ volume. The 64 TB raid is for sanity purposes regularly checked with DiskWarrior.
I will later post a picture that shows the scheme how I store my data. Most album folders contain graphics more or less, often embedded artwork and much in hires. There‘s mostly a music analysis graph for every single track present, too.
Since the Roon 2.0 update in October with the .net version for Mac until 2.0.10 everything really worked flawlessly, no bugs for me.
Backup is done on a similar 80 TB raid.
Why there are i/o errors on the mentioned volume is a miracle to me. How could the storage location fail to mount properly?
What would you say when I did a backup of the Roon database (which I backup regularly by drag and drop of the RoonServer folder, I have older databases back to 1.8), then route Roon to the backup raid, the 80 TB volume?
See my system maxed out in times of storage size, storage speed and RAM. To solve the actual problems here will for sure help you gaining experience with large libraries for the future.
My RoonServer will be on for the next 13 hours, so you can again have a look at it.
The team is actively investigating this issue. As you’ve suspected, it appears to be limited to users with large library sizes (roughly 700k tracks and above),.
Doubtless, this is true. I appreciate your efforts to assist in pinning this one down. I’ll report back shortly as soon as the team has a more precise sense of: 1) what’s wrong and 2) a temporary workaround or permanent fix to restore your system.
Just to remind the Roon team, what I posted partly in a different thread:
The sluggish behaviour began with RoonServer update 2.0.11, when the database was somehow rearranged. If needed, I have still an old 2.0.10 database.
I tried everything to exclude network, harddisk performance, bad database. No fault found there.
By the way: adding albums of the same artist goes quicker and when Roon is freshly started adding of albums goes quicker than later on. When music is playing, adding of tracks takes much more time, too. For example: adding 10 SACD DSD‘s of Depeche Mode this morning just took about 15 seconds per album this morning when Roon was freshly started, where as Roon added the whole night when music was playing only about 200 tracks. But strangely the next 2 SACD‘s from Depeche Mode took about 15 minutes, just after the other 10 SACD‘s had been added in 15 seconds each. Here‘s the screenshot from the iPad:
I can report the exact same problem but with only 220,000 tracks. I posted a separate post on this yesterday (there you will find my details). For me it started in November and after my own (primitive) debugging I concluded it is related to ARC.
Same here since -1211 update. The difference is significant and found myself having to reboot 2-3 times a day just to have useable playback. I reported this back in Feb when this release was made Roon became noticeably slower with latest 2.0 (build 1211) upgrade - large library. I also noted several others reporting issues with this update.
Ever since updated with the -1211 and subsequent releases have been “noticeable” / “painful” slow to the point of becoming unusable.
Well, to say at least something positive in our desperate situation:
Roon is really extraordinary when it is in full order. Since 2.0 in October with the native .net for Mac users I know for sure I can handle a ton of tracks and make all usable. In my case, I’m sure I will have a million tracks soon and about nearly 100.000 albums! That means Roon does in most cases its job in between seconds, no matter what it is.
Think of 100.000 discs in the times of CD’s and LP’s…
Now in the digital domain of computers and hard-disks, all I have to do is get the albums and tracks, do a good finder naming of albums and their versions and sort them in the musiclibrary.
If I want and have the time, I can tag albums of my choice and find a hires coverart. But no need for a time eating tagging process, when the basic tags like artist, album name, year of release and track names of course are present when I get an album.
That’s what I always wanted in the iTunes era, when I had to take care much more of time consuming tagging.
Then the sound: Roon is for sure under the best sounding audio softwares - with one difference: It makes connections of artists and albums in your own musiclibrary that one always wanted but you didn’t even think of, despite it even being possible.
These things aren’t easy because of their complexity and different platforms. So despite all the problems, I think Roon is the right choice…
I’m glad we have retained your faith in Roon and we appreciate your candor as well. For those of you just joining this thread, rest assured we’re investigating these reports.
I don’t have a more precise update at this time, unfortunately. What we can confirm is that the issue is a) related to databases containing roughly 700k tracks or more, although hugely dependent on the breakdown of file quality and b) emerged roughly around the shift to Roon 2.0.
Our goal as a support team is to maintain playback and a positive UI experience until we can diagnose what’s really happening here. Towards that end, please continue to post here if symptoms change, and I will do my part to provide and amplify and function workarounds in the meantime.
Diagnostics from your particular setup indicate the API interaction with RooExtend my be involved, in part, with performance decline. Are you using a RooExtend in your setup?
Out of curiosity, do you experience any change of symptoms if you remove RooExtend temporarily from your setup?
Thank you for your continued patience, everyone, we’re still investigating the overall cause here and whether there’s a unifying factor or a constellation of issues that, combined, affect large databases.
