Ongoing Qobuz Integration Issue Leading to Lost Metadata (ref#EC7O70)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· [[Subject: Ongoing Qobuz Integration Issue — Still Unresolved After Thread Closure]]

I have been experiencing a problem with Roon's Qobuz integration since mid-February, and the issue remains unresolved more than three months later. I am writing here after following the link provided at the closure of the related support thread.
The final post in that thread, from Roon Staff member Connor, stated that in the absence of more recent reports, the issue would be considered resolved. I would respectfully suggest, however, that a lack of new reports does not necessarily indicate that the problem has been fixed. Users like myself, who were waiting in good faith based on repeated staff assurances that the issue was being actively worked on and that any fix would be applied automatically, had no reason to continue posting in the thread. After waiting for more than three months on that basis, I was disappointed to find the thread closed without a clear explanation of what had been resolved, without confirmation that affected users had been followed up on, and without guidance for those still experiencing the problem. In my case, nothing has been resolved.

[Setup]
Rock: Intel NUC11TN — Roon Server Version 2.66 (Build 1658) / RoonOS Version 2.1 (Build 271)
Mac OS Tahoe 26.5 (Apple M4) — Roon Version 2.66 (Build 1658)
Windows 11 Home (AMD Ryzen) — Roon Version 2.66 (Build 1658)
The issue occurs identically on both Mac and Windows.

[Description of the Problem]
Around mid-February, several dozen Qobuz albums suddenly appeared at the top of my library when sorted by date added, with their added dates changed en masse to a specific date just before I noticed the problem. Over time, most of these partially corrected themselves, but 18 albums continue to show the wrong added date to this day.
More significantly, all user-entered tag information and playlist associations for those 18 albums have been lost entirely. Given the size of my library, I cannot verify whether other albums have also been affected, but the loss is confirmed for those 18.
Under Settings → Library → Library Maintenance → Clean up library, I see a prompt to clean up 303 deleted files, which I believe to be Qobuz tracks. This number exceeds even the combined track count of the 18 affected albums (269 tracks). I have not yet executed this cleanup, as I wanted to preserve the state of my library in case a server-side fix would restore these entries.
I have attempted to restore from multiple backups at different points in time. Each restore briefly returns the library to its pre-problem state, but within minutes — or as soon as Roon syncs with Qobuz — all Qobuz albums disappear and then reappear, leaving the same 18 albums and 303 deleted files unresolved. Browsing Qobuz directly via Sidebar → Browse → Qobuz works normally throughout.
At some point after Roon acknowledged the issue and announced that it was working with Qobuz on a fix, 17 of the 18 affected albums appear to have had their added dates quietly corrected. However, no user-entered metadata — tags, playlist entries, or any other custom data — has been restored for any of these albums. The remaining album and the 303 deleted files are also unchanged.
Because I do not know when or whether a full resolution will occur, I have refrained from making any changes to my library — no new albums, no new tags — so as not to complicate a potential recovery.

[Questions]
I would be grateful for clarification on the following points.
First, has the root cause of this issue been identified, and is a full resolution still expected? Second, is there any possibility of recovering the lost tag and playlist data? Third, if I resume normal library activity before the issue is resolved, would that interfere with any eventual recovery of the data that has already been lost?
Having waited more than three months, I would greatly appreciate a timely response and a clear path forward.

Tell us about your home network

· ipTime ***/ no vpn. not want to give anything more info.

2

Hello @Jeongseok_Seong,

Thank you for your detailed follow-up.

To address your concerns directly:

1. Root Cause and Resolution Status This issue stems from a synchronization mismatch between Roon’s database and Qobuz’s API. When Roon detects an unexpected change in Qobuz’s catalog, it can trigger a “refresh” of those items, which inadvertently resets the “Date Added” metadata and creates orphan files in our database. Many instances of this were resolved on the Qobuz side.

2. Can your Tag and Playlist data be recovered? When Roon’s database “flushes” these items during a sync error, the links between those tracks and your custom tags/playlists are broken. While the backup restores the state of the database, the sync process immediately overwrites it because Roon sees the Qobuz tracks as “new” or “re-added” items. This is why your manual tags and playlist associations are not sticking.

3. Resuming Library Activity You do not need to pause your library activity. Adding new albums or tags will not interfere with any potential server-side fix, as those actions occur in a different part of the database than the specific Qobuz sync logic that is currently affecting these 18 albums.

Recommended Path Forward

Since your local backups are being overwritten by the sync loop, we need to manually break the link to force a clean re-synchronization. Please try the following:

  1. Clean up the “Orphaned” Files: Go ahead and perform the Library Maintenance > Clean up library task. This will remove the 303 deleted files that are currently cluttering your database and preventing a clean sync.
  2. Manual Re-tagging: Because the tag metadata for those 18 albums was lost in your database, it is unfortunately unlikely that a server-side fix will “re-attach” those specific tags to the items. Once you have performed the clean-up and re-sync, you will likely need to re-apply the tags to those 18 albums.

Thank you for your patience while we get this sorted.

3

Subject: Follow-Up Questions and Clarification Request — Continuing from Previous Thread

Thank you for your response. I understand the explanation of the current situation and the recommended course of action. Before proceeding with those steps, however, I would appreciate further clarification on several points, as well as answers to some broader questions about this issue. I will address them in order.

1. The Nature of the 303 Flagged Files and the Recommendation to Delete Them

Your response recommends performing the Library Maintenance cleanup on the basis that the 303 flagged files are orphaned entries created by the synchronization mismatch. However, the figure of 303 exceeds the total track count of the 18 affected albums, which stands at 269. This discrepancy suggests one of two possibilities: either additional albums beyond the 18 were silently affected by the sync error, resulting in further file losses that have gone unnoticed; or the 303 files are not displaced tracks at all, but residual data generated as a byproduct of the error process. As there is no way for me to inspect the contents of these files directly, I would ask that their nature be explained clearly before I proceed with an irreversible deletion.

I would also like to raise a related concern. Your response notes that server-side restoration of user-defined tags is unlikely. However, communications in the previous support thread repeatedly indicated that a fix would be applied automatically once the issue was resolved, and I — along with other users — waited more than three months on that basis, refraining from any library activity in the meantime. If automatic tag recovery was not technically feasible, that should have been communicated more clearly at an earlier stage.

2. The Handling of System-Generated and User-Entered Metadata

This issue has highlighted a distinction between two categories of metadata. The “Date Added” field is generated and managed automatically by the system, whereas custom tags and playlist associations are built manually by the user over time. In this case, both were reset by the same sync error. The former has been partially restored through server-side corrections; the latter has not, and your response confirms that restoration is unlikely. This suggests that the current sync logic does not distinguish between these two categories when initiating a reset. Given that Qobuz’s catalog will continue to change over time, I would like to know whether the sync logic has been updated to ensure that user-entered data is protected from being overwritten in the event of future catalog changes.

In my particular case, the number of affected albums is manageable, and I can proceed with manually re-entering the lost metadata as recommended. That said, if the same problem were to recur on a larger scale — affecting a significantly greater number of albums — manual recovery would not be a realistic option. This is why understanding the direction of a more fundamental resolution to this issue matters to me.

3. The Scope of the Fix and Whether the Root Cause Has Been Addressed

Your response states that the issue has been largely resolved on the Qobuz side. I would appreciate clarification on what this resolution encompasses. In my case, the “Date Added” errors have corrected themselves for 17 of the 18 affected albums, which I take to fall within the scope of what has been resolved. However, the user-entered tag and playlist data remains entirely unrestored. If the resolution refers specifically to the “Date Added” error, it would follow that the more significant problem — the loss of user-entered data — was never within the scope of the fix to begin with, and I would like that confirmed explicitly.

I would also like to understand whether the resolution involved corrections to Qobuz’s catalog data, improvements to Roon’s sync logic, or both. If the fix was limited to catalog-level corrections on the Qobuz side, the underlying vulnerability in the sync process may still be present, leaving open the possibility of recurrence whenever catalog changes occur in the future.

4. The Validity of Existing Backups and Guidance on Future Data Management

My understanding is that restoring a backup created before the sync mismatch occurred would return my database to a state that is inconsistent with the current Qobuz catalog, likely triggering the same sync loop again. If that is correct, it would mean that my existing backups are no longer usable for restoration purposes. I would appreciate confirmation of this. Additionally, once the recommended cleanup and re-sync have been completed and a new baseline has been established, I would welcome any guidance on how best to manage backups and library data going forward to minimize the risk of similar data loss in the future.

I look forward to your response on these points. Thank you.

4

Hello @vadim ,

I posted a follow-up inquiry in response to your reply a few days ago, but have not yet received a response, so I am writing to check in. As the thread is approaching its automatic closure deadline, I would be grateful if you could find the time to review my follow-up questions and provide a reply.

5

Hi @Jeongseok_Seong,

Apologies for the delayed response, and thank you for your patience and the thoroughness of your follow-up. Let me address each of your points.

1. The 303 flagged files
The discrepancy between 303 and 269 is expected, and does not necessarily indicate additional silent data loss. The Library Maintenance cleanup covers several distinct categories: tracks deleted via Roon or removed from a streaming service, files whose storage location no longer exists, and internal database objects such as relationship links and metadata pointers that were created alongside those items and are now orphaned. The 303 figure is likely a combination of these categories — not exclusively Qobuz tracks from the 18 affected albums. None of these are recoverable user data. Proceeding with the cleanup is safe.

Regarding the expectation of automatic tag recovery: that expectation was not accurate, and it should have been clarified sooner. I apologize for that.

2. User-entered vs. system metadata
The Date Added field is system-managed and was restorable; user-entered tags and playlist associations are stored differently and were not. When a streaming object is updated or replaced, Roon treats it as a new item and the links to previously attached user data are severed. This is expected behavior given how streaming catalog changes propagate.

3. Scope of the resolution and what to expect going forward
The Date Added issue was caused by a change on the streaming side that has since been addressed. You should not expect a recurrence of the same incident.

However, the loss of your user-entered metadata for those 18 albums is a separate matter. Those tags and playlist entries were linked to streaming objects that no longer exist in their original form, and there is no path to automatic recovery.

4. Practical next step
Before running the library cleanup, I’d suggest backing up your current state and restoring one of your pre-February backups and observing what happens when Roon syncs with Qobuz. This will tell you two things: whether your tags and playlist data are intact in that backup, and whether the sync resolves cleanly or displaces those albums again.

If the sync loop repeats, it likely means something has changed for those specific titles on the streaming side — a catalog update, rights change, or ID reassignment — and manual re-tagging would be the path forward regardless.

If the restore holds cleanly, you can proceed from that baseline.

Let us know what you observe and we will advise from there.

6

Report on Backup Restore Attempt and Outstanding Questions

Hi @vadim ,

I followed your recommendation and wanted to share the outcome, along with a summary of what has been established through our exchange and one remaining question.

1. Backup Restore Attempt

I restored a backup from before the issue first appeared, but unfortunately the problem was not resolved. This had already been noted in the previous community thread and confirmed in both of your replies, and I had also attempted it several times previously, as mentioned in my earlier posts. I tried again following your suggestion, but the outcome was the same. The sequence of events was as follows.

  • On restoring the backup, the library initially returns to its correct state. All user-entered data and system metadata are intact, the Date Added fields are accurate, and no albums appear out of place in sorting.
  • Shortly after, the tracks in the affected Qobuz albums begin showing as ‘Unavailable’. At this point, all user-entered data and system metadata are still intact.
  • The Qobuz albums then disappear entirely from My Library, leaving only local albums.
  • After triggering a Qobuz sync — either automatically or manually — all Qobuz albums reappear. However, for the affected albums, only the Date Added field is preserved (matching the original dates from the backup), and the ‘By date added’ sort order appears correct. All other user-entered data and system metadata have been reset. Because the albums sort normally, there is no way to identify which ones were affected unless they were noted in advance.
  • The ‘Unavailable’ markers mentioned earlier are gone.
  • From there, the orphaned files are removed via Library Maintenance, and the affected albums must be located individually and re-tagged by hand.

2. On the Resolution of the Date Added Issue

I accept your assurance that the Date Added error has been resolved on the Qobuz side and will not recur, as well as the acknowledgment that users were left with an inaccurate expectation of automatic tag recovery for an extended period. In my case, 17 of the 18 affected albums have already had their Date Added restored, and I am prepared to take Roon’s word on this going forward. I also accept that manually re-entering the lost metadata for the affected albums, after completing the Library Maintenance cleanup, is the only available path at this point.

3. [A Few Additional Questions]

You explained that when a streaming object is updated or replaced — whether due to a catalog update, rights change, or ID reassignment — Roon treats it as a new item, severing the links to previously attached user data, with no path to automatic recovery. You noted that this is expected behavior.

I have two questions in this regard.

First, independent of this issue — and a situation that predates it and continues to this day — there are a number of albums in My Library where some or all Qobuz tracks are marked as ‘Unavailable’. These cannot be played, but they remain visible in My Library, and all user-entered data and system metadata for those albums and tracks are fully intact. I am curious whether this is governed by a different mechanism from the Qobuz-Roon sync error that caused this issue.

Second, your responses have confirmed that the Date Added error stemmed from a specific change on the Qobuz side and will not recur. However, the underlying sync behavior — whereby a streaming object change severs the links to user-entered data — has not been modified, and this remains expected behavior. Given that Qobuz’s catalog will continue to change over time, it seems that the possibility of similar data loss occurring again for other reasons has not been eliminated. I would like to ask whether there is any prospect of the sync logic being improved to protect user-entered data in the event of future catalog changes. In my case, the number of affected albums is small enough that manual re-entry is manageable, but if the same issue were to affect a significantly larger number of albums in the future, manual recovery would not be a realistic option. With that in mind, I would like to understand what a more fundamental resolution to this problem might look like.

7

Hello @Jeongseok_Seong,

Thank you for the detailed report and for the measured and precise way you have framed your questions.

On the “Unavailable” tracks in your library: This is indeed a different mechanism from the sync error that caused this issue. When Qobuz tracks are marked as “Unavailable” but remain in your library with all metadata intact, this typically means the content is still in Qobuz’s catalog but is currently inaccessible — most commonly due to regional licensing restrictions or a temporary rights issue. Because the underlying item has not been replaced or reassigned, Roon retains the link to your user data, in contrast to the sync error scenario where the item was replaced.

On the prospect of improving sync logic to protect user data: You are correct that the underlying behavior has not been modified and that this risk remains for future catalog changes. We do not have specific plans to share at this time, but feedback of this kind is genuinely useful and we will make sure it reaches the relevant teams.

To that end — we would like to escalate your case to our QA and engineering teams for further investigation. You mentioned that you have a backup from before the issue first appeared and we have a clear reproduction. Could you please upload it to our File Uploader and let us know once it is done? This will allow our team to examine the exact state of the database and investigate why the sync process overwrites user data in this scenario.

We appreciate your patience throughout this process.