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:
image

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.

Thanks!

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!

3 Likes

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?
Thanks.

@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.