Since restoring my Roon database from a backup onto a new ROCK installation (Intel NUC10i3FNH, Roon 2.71 build 1683), the Played view in Recent Activity behaves incorrectly.
Symptoms
The first two entries (one track and one playlist) remain permanently at the top left most position of the shown list (first and second positions). Newer plays are recorded, but always appear from the third position onwards. Replaying the pinned track creates a second Recent Activity entry in the third position the list rather than replacing the original. The underlying History view is correct. The issue is identical on multiple Roon Remotes (macOS and iOS).
Troubleshooting already performed
Rebooted ROCK. Signed out and back into Qobuz. Cleared the RoonServer/Cache folder. Confirmed all devices are running Roon 2.71 (build 1683).
The issue appears to have started immediately after restoring the database onto a replacement NUC approximately nine days ago as the two pinned entries correspond to plays from approximately the same date as the database restore according to History (about 9 days ago), while all newer plays appear correctly beneath them.
Tell us about your home network
· ASUS DSL-AX82U router with ASUS RT-AX59U AiMesh nodes (Ethernet backhaul), TP-Link and Ubiquiti switches. ROCK server is connected via Ethernet. No VPN in use.
Yes. The issue appears on the home page of all Roon Remotes when using my profile. I have this evening realised that my daughter’s profile updates Recent Activity correctly. So it seems to be limited to my profile.
No. The affected objects weren’t present in the queue for any of my zones. I’ve also cleared all queues and then played another track to test whether the stuck objects would move. Unfortunately, they remained in place.
System Test playlist contains entirely Qobuz content. I do have one of the tracks in my local library as a lower-resolution version, but I specifically added the high-resolution Qobuz version to the playlist.
Was your profile the active profile within Roon when you first initiated the restore?
Just for due diligence, any frozen objects in Recently Added? This will be global to all profiles.
Lastly, logs seem to indicate that the restore collapsed the identity association between the Qobuz and local object of Kid A. Try opening Albums → Focus → Inspector and adding a Duplicates filter. Are the two objects separated? What happens if you merge them or mark them as alternates using the Edit Album tool?
Yes, I believe that my profile was the active profile when I first initiated restore.
No problems with frozen objects in Recently Added. I’ve added a couple of albums today and it functioned as it should.
I checked Albums → Focus → Inspector → Duplicates. Kid A does not appear in the duplicates list.
The duplicates that do appear seem to be expected ones, for example, albums where I have both a local AAC version and a Qobuz Hi-Res version in my library, and albums where I intentionally have separate stereo and mono editions (e.g. The Beatles).
I investigated Kid A further. The local AAC version and the Qobuz version are already shown together under “2 library versions”.
The local version has 10 tracks and the Qobuz version has 11 tracks.
The context menu only offers “Make primary” and “Remove from group”, but both options are disabled (I’ve attached a screenshot).
So from the UI, Roon appears to consider the two versions already grouped correctly, and I can’t see any option to merge them or mark them as alternates.
Ben here, alongside @connor. Thanks for the detailed testing, it’s let us close off one line of investigation and concentrate on the real one.
Kid A is a dead end, and you can stop chasing it. Your screenshot shows the two copies correctly grouped, with the AAC version as primary and currently selected. Those context menu options are unavailable because there’s nothing there to change, the versions are already grouped, and the one you’re viewing is already primary. It won’t show under Duplicates either: 10 tracks against 11 makes these different editions, which Roon groups as versions rather than flagging as duplicates. Nothing to merge, nothing to repair.
Related, the “second entry” when you replayed the track isn’t a duplicate. Played shows tracks, albums and playlists side by side, so a track tile and an album tile are separate objects and were never going to merge into one another.
The pinned entries, though, are a real problem. Two items holding the first two positions while everything newer starts at the third is not how that view should behave, and nothing you’ve done is causing it.
Two additional asks:
Would you send us a copy of your database? That’s the fastest route from here, it lets QA look at those two records directly instead of inferring from logs. We’ll follow up with upload instructions.
Zip up your RoonBackups folder (right-click it and select “Compress…”):
Do you still have the backup you restored from, and any earlier ones? I’d be curious to see if restoring a different backup results in the same issue. Or, if you attempt to re-restore the same backup again.
One practical note: depending on how many backups you keep, your scheduled backups will eventually prune older snapshots, so it’s worth preserving the one you restored from before it rolls off. Thanks for your patience with this one.
Thanks for the clarification—that all makes sense.
I’ve now uploaded a ZIP of my current RoonServer/Database folder through the Database Issues portal.
I still have the backup that I restored from, along with earlier backups. Interestingly to me, the backups are organised by Core ID, so the backups from the original ROCK and the replacement ROCK are stored separately. That seems to imply the backup of the old Core that I restored from isn’t at immediate risk of being pruned by the current Core’s retention policy. I have however copied the entire backup set to my Mac to preserve it while we’re investigating.
I’d prefer not to restore another backup just yet, as I’ve made changes to the system since the restore (including adding a new endpoint), but I’m happy to do so later if QA think it would help the investigation after they’ve examined the current database.
Understood, thanks for the reply and upload @Brian_Laycock! We have a ticket in with our QA team to attempt reproduction, and we’ll be in touch once we hear back from them on their results.
If the behavior changes in the meantime, certainly let us know!
