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.
Thanks!
enough. I turned my Server off 
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â.
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.