My library is a tad larger than that and you have the advantage of running Roon Server with .Net Core on ROCK, which is one of the reasons you don’t need to restart it as often as Roon Server running on Mono libraries.
If there was a way around mangled filenames using SMB I’d use ROCK, but given my desktop OS is Linux and barring Roon all my apps are Linux native they all allow characters in filenames that Windows doesn’t.
Oh, i see. This is of course a delicate problem, but i’m sure that code tables could be synced and preserve your lettering. Afraid i don’t see why your linux desktop couldn’t stay in code page sync with a Rock-machine though? Is it SMB-related?
It’s Windows related - as soon as you view a *nix filesystem using a Windows device you end up with mangled filenames if the filenames contain character the *nix filesystem allows but Windows doesn’t. So any network shares to a Windows machine are susceptible o the problem unless there’s a workaround I’m not aware of. In Linux one can configure SAMBA (the software that implements SMB in Linux) not to display garbled filenames.
Startup generally is unacceptably slow. I almost burned the steaks last night trying to get some music on. Roon core was super sluggish (happens daily) and the restart took 5+ minutes.
Why should users have to use Rock or some other alternate OS to keep this product stable? I run a few other services on the core that require windows (these are to operate physical buttons on the case and run icue for RGB. Not resource consuming.)
I just brew tea 
I shut down overnight, in the morning fire up brew tea, by the time the tea is ready so is Roon
It is a pain , I assume it’s loading the library into memory
I’m not sure what good that would do. The Mac I’m using for a core is not being used for anything else. It’s way beyond spec for Roon.
Reboots are usually caused by “Having trouble loading this track” “too many errors”, or just fast-skipping through. The queue without playing anything. Restarting the RoonServer software sometimes works, sometimes I have to reboot the machine. ~9TB of FLAC across 3 drives in a Thunderbolt RAID enclosure.
Well I’m just glad it only takes the time required to brew tea. Sometimes I feel like I could brew BEER in the time it takes to load, but really it is somewhere around 6-8 minutes.
Roon is just.not.that.stable. performance-wise. I guess I could figure out how to set a reboot in the middle of the night then relaunch Roon as a startup service in Windows, but the point really is, Roon should address this.
I am a past master at Beer too, I think I might ,moan if startup was 22 days …
I would guess mine takes 4 to 5 minutes,on the times I notice, I don’t often time it , I switch on and walk away to brew tea 
, I am a creature of habit.
I would imagine it’s library size dependent , mines about 160 tracks
If it takes that long to scan for that little we are in trouble. I take it you mean 160k . Lol
OOPs missed a odd K 
What is the harm in just making the Roon library visable to the user ?
One could also ask whether the entirety of Roon’s Tidal and Qobuz infrastructure is rescanned every time a streaming only user fires up their instance. Given it’s not, I can see no good reason to do so with local content - it seems to me to be legacy thinking.
Isn’t this other ongoing feature request thread essentially about the same thing? Together you would have 2 votes 
Yes and no.
I could re-phrase it like this
”Please alert the user when storage is not accessable but still show the library”
There are more things to consider but I as a user want to view my library even of story is de-attached while fixing the problem or waiting for it to be acessable again.
If I try to play something that does not exist I Will just get an error message.
If the storage never comes back again the Library Will be in sync when
I Do a library cleanup or delete the storage and the associated data in the Library has been deleted…yes ??