I’ve merged both your threads as they seem to be the same issue.
When you mention “it came from Qobuz” are you referring to purchasing a digital copy of the album from Qobuz, or you have it added to your Qobuz favorites via streaming?
You should be able to remove this album no matter, if you purchased the album, after you downloaded it, where did you add it in terms of your local library storage location?
Or, if it’s added to your Qobuz streaming account, simply navigate back into Qobuz and unfavorite the album. Then, you can perform a Library Clean Up and Roon will remove the album from your Roon library.
We took a closer look at a fresh Roon Server diagnostic report, but unfortunately, the logs don’t contain the specific track names/IDs that are spinning.
The good news here is that the logs do show the metadata queue that started at 4,622 tracks fully drained to zero. This means Roon successfully processed metadata for all your re-added Qobuz favorites. The “spinning” you’re seeing isn’t from tracks stuck in metadata processing, those finished.
Are you still seeing issues at this point? If so, I’d safely stop and restart Roon Server, and see if that finally clears things up for you.
I restarted Roon but I still says “adding music to library: of 16 tracks 16 added, 0 identified”. I was going to try to add back some of my “tags” but the first one I tried under “Classical” failed and still says “unavailable”. If I delete the album and re-add it it’s fine but if I “tag” a track to “Classical” then it becomes "unavailable " I’ll leave it as-is for now hopefully you’ll see it.
Thanks for the reply and follow-up! We were able to get another fresh look at a Roon Server diagnostic report, and can confirm:
This isn’t a storage-permission, Full Disk Access, or Qobuz-authentication problem. Those layers are all healthy in the logs. The “unavailable” behavior is being caused by corrupt image references carried into the restored database, and they crash Roon Server’s library engine on the tag-compute path. That is exactly why tagging a track to “Classical” makes it go unavailable.
The root cause: On startup and whenever an affected tag is recomputed, the library mutation crashes:
Critical: Library.EndMutation: System.NullReferenceException
at Sooloos.CompressedImageUri.ToString()
at Sooloos.CompressedImageUri..ctor(String path)
at Sooloos.Broker.Image..ctor(MPImage image, Image successor_to)
at Sooloos.Broker.ImageCollection.TryGetBestImage(...)
at Sooloos.Broker.Music.LibraryPerformer._Load(...)
...
at Sooloos.Broker.Music.LibraryTagAlbumItem.Refresh(env, LibraryTag tag) ← tag
at Sooloos.Broker.Music.LibraryExplicitTag._OnComputeForType(env) ← explicit tag
at Sooloos.Broker.Music.Library.EndMutation()
Independently, the image database itself contains a row with no URI, and this is still firing on the two most recent days:
06/13 18:56:22 Critical: scx: can't insert image without uri at Sooloos.Broker.ImageDatabase.PutImage(...)
06/14 18:56:22 Critical: scx: can't insert image without uri at Sooloos.Broker.ImageDatabase.PutImage(...)
This is a database-level artifact of the backup→restore onto the new Mac mini, not anything in the file system or the streaming services.
This directly aligns with your issue progression:
"Tag a track to Classical → it becomes unavailable" → the explicit-tag recompute hits the null image URI and EndMutation rolls back. The tagged item is left unavailable.
"Delete the album and re-add it → fine" → re-adding rebuilds clean image/credit references, so the bad row isn't in the path anymore.
Scope is large and skews classical: roughly 4,000 distinct tracks are flagged IsAvailable=False across the sessions out of a library of ~7,300+. The flagged items include whole classical albums, John Williams in Vienna (every track), Seattle Symphony Portraits of Freedom, Jordi Savall Beethoven Révolution, which lines up with the "Classical" tag being where you first noticed it.
All of this said, here is what the best next steps are:
Recommended next steps
The rebuild you already proposed is the right call. Because the corruption is baked into the database you keep restoring, every restore reintroduces it. Starting fresh on the current version and re-importing avoids carrying the bad image rows over. The cost is low: Qobuz favorites and playlists re-sync automatically from the account (auth is healthy), local files re-import from /Users/mallen/Music (access is healthy), only Tags and a handful of settings need manual rebuild. You won't lose the music, just the tags/groupings.
Before you wipe it, we’d like to grab a fresh backup of the current (damaged) database. The NullReferenceException on a null image URI inside LibraryExplicitTag is a null-handling gap in the tag-compute code, Roon shouldn't hard-crash the mutation on a missing image. I’d like to share these findings with our engineers.
If you could compress and upload a copy of your affected backup, that would be helpful!
Zip up your RoonBackups folder (right-click it and select “Compress…”): 2. Submit the .zip file to us through our Database Issues portal
Thanks. It’s been uploaded. Hopefully someone can make head or tails with it. I gotta admit I really miss my “tags”. I’m tempted to just go back to the old version until the next release. Is there a way to export “tags” to a .csv file?
If you’re able to (it’s not something Roon technically supports) safely, then by all means, feel free to do so until the next Roon Production release is sent out.
Glad to hear the new update helped. Please keep us posted if the issue turns out to be fully resolved, and we will go ahead and close this one out once you confirm everything is sorted.
