Long on Scanning, Short on "Memory"

How quickly Roon forgets…

After 9 days of scanning my initial library of nearly 49,000 tracks (sans audio analysis, BTW), I was happy that it completed yesterday on July 8. I even started to manually merge albums and fixing issues that Roon couldn’t handle. During this process, I realized that I had 900 tracks on my local SSD c: drive.

Though it may not be the best option, I am using Google Drive (g:) and One Drive (m:) to store my library. I moved the 900 tracks to my g:\ drive. As expected, Roon scanned to find these tracks.

But, why is it rescanning my whole library again? It makes no sense to me. I’m back to around 16k tracks.

Roon seems to play much better from my cloud drives better than JRiver or anything else, but repeated mass scanning renders Roon unusable to me especially if it takes days. Did I miss something. Is this normal?

Roon 1.3 (234) 64bit
Windows 10
Lenovo G50-45 4gb RAM, AMD quad-core 2.4ghz
Google Drive and Microsoft One Drive mapped via NetDrive

Thanks in advance for your help.

Yes, normal. Roon rescans your library upon launch and at configurable interval – default is four hours.

The short of it, storing your library in the cloud probably will not work well.

AJ

@DavidPG You are really in for a rough ride with such a setup…not going to be a good user experience at all…starting with your PC. Offsite library material is the least of your issues. Actually I am surprised it runs at all. 9 days to scan a library is ridiculously impossible to work with IMHO

Recommended Hardware
Intel Core i3, Ivy Bridge+ Not sure how AMD stack up but it a scrapes in perhaps if you are lucky
4GB RAM A scrapes in to be honest
SSD boot drive NOT MET - not even close…this will be the biggest issue - even if all your libraries are locally attached
1440 x 900 Resolution NOT MET

https://kb.roonlabs.com/FAQ:_What_are_the_minimum_requirements%3F

1 Like

Assuming that those “drives” are always available prior to Roon being fired up I can’t imagine that it’d cause you to have to rescan other than Roon’s startup and periodic scans (they’re pretty much looking for changes and don’t take long to run). Different story though if they’re not up when you first fire up Roon.

9 days scanning sans analysis makes no sense …as earlier posts imply, check your hardware.

Where can I find the setting for scan interval? I looked through Settings and didn’t see it.

Thanks

Roon only periodically scans watched folders that are on network shares. We only show the option in the settings for network shares as well. So, one possible reason you can’t find it is just that you’re looking at a watched folder that is on a local drive and the option doesn’t exist.

If you do have a network share, the setting is per-watched folder, and found in settings -> storage -> 3 dots menu for the watched folder -> edit, at the bottom of the window:

Thanks, I use fstab mounts so I don’t have access to the option. Can that be added to the nice-to-have list? As it is I force a restart at night which rescans the volumes, messy but effective.

Ben, thanks for the reply. This makes sense to me especially if the watched is not connected. It’s possible that the cloud drives disconnected overnight or some Comcast internet event. But if the watched folder is reconnected, shouldn’t Roon fall back to what was already indexed?

Maybe my issue was a one-off fluke…

Aside from going offline, adding/deleting/changing files the vast majority of the files in the database will be static. Once the cloud drive is reconnected, I know rescans are necessary. But starting from 0 and rebuilding my db? How do I avoid that?

  1. Even after shutting down Roon and restarting, it did see the cloud drives but not recall existing files. It proceeded to rescan and build as if nothing had previously been done. My other music apps don’t have this problem. They’d indicate file not found and once connected, we’re good again.

  2. I did a restore to quicken the process. That tells me Roon was aware of prior scans. Roon shows my library. But it is still rescanning. Isn’t the algo able to determine changes to the files in db if any from last session and only scan those?

#1 is akin to google reindexing the internet and users not having the ability to access information that it already found while it does so. In case 2, at least from what I can see happening, if it is rescanning the entire directory again that had no changes aside from being unavailable, this is a step that is using resources and bandwidth unnecessarily?

PS, I looked at the automatic scan interval you mentioned. I don’t see that setting on my window. My guess is that my cloud drive and network share are different storage devices according to Roon?

I like the idea though. Can you add a feature to force scans by time/day?

Hi David,

I don’t know enough about the details of your situation to know for sure, but this sounds a lot like the problem we sometimes have with NAS systems and Roon running on MacOS. In that situation, the user observes tracks slowly disappearing from their library and then re-appearing as the drive is scanned. It’s caused by the OS reporting to Roon that the network share is connected and available but empty. I’m guessing that you have the same problem.

If my guess is right:
The reason you observe #1 is that at some point Roon was told that the directory was empty, implying you’d deleted all your music for some reason. We hide tracks in this state to avoid the user experience of trying to play a track and then discovering that it has been deleted.

For #2, Roon does look for modifications in roughly the way you’re expecting, the issue is probably that it thinks the files were deleted.

Re: automatic scan intervals: According to your first screenshot, Roon is showing your network drives mounted as normal non-network watched folders, which don’t do any sort of automatic rescanning. I think this is because you’ve mapped them as normal Windows drives? I might be guessing wrong there.

I could look at logs to try to confirm my guess at the original reason Roon thought all your files where deleted. This basic situation is rough on our assumptions about how files work, so and I’m not sure there are easy fixes available. On thing you might try is setting Roon to watch a subfolder further down into the tree on the cloud drives. That way if a network error causes the OS to report the drives are empty, the directory Roon is watching will disappear, and we’ll put the watched folder into a disabled state instead of thinking the files were deleted. I don’t know if it will work for you, but it’s at least easy to try.