we have here a Nucleus+, which is equipped with a 4 TB Samsung SSD 860 and this is filled to 81%, ( 107152 files ).
After updating to 1.7, the Nucleus doesn’t stop scanning the hard drive, it has already been at 400 tsd files.
The Nucleus also shows me two hard disks, the older one is from 12.12.2019 with 2.92 TB and the second one is from today and shows me 7.25tb.
Why is that and how can I fix the error?
Thank you very much for a quick solution of the problem.
That last screenshot shows a folder called InternalStorage nested inside the folder called InternalStorage… Have you got the recursion error - it’s very rare, but it has been known to happen:
I can help with the InternalStorage issue without the need to reformat the drive. There are a few things I kindly request from you though:
What is the serial numbers of the affected Nucleii? I see one has a serial number of 94C691A2C233 from the WebUI, you mentioned you had another one affected by this issue?
Can you please create a database Backup of the affected Nucleii and let me know once you have done so?
Thanks for confirming the serial of the second Nucleus. I was able to locate it in our systems, but doesn’t appear to have communicated with our diagnostics servers in a few days, is this Nucleus still powered on and online?
What exactly do you mean by this? Is the behavior the same if you try to access the Nucleus from multiple Roon Remotes/Clients? Is there any change in behavior if you reboot the Nucleus via the Web UI and the Roon Remote/Client as well?
Can you confirm if you have any recent backups of the two Nucleii databases?
Making a fresh backup will help, but if you have recent backups (or don’t have any database edits/settings you need preserved), we can perform more advanced troubleshooting.
I just want to make sure that if there is some data we need to preserve, we do this before performing the more advanced troubleshooting steps.
the second nucleus has been off the grid for days.
Both Nucluii belong to end customers of ours and I can’t backup the database because I don’t have the access data of the customers.
But that’s ok, we can now start with the first device with the serial number 94C691A2C233, when we are done with this device we can raprieren the other one.
Apologies for the delay, I was away from my desk. I just issued a storage refresh command for the first Nucleus:
Can you please check to see if it helped with the issue this Nucleus was experiencing?
The next steps following this refresh is to clean up the Roon database (Note: you may want to ask the user to run these steps once the Nucleus is back in their possession):
Connect all of your active media locations to the Nucleus
Important - Go to Roon Settings -> Storage and verify that all your locations which contain media files are currently connected to the Nucleus (make sure that nothing you use on your day-to-day is listed as offline - this includes NAS and any external USB Storage you may have)
Go to Roon Settings -> Library -> Clean Up Library
Select all of the 3 options listed there and perform a library cleanup (deleted files/not associated with storage location/disabled storage locations)
Perform a library cleanup
Reboot your Nucleus
Let us know if the same behavior is still occurring
Happy to hear the issue was resolved on the first Nucleus!
I issued a storage refresh command via our diagnostics system. This is not something that you can run manually on your end, we have to issue it from our side.
There have been a couple of reports regarding this issue and QA is looking into what causes this behavior. If you by any chance have any additional info as to how the user’s go into this state, please let me know so I can inform QA for their investigation, information such as how the users typically add new files to Roon (do they use drag-and-drop in the Roon app or connect via SMB to the share)?
I’m not seeing the second Nucleus show up in our diagnostics systems. Can you perhaps try to reboot it via the Web UI?
the second nucleus is now back in the network.
You should be able to see it now.
I did nothing more than check the hard drive with the first nucleus, here the “virtual disk” is no longer visible and the core shows the actual amount of data on the disk.
I compared the contents of the disk with the copy of the library, again it shows the correct values.