James_I
(The truth is out there but not necessarily here)
41
My post may not have been clear but I’m not sure what this means. Unidentified albums can still be connected to artists and found by search queries. They are now.
My point was more about the performance of Roon with any significant portion of unidentified albums, albeit I cannot say with certainty that any issues I’ve had specifically arise out of unidentified albums. All I know is that sometimes working with the library slows things down considerably. It just depends on how seriously you take Roon’s recent posts that unidentified albums interfere with performance.
I believe the point was that they are now, and therefore have to be crawled every time you invoke hyperlinks or search, and therefore they add to slowness if there are too many with too many links into the library.
If they were unconnected then they wouldn’t have the performance impact but then they also would not be included as first class content in the library
James_I
(The truth is out there but not necessarily here)
45
Ah thank you for the interpretation. There must be a way to index them without identification so that the performance hit isn’t there. That said, the slowness issues I see are generally not with search. Sometimes.
It only helps if albums are in MusicBrainz as that’s Roons point of reference, all these taggers won’t help Roon identify if it’s not. MusicBrainz Picard is the only one I know that help as it allows you to submit to MusicBrainz releases you have that are not in its database from your rips. Ensure you have added as much as possible first then submit and fill in the stuff on their website You need to sign up and follow its guidelines and in a day or so you can have a lot less unidentified. It’s time consuming and a little daunting at first but after a few it’s easy.
That is an interesting thought. Audio analysis (both background and on-demand) is processed by roon separately from handling the library, that is why one can choose the amount of cores / computing power you can throw onto it.
Except from computing-intense text searches (with regards to ´The The´!) I am not aware of any operation roon is utilizing all cores at once for. So leaving at least one physical core which would not be bothered with audio analysis should make sure the processes are not slowing down each other.
Once all audio files are analyzed, the computing power sucked out by this procedure becomes irrelevant anyways. The question is: what is roon doing with the results of the analysis and to which extend is it inflating the internal database, causes intensive processes and slowing things down?
Honest answer: we do not know. There was a comment by member of roon team Connor about 150,000 unidentified tracks inevitably slowing things down hinting to that direction. It is somehow matching my experience with unidentified chunky files (such as DSD128, DxD or PCM352) and similar files slowing down roon in the most significant way.
Everybody’s frustration who is finding roon not being as snappy and pleasant to use as it used to be is fully understood. I personally would, if owning a library of 500k+ tracks having invested a considerable amount of time into it, invest some more time into researching what can be done to solve the problem temporarily and make roon useful again.
I did that a year ago when almost nobody was talking about performance issues while my roon machine was collapsing showing similar artifacts so many people are talking about in recent months. Yes, it took time and effort to identify albums manually and improve the metadata. And the decision to migrate a part of my library to usually disabled folders way not an easy one (Feeling a bit like a rookie with just under 60k tracks in what is now my core library being active in daily use. Bye-bye to ´Karajan on 333 CDs´!). The last decision was to throw out all DSD files, converting the ones I wanted to keep to PCM88 or 176.
Not sure what the single gain of the latter measure was but the result is that roots runs absolutely smoothly with no issues. Can absolutely recommend to do some experiments of reducing and optimizing one’s library.
Remove those unidentified tracks, hope this is the problem and Roon will fix it
Reboot when Roon gets slow
I opted for a daily reboot. Interesting enough Roon works great for about one day or so before. This points to some throttling kiccking in under certain load conditions (e.g. too many failed queries…).
I did very similar, I keep really big boxes on a separate external USB drive, Disabled in Roon . Before disabling I let Roon do it’s magic of ID and analysis so that it can be switched back on in a few minutes
But you never leave it running, as you you have said you power your core off due to power outages. I imagine this is help masking the problem as it’s not consuming the resources it would if left on.
If your system runs smoothly, that is of course the most convenient way.
If you encounter performance problems, I am not sure if it is best practice to let Roon´s internal database keep all the data related to the disabled albums. Theoretically, they should be ignored when roon is performing computing-intensive operations, but who knows? I keep them out and clean up the library and live with the fact that metadata recognition is imperfect with these albums.
Did you do a total library cleanup after removing (do not forget to backup prior to that)?
Are there any benefits for dosing a backup and wiping the database out and restoring it from backup?
I have never read anything about that with Roon, but many years ago in other area’s we used to wipe filesystems and restore database backups and get great performance improvements.
Has anyone tried this and seen any performance improvements on Roon
Have not heard of that yet. And as we are talking about simply doing a backup of on internal database, neither system nor data like music , I am not sure your examples are comparable.
I prefer the wipeout after removing albums from the library which had been causing performance issues in the past. Just to make sure their traces are totally removed from the current library.
I would not really expect it to compared to slow spinning drive’s of the late 80s with poorly performing filesystems where moving data to contiguous blocks had a huge performance improvement for a few months.
Good to confirm that it doesn’t though thank you.
I was mainly wondering if cruft is left behind that isn’t cleaned up by a Library Clean up.
So if the album is matched by SongKong to MusicBrainz it will add MusicBrainz identifiers to the matched tracks. And I believe (perhaps Roon can confirm) that Roon will recognize and use the matched album as a the match.
If SongKong matches to Discogs then Roon does not recognize DiscogsIds, however with the improved metadata added by SongKong now Roon is more likely to be able to match the songs to its AllMusic catalog.
Now, if it still cannot find a match I would be interested to know if there any difference to Roons behaviour for unidentified albums that have good metadata, and unidentified albums with no metadata, does Roon treat them differently or exactly the same ?
They are very different beasts so it depends what you want, or use both!
To try and summarize fairly in one long sentence Yate is very flexible for automating manual editing but not designed to automatically match multiple albums in one go, SongKong main power is accurately automatic matching of multiple albums, and also automatic duplicate deletion but it’s (automated) manual editing is more limited than Yate.
