Unable to Restore Backup on DietPi After Moving from ROCK (ref#L0CIJ2)

Hello @mookr

Please keep us posted on the progress here.

Hi @noris @vadim

Some quick updates. I’ve been able to do some limited testing this weekend. So far:

  • the restore worked as of end of July

  • listen later and history, etc. show as of end of July (obviously)

  • the local music stats/info seem tied to storage location as they were not restored

    • I had to add the new storage location, populating the roon db
    • not sure yet, but suspect my stats and album groupings are now off: I see the same album individually (multiple versions) vs. the grouped approach before, so will need to clean that up I think (this may take a while – but, that’s speculative as I haven’t really dug into this part yet)
  • Roon ARC, oddly, would not auto-configure, as it did do with ROCK. I had to manually add the port-forwarding (nothing has changed wrt the network)

So, brief summary:

  • I’m glad to have some notion of history back, albeit not up to date
  • But, my tracks and albums have not been de-duped and will need to look into this some more

Hello @mookr ,

Glad to hear that the previous backup worked (mostly) ok.

Is Roon by any chance seeing (or did see) duplicate storage locations? If roon sees duplicate files, it will treat the duplicates as “new” and they will not have any previously associated metadata edits.

Hi @noris

I may not have been clear. I have multiple versions of some albums and they are not yet grouped, so everything is showing as multiple tracks and multiple albums. I have local + Qobuz with some album (but different version) overlaps.

Also, to answer your question: I’ve only (ever) had one storage location. When restoring this last backup, there were no storage locations defined (new mount point relative to backup).

Hi @mookr,

Do you by chance have ‘Show hidden tracks and albums’ enabled in your Roon Settings>General?

See if disabling this setting helps remove the unwanted duplicates. :folded_hands:

Hi @benjamin

That setting was enabled, yes. (Don’t recall the why or when for that, tbh.)

I’m not entirely sure of the result. On the main Home screen, the numbers under tracks and albums have not changed, but when you go into those sections, the totals show as decreased. In addition, I do see multiple albums in the album list – the couple that I’ve checked suggest that these are grouped versions.

With different numbers showing and multiple albums showing in the list (vs. e.g. just the primary), I’m wondering if this is my expectations bumping into standard behavior, or if there is still something “off” with the setup. Not sure. But, I will admit I’m not 100% confident in what my collection “now is”, if that makes sense.

I have to ask - any luck with the diagnosing of my corrupt backup?

Thanks.

Hi @mookr,

to check whether your backup has been properly restored, go to

settings > libray > library cleanup.

if you see large numbers in one of the bottom two categories that match the track count of your local files, your database hasn‘t been properly restored and the local music files have beeb treated as new instead of being reassociated with your database backup:

This is what happened to me when moving from ROCK with internal storage to DietPi as described in the support thread linked in one of my earlier posts.

If you see all zeros there as in my screenshot, everything worked as it should have. But judging from your posts i highly doubt this to be the case. Most likely you‘re encounteted the exact same (unresolved) issue i did.

Working around this is possible, but painful and would require extra hardware (external USB drive and second M2 SSD) and going back to ROCK once more to prepare the migration by moving the local music files to an external storage, reassociating those with the database and creating a fresh database backup to restore from with the DietPi as described in the above mentioned support thread…

In case you want to go down this route and need assistance, feel free to contact me via PM!

Regards,
Roland

Hi @Roland_von_Unruh

Thanks for the insights. Fortunately, my maintenance screen shows zero to clean-up, so perhaps I don’t have to go through what you unfortunately did.

I think what I’m experiencing may be the standard experience if one changes the source path for the music storage location (that said, I’m not sure if this happens if you do not also change OS e.g. if backup/restore only to ROCK, but change music location).

At this point, I’m looking to see how I can get a “clean” view of my library or, rather, how I can get it to be how I want it to be. My preferred approach is to have a single view of an album and its associated tracks at the top level i.e. what I see in the Albums and Tracks view and access grouped versions from an album as needed.

I thought that was how it was presenting before I changed to DietPi, but am starting to second-guess myself now :slight_smile:

But, I can still play music, which is the main thing :slight_smile:

Hello @mookr

Would you kindly clarify whether you have added a new path or modified the existing ones after restoring the backup?

Hi @vadim

After the restore, there was no local storage location set, so I added a storage location to point to my music files.

The ssd and contents have not changed, but the mount point has (backup on ROCK, restore on Dietpi).

Thanks.

Hello @mookr ,

Did Roon at any point see two copies of the same music files at the same time? If Roon did, then it would essentially catalog the duplicate media file as “new” and not have any of the previous metadata associated with it.

@noris No, not duplicate in that sense. This is just what I’m seeing in the library in that when I have multiple versions of an album and they are grouped, there is no de-duplication happening in the album or tracks counts (or the visuals either).

Maybe that is by design?

Hey @mookr,

Could you please share a screenshot of what you’re seeing here?

Thank you!

Yes - see below. This is in my Albums view – see Alt-J for example. These albums are all in my library, but not grouped. I seem to have lost the grouping as part of the restore.

When I group the albums I get the view I’m looking for, see below:

I couldn’t find this in Focus or Preferences, but: is there a way to id albums that are part of the library that are not grouped? I need to go through and re-group these albums.

Thanks.

A quick feedback from my side:

I recently build a ROCK-based backup Roon-Server (Roon 2.57) with internal storage.

Importing the database backup by my active Roon Server (MacOS at the moment) into ROCK went without problems, as expected (this already worked fine in the past).

Out of curiosity I tried migrating a newly created database backup of this ROCK-server back into the DietPi Roon installation.
To my surprise, this went without issue, all edits and favorites etc. were kept intact.

So most likely Roon in the meantime has quietly resolved the underlying issue with migrating database backups from ROCK to other OS’es which caused me so much trouble this summer.

Hope you can sort out the remaining issues with Album grouping as well!

@Roland_von_Unruh Good to hear and thanks for that insight.

I wonder if it has anything to do with versions? I’m restoring from an older backup on 1544 into 1598. :man_shrugging:t4:

I don’t know. The other thing is: it’s not clear how “clean” my original backup was - maybe my grouping was not 100%? It’s difficult to truly know right now if and where an issue may be.

Either way, I can still play music :slightly_smiling_face: Re-grouping will give me something to do over the holidays perhaps! (I would like an easier way of doing it though eg via preference or focus.)

Hi @mookr,

There isn’t a direct way to focus on ungrouped albums, but you may have luck with using:

  • Focus> Inspector > Duplicates, or
  • Date Added → Recent imports

I’m sorry to hear you’re needing to do this manually. I’ll go ahead and mark your above reply as a solution, but if you either want to continue to troubleshoot or have any additional questions, certainly let us know!

Thanks @benjamin Is it therefore correct to presume that there will be no further analysis on the original backup issue of this ticket? (The issue was unable to restore, not “incorrect album views post-refresh”).