Firstly, I have swapped out the Netgear Orbi WiFi in favour of Linksys Velop, so the timeout issue is not being caused by idiosyncrasies in the Orbis.
I now have two Roon folders that I can switch between. The new one has scanned the same music folder. I have not bothered to synchronise iTunes playlists, and it does not have all my custom artist images.
Starting from the skeletal Roon folder, I could not provoke the timeout switching between Dayroom Aries (ethernet over power line in, USB out), iPhone XS and Lounge Chromecast.
Switching to the full Roon folder, I generated timeouts after a few switches:
PS: I remembered that I had Memory for Photos/Artwork set to 2048MB, so I set it to Minimum. This seemed to make things worse rather than better, and generated:
After adding a new artist picture and downloading a new track via iTunes, I had trouble adding a new artist picture. I quite Roon and on restart received:
I restored last night’s backup:
Then I get a continual blue busy circle:
which is still running, three hours later (still 49:0:0).
I have just tried to enable diagnostics mode for your PC’s new install, but it appears that the diagnostics are not coming through. Can you please send me a manual copy of your logs by using these instructions and send them via Dropbox / Google Drive / Send.firefox.com?
Thanks for sharing those log files, I have forwarded them to QA for analysis. I have also merged your two threads because I believe these issues are related. I will be discussing your case with QA and will let you know after I hear back from them as to what the log analysis indicates.
Thank you again for your patience while our technical team has been looking into this issue for you.
I spoke with our team today regarding their evaluation of the logs from your install. Sometimes, errors like the one you saw can be spurious, but unfortunately in this case they are seeing signs of low level corruption in your database.
This type of error is extremely rare for us and not one that we see often. Our database infrastructure is designed specifically to prevent this type of corruption, and we don’t take this class of issue lightly.
We’ve traced a few reports like this in the past to hard drive integrity issues but generally speaking, this means that Roon is reading information from your hard drive that is different from what was originally written, and the database is now unable to load properly.
What’s Next?
If you’ve been making regular backups, my advice would be to install Roon fresh on your Core machine, and roll back to one of your backups.
I can’t say for sure when exactly this issue started occurring, and it seems like you have already tried to restore a recent backup, so my suggestion here would be to perform the rename of the Roon -> Roon_old folder as you have done so before and try one of your even older backups. After restoring one of the older (or even oldest) backups, I can check to make sure that everything is intact and has loaded up properly.
If the older or oldest backup experiences the same behavior, you will unfortunately need to start with a fresh database.
Again, this class of issue is extremely rare for us and you have our apologies for the trouble here.
NOTE: First Aid will temporarily lock the startup volume.
Verifying file system.
Volume could not be unmounted.
Using live mode.
Performing fsck_apfs -n -l -x /dev/rdisk1s1
Checking the container superblock.
Checking the EFI jumpstart record.
Checking the space manager.
Checking the space manager free queue trees.
Checking the object map.
Checking volume.
Checking the APFS volume superblock.
The volume Macintosh HD was formatted by newfs_apfs (748.77.8) and last modified by apfs_kext (945.260.7).
Checking the object map.
Checking the snapshot metadata tree.
Checking the snapshot metadata.
Checking snapshot 1 of 6.
Checking snapshot 2 of 6.
Checking snapshot 3 of 6.
Checking snapshot 4 of 6.
Checking snapshot 5 of 6.
Checking snapshot 6 of 6.
Checking the extent ref tree.
Checking the fsroot tree.
Verifying allocated space.
The volume /dev/rdisk1s1 appears to be OK.
File system check exit code is 0.
Restoring the original state found as mounted.
Operation successful.
So, should I step back through on-disc and time-machine backups until I find one that does not display the continuous busy wheel?
Thank you for running the disk check and for letting me know that the volume appears to be intact.
Just a word of caution here, Time Machine backups are not supported in Roon and can cause issues if you try to restore them as mentioned in our Backups Documentation.
I would suggest using only the Roon created backups to restore the database, and I would try the oldest one you have available and see if things are loading properly and playback works without issue.
Once you have restored the backup and things appeared intact, please let me know and I can check diagnostics to confirm that the database is intact and everything looks as expected.
Thank you for restoring the database once more. Can I please ask you to manually re-submit logs so I can check them to ensure that the database loaded up properly?
I am not certain what you mean by this, was the intention to add 49 tracks? Is there been any further disconnects or strange behavior since restoring the database?
I uploaded the artist photos which got lost during the restore process, and took a manual backup. All now seems good.
This evening I have successfully played through Conservatory Chromecast and Dayroom Chromecast (I am not yet ready for the aggravation of Aries endpoints).
I suffered several disconnects of my iPad app: as usual, the iPhone was more resilient. I think the iPad problems were a combination of the iPad disconnect problem (Remotes are losing connection to Core machine) and a Develo in the conservatory with a red connectivity indicator, which I rebooted.
Otherwise, playback was flawless.
On your question, on my Aug 6th 9:53pm post, Roon was getting stuck trying to Add 49 tracks to the music library: I was observing that after the Aug 5th backup (my post Aug 8th 6:39am) there were only 13 tracks, which instantly resolved.
Do you have advice for me on the Memory for Photos/Artwork setting?
Thanks for sending those new log files over and for restoring your database once more. I am looking through them and I don’t see any new traces of corruption, but there is some recurring tries to access your Chromecast, much more than I would typically see. I have asked QA to review these new traces for any additional feedback they may be able to provide.
Thanks for clarifying this aspect, since they completed successfully this is a good sign.
What are you Roon Settings -> Library -> Import Settings set to? If you are using “Prefer Roon” then it is possible that Roon is selecting the best artwork available via our metadata services. You should be able to toggle “Prefer File” and it will restore your custom saved artwork. Does that help?
I have discussed your new logs with QA and I wanted to pass on some feedback that they gave me. Since you are restoring an August 5th backup, it is possible that the backup itself can contain latent corruption and would need some time for this corruption to reveal itself in the diagnostics.
Our suggestion is to try restoring one of the older backups, before these kinds of issues started and certainly one before you reported this behavior first occurring (July 5th). I can’t say for sure how back you should go, but if you do not have any older backups, it is suggested that you unfortunately start with a fresh Roon database as to corruption in the future.
Hi Noris, I have had a couple of evenings with successful transfers between the two Aries minis (Conservatory Roon & Dayroom Roon). I have now uploaded the “A” artist photographs.
