Never ever, unless there is a power loss. Which happens for two or three times a year.
Everything Roon shares an 8-port gigabyte Switch connected to one of my routers gigabyte ports. At least as fast as USB3 and super reliable.
Are you on these most current firmware?
Yes I am. However its the lower end 4TB model so perhaps not as robust as yours. Also there could be other culprits - network extender its on. I’m moving it to my main switch to see if that helps.
Cheers
I run the smallest of their two disk boxes with two 12 TB Toshiba drives. Works for me.
Sooo…just how long has Roon known that unidentified albums and changes to the library are the cause of the server slowdowns???
I preferred your deleted reply . It was to the point and summed up the frustration a lot of us are feeling right now
I may repeat it. I just wasn’t ready for a firestorm early in the morning…
I had SongKong analyze my library (analyze only, no changes made to files). I did two runs:
Lossless files, carefully curated turned out a recognition rate of 87.5 percent on musicbrainz and a recognition rate of 81.1 percent on discogs.
Lossy files, metadata as is returned a recognition rate of 75.2 percent with musicbrainz and 77 percent with discogs.
processing speed was 42 tracks per minute with lossless files and 174 files per minute with the lossy stuff.
I wish there was a way to tell Roon to leave those unidentified files alone. Of course they carry metadata. They are just not listed on musicbrainz.
Maybe I will move those tracks to seperate directories, so I can turn Roon confusion off. A daily reboot seems the easier route, though.
Still hope Roon will fix this.
That would be an interesting experiment to see if it actually makes any difference on a library of your size. I suspect that with any given Roon software release/hardware/directory organisation combination there is a tipping point beyond which the system gets very laggy and unuseable. Lots of variables!
I did this experiment with a considerably smaller yet more complicated library and a pretty underpowered core.
Reason being I had a library of just under 200k tracks, more than half of it being classical stuff such as extended collection boxes (´Karajan complete on 333 CDs´ and alike), ripped DVDs and SACDs with zillions of references to a limited number of composers and artists while not being identified by roon and with big files (an opera from ripped SACD can reach 25GB per album easily). This caused roon to slow down and stutter already a year ago.
I decided to cut down my library moving things which I do not need regularly away from my server while trying to identify and tag properly as many albums as possible. The ratio of unidentified albums decreased from 35% to 5%.
It appeared to me that especially unidentified DSD albums and unidentified multi-CD boxes with way north of 1000 tracks per album made a difference. Removing these brought back the snappy roon experience I once knew but eventually I both replaced my server and cut down my core library to less than half of what I had. Despite from snappiness I enjoyed my library being much easier to handle and more pleasant to browse so I left things.
There is still one folder with such classical stuff containing less than 10k tracks but obviously the difficult ones for roon (DSD and multi-CD albums). Enabling or disabling that one leads to a noticeable change in reaction time.
Unfortunately it would be just that. I am not sure if it is worth the effort, as Roon seems not interested in the issue at all.
Having to exclude a large section of my library due to Roons short comings would not sit well with most, it would not for me and I would question why subscribe when I need two apps to manage my library when any other app will do it. Its supposed to be the be all and end all of music management yet it fails when sources have no available metadata, something thats outside of most users controi. Another one of its poorly chosen opinionated decisions.
Are Roon in correspondence with you about this?
Its 12 days since they participated in this thread.
I fully understand it is not a solution for everyone. I happened to like both classical music and pop/rock/jazz and found my way of browsing through my collection using roon´s coverflow, lists ofcompositions and composers much more enjoyable when being in a ´classical word´ or a ´pop/jazz´ environment so being used to switch anyways.
You do not need 2 apps for that, roon with 2 main music folders ´classical´ and ´pop/jazz´ being activated one at a time would do the job. And while I agree that it is certainly a limitation of roon not being well communicated I cannot really imagine browsing through 500k+ tracks active at a time having a considerable number of them tagged but not identified in roon. I mean, tagging 150k+ unidentifiable tracks properly, how long does that take? And is the metadata really consistent within this part?
In comparison I think just deacitiving or activating a folder in roon to hide a part of the library is done in 2 or 3 seconds. And in my case if dramatically improved performance and still does.
If you look at that post from Roon from 12 days ago, it seems highly unlikely that Roon is willing to take a serious effort to look into this. Moving it to the ‘tinkering’ section, being very defensive about it and basically blaming the user does not inspire much confidence in Roon’s willingness to work together with the/any user to address this.
Roon need to fix this issue as it is longstanding and is only going to be more common and frequent amongst future Titan owners with larger collections. That is the whole point of the Titan remember according to marketing blurb (that and updating internals to the latest NUC board, even though intel NUC boards are now EOL/obsolete).
I actually sent a private message to @connor. Did not receive a reply, though. I do not think they are interested in any kind of analysis.
These are tagged properly. The metadata is as good as it gets. Roon is just not able to find albums in its metadata sources. Does not make sense at all.
Doesnt matter if it can be done in this way or not a user should not have deactivate parts of their library period for Roon to perform normally. Its a poor workaround for a poor design decision in an expensive music management application. Management here being loose as it cant manage it at all by the looks of it.
As far as I understand, Roon needs to locally browse through everything like metadata and audio analysis stored in the database related to your non-identified albums every time you do anything like opening a list in roon, performing a search or alike. That’s the computing-intense part and probably the main reason for poor performance with very big libraries or such with high number of unidentified tracks.
I agree it is not a satisfying explanation but I do not see a way to solve this problem. Not doing this intense operation every time you search, filter or compose a list would mean to fully ignore all the 150k unidentified tracks. Also dissatisfying in my eyes as important results might be left unnoticed. More complete Metadata sources seem not to be in sight. Discogs is capable of identifying more albums than MusicBrainz but the consistency of metadata is highly questionable and probably a nightmare to implement into a self-interpreting system like roon. Same with using your locals tags uploading the contained references to roon´s servers for a cloud-based search. It is even questionable in terms of privacy policy.
If I understand the statement by roon´s rep in this thread correctly, they see this as a case of beyond-normal-operation due to the size of library and the number of unidentified tracks. I understand the frustration that such hard threshold like ´roon does not work properly north of 500k tracks or 50k unidentified tracks´ has never been officially postulated (and it should be, if limitations are known). But to be fair, everything above a 250k library is officially declared to be beyond any warranty, at your own risk.
On the other hand, what would be the solution? Reducing the integration of local, non-identified tracks or the snappy user experience for 350,000 within-the-limits users to speed things up for a few dozen 500k±users? Not sure this would be met with acclaim.
I personally can tell that I was frustrated myself when I met the limits but in the end of the day did not perceive my solution as a poor workaround but rather as a purge. As I now have a more specific browsing of my down-to-earth core collection enjoying that everything is nicely tagged. Never really miss the 100k+ tracks in the digital attic. And if I do it takes a few seconds to plug in the external drive and activate the folder. But again - surely not a solution for everyone.
This is all very reasonable, but nevertheless I get the impression that there has been a performance degradation in these recent builds at least in such corner case libraries. (While still no issues with my modest 45K tracks library)
Just a few days ago there was a new topic by user with 1.6 million tracks on a NAS and he said things were fine until he got the update. Support is aware of this case and looking into it, but there sure seems to be a significant number of such reports. And it’s not as if there was a big new feature that would explain it.
But maybe that’s a good thing because it might be fixable