Roon stuck on "Scanning now"

5 posts were split to a new topic: Infinite scanning on SonicTransporter

Same issue. Been scanning since lastest software update to my Nuc ROCK. Waiting for a solution.

I have a similar problem, endless spinning etc, but my core is on an iMac and library on Synology NAS. Using NFS didn’t seem to help, so I’m using SMB and have the drives mounting automatically as “Login Items”. I don’t know how to fool OSX catalina into thinking an NFS drive is local, as you’ve described for linux. there is no etc/exports I can find. Can anyone translate for me? Command line amature here appreciates any assist.

@evan_campbell, The /etc/fstabs file is a Linux-specific file that maps the mounting of local and remote storage devices automatically at boot time so they don’t have to be done manually from the command line whenever the machine is restarted. OSX started its life as a BSD-flavored Unix so it’s a bit different.

I’ve never mounted an NFS share on one of my Mac boxes but apparently there’s an easy way to do it via the GUI Disk Utility:

Here’s a pretty comprehensive HowTo:

If you run into any additional problems, I can fire up my MacBook and see if I can answer it. But hopefully it’ll be pretty easy.

Thank you @Darryl_Caillouet and @dylan I realized I was not using NFS correctly previously, but now have it correctly configured on the NAS, and mounted on my iMac Roon Core machine. In Roon settings > storage I find them under “Volumes” - where Roon posts a warning not to use “volumes”. Using them anyway, and I still have roon core hanging as before. I can’t see the drives appearing local anywhere other than volumes, in the roon storage “add folder” function. This pic should be explanatory. Have I attempted the work-around as best possible?

@evan_campbell, Because I’m not familiar with your setup, there was one thing about the screenshot that had me a bit confused. The two NFS mounts that are enabled show 8787 + 17928 = 26715 tracks. Yet the dialog box shows 28676 tracks added of 47666. So I wasn’t sure where these other tracks were coming from.

The two NFS mounts show the tracks are imported and that Roon is watching for new files. To me this indicates that they have successfully been scanned. I say this because when I first encountered the problem, my remote CIFS drive had a “scanning…” comment attached to the remote mount that never went away.

So what I’m trying to decipher from your screenshot is that if the two NFS mounts have completed correctly (or have they?), is where the additional tracks being scanned are located. Based on what I saw on my machines, I’m getting mixed messages from yours which is preventing me from making a logical guess as to a possible solution.

Thanks @Darryl_Caillouet I’m pretty confused as well where all those other tracks are coming from because those are the only two drives. I do have Tidal connected. It’s always spinning so never seems done. After a reboot and restart, with no change to config, it now says I have 18990 tracks and stuck on 0/0 added/identified. Weird. @dylan any ideas?

Roon support should really have a look, here. Why are they keeping their customers in the dark?

Hi everyone,

I just wanted to provide an update here — Our team has been investigating this and has reproduced this issue in-house on some variants (while others are working okay). We are currently continuing our investigation and working on a solution with the development team. I can’t provide any timelines just yet, but I can assure everyone that this is a high priority issue for us and our team is working to get this resolved ASAP.

We believe that the OS / kernel version is playing into this and, while we are investigating internally, we are hoping anyone affected by this could provide the following information if you haven’t already:

  • Core machine OS + kernel version
  • Where the watched folders are located, including a screenshot of Settings > Storage.
  • Number of tracks in your library

We’ll continue to pass this information along to the team and as soon as we have more information about this issue we’ll be in touch with an update.


1 Like

I think you have my varying numbers of tracks, but didn’t have my OS so here it is:

This is my storage, on a Synology Nas (ip address blanked)

Roon server is running on a NUC 8i3beh Linux Ubuntu 20.04.1 LTSLinux nuc8i3beh 5.4.0-52-generic #57-Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Both Core and fileserver are running Ubuntu 20.04.1.

The Core is running Kernel 5.4.0-52-generic x86_64.
The fileserver is running either Kernel 4.14.202-odroidxu4 or Kernel 5.4.72-odroidxu4.

Samba is 4.13.1. Switching to NFS cures the problem.

enough. I turned my Server off :frowning:

Hi everyone,

I met with the team this morning to discuss their findings. We’ve been able to track down the root cause of the issue and believe we have a way for this to get resolved for everyone.

What we’ve found is that everyone affected is using the same Linux kernel. With that Linux kernel we can reproduce this behavior, but on a newer kernel the issue does not exist.

Ultimately our update exposed an issue with this kernel specifically. Our update appears to be working correctly for the vast majority of users who are not using this kernel, and our testing has proven that to be true.

For the quickest solution we recommend updating the kernel using these instructions:

Once updated things should be functioning properly. If you’re seeing any issues afterward please let us know!


Won’t you tell us the kernel version affected?

That should be clear from all the posts above: 5.4.0-52.

Personally, I think switching from CIFS to NFS is easier and “safer”.

1 Like

It seems to be working. Thank you so much.

hey @Darryl_Caillouet I was planning to stick with NFS, I noticed today after added new files I must use “force rescan” to get new files added… is it behaving like that for you?

@mavmcl, Mine is behaving that way too. But I didn’t mind because I only add new tracks to my remote storage on an intermittent basis so doing a manual rescan was always my preferred method. I assumed it was doing that because it perceived the new NFS mount as a local drive when it really wasn’t. In the documentation there’s an example of connecting via the Roon interface to remote Samba storage by prefixing the remote location with an smb: tag to specify the protocol. I didn’t do any research to see if there was a way of putting some kind of nfs: tag to force Roon to mount it with a different protocol (in much the same way you can use http: https: ftp: file: etc. to specify how you want to communicate sometimes). Roon might treat the storage differently if it had a clearer idea of exactly where it was and knew the underlying protocol. Right now that information is being controlled by Ubuntu.

Since NFS was developed by Sun over 35 years ago, my guess is that my storage server is aware of the local directory change but the protocol is probably not sophisticated enough to forward those notifications to the primary Roon server through its NFS link unless someone has written some kind of utility to propagate it.

Thanks @Darryl_Caillouet I think I am with you about NFS not propagating the changes to higher layers… I think I will create a zvol, format it with ext4 and duplicate my library there, that way the core vm will really have direct access to the data.