1 Like
While Roon Core is running, it can rely on OS services to tell it whether music folder contents have changed (well, in most cases, it can be iffy with NAS folders). However, when it is stopped, it can’t track folder contents, of course, so it needs to refresh its view of folder contents when it restarts. Technically, I see no other way of keeping Roon Core up to date with respect to the music folders.
A user initiated forced rescan would have the same result. Content doesn’t mysteriously change between Roon sessions unless explicitly triggered by a user, file system corruption or hardware failure.
3 Likes
In my setup it does, as I run Syncthing between multiple servers for redundancy, which can run at any time, Roon Core up or down 
But more generally, it seems good practice to make sure that a music server’s view of the music collection is up to date when the server comes up. I also run MinimServer DLNA on the same server that Roon Core runs on, and MinimServer rescans on startup as well.
I imagine your setup would be an outlier and I get the need for ability to rescan, however, triggering a rescan on restart of the server should be an opt-in behaviour. Most of the time it serves no purpose other than to waste time and thrash discs. I wonder, does Roon core rescan Tidal a d Qobuz just in case also.
1 Like
As an former designer & implementer of complex object-oriented software: making sure at startup that the in-memory representation of the data is consistent with the disk version is way simpler and less bug-prone than assuming consistency and having checks everywhere in the code in case the consistency assumption is violated.
1 Like
So does Roon rescan Tidal and/or Qobuz when a user fires up their core hooked up to a streaming account?
It doesn’t need to, because the only Qobuz/Tidal objects that Roon needs to track are those that the user has explicitly added to their library. In contrast to local music, where everything in the watched folders is supposed to be represented in Roon’s library.
Not being difficult here, but does it go check for those whenever a core is restarted?
And I wouldn’t mind so much if it wasn’t necessary to periodically restart the core to keep Roon functioning properly.
1 Like
No. Which means that occasionally a Roon library object for a streaming service item is invalid, with somewhat confusing consequences as I’ve witnessed. In general, wearing my former software engineer hat, I’d go for avoiding exceptional conditions as much as possible, even if at the expense of initialization costs. But I can see the other side, if initialization costs are very high. My hunch is that the initialization approach seemed simplest before Roon offered external music providers, but then some form of dynamic consistency check was added as well. I remember than when I had my music on a NAS, which did not correctly signal to Roon that files changed, Roon would get somewhat confused when the NAS music files changed, and a complete rescan was the only way out.
Another way to think about this is that Roon is trying to minimize exceptional conditions that could confuse the code or the user.
As a former dev myself I get where you’re coming from, but I think in this situation Roon’s thinking is flawed. There is more likely to be a change in streaming content no longer being available than there is local content disappearing (barring filesystem or disk failure, which a rescan isn’t going to do anything for other than possibly destroy a users library). An opt-in rescan would be the right solution here.
I can’t disagree that an option to not rescan makes sense technically, but in their shoes I would worry that it could cause even more calls to support when users forget how they set it and find that changes in their “watched” folders are not so watched after all…
1 Like
It would be nice to have the option to autos an at startup, or scan manually. Scanning several terabytes of music takes an annoyingly long time.
And restarting Roon is a fact of life, at least for me, several times a day.
2 Likes
Not forcing a rescan should not have any effect on watched folders - the OS would still trigger a notification which Roon acts on.
Following the logic the other way people should not be allowed to drive because there will be accidents and some will be fatal.
Agreed, albeit for me it’s not quite that frequent. Out of curiosity what OS is your core running on?
1 Like
Mac Big Sur, trash can Mac pro, 64GB ram, Roon DB is on a pair of raid 0 ssd’s.
Fresh erase/system install about a month ago, brand new Roon DB. Network is Orbi RBR50 +2 Satellites with cat 6 backhaul, 2018 Mac Mini endpoint, cat 6 wired.
Super frustrating.
While i agree that this “start up-scan” for sure should be optional, there are other parts of the start up sequence that really could to be faster.
However, why don’t you guys consider going ROCK? (Or dedicted server) I restart my servers very rarely, and have at lest two of them running constantly. I migrate the licence when i have the desire to listen to another Core of course.
I’m pretty sure you’re barking up the wrong tree here, Roon Server is remarkably stable imo.
2 Likes
How large is your library? My guess is it’s more stable under Roon OS & Windows because it’s running. Net libraries rather than Mono. Under general Linux and OSX it’s running under Mono.
Still the startup scan is flawed thinking, so this is a feature request to make it optional so that users don’t needlessly wait and drives aren’t needlessly thrashed.
Around 200K tracks (ca 8Tb), a little less when im using my MacBook Pro as portable Roon. (And thats when i usually suffer from starting up the Core, not due to bad behaviour, rather that i shut the computer down since Roon also keeps chatting to the USB drive, keeping it awake…)