Ah - a likely red herring then. Thanks, @Suedkiez!
@Suedkiez is quite correct with the above, thank you for the help on that one!
@Greg_Ince our team is still working on reproducing the issue in-house. That said, we can clearly see the pattern that causes the issue to revert:
The pattern is:
- Any Roon Server restart (including sleep/wake on the Mac, or the external drive disconnecting/reconnecting) causes the external drive to be remounted
- On remount, Roon re-scans the watch folder and treats tracks as needing fresh analysis
- Roon queries its AudioAnalysis cloud API for each track by content hash
- If the cloud has data, it applies it, overriding any local fixes you've made
- The clean-up you did previously fixed it in Roon's local database, but the cloud API apparently still has the problematic analysis values for these specific file hashes
I’d be curious, as a side test - if you move the problematic tracks to a different share location separate from the external drive (like a folder via your macOS desktop, for example) and then follow the same process you did earlier, does the same incorrect data override your previous edits?
Thanks for the additional patience here!
I’ll give it a go @benjamin - will let you know!
Sounds good @Greg_Ince, we’ll be monitoring for your reply and results, thanks again 