Qobuz Playback Issues and Missing Artwork in Roon (ref#CAFOPT)

What’s happening?

Qobuz playback impossible, artwork missing, rescan stuck.

Describe the issue

First symptom noticed:

Qobuz album suddenly stopped playback. Client showed message “Qobuz is slow to
load” (or similar), but Qobuz server status shows no anomalies and the Qobuz
web player plays back just fine.

Playback keeps failing from that point. Restarts don’t help.

That’s when I noticed all Qobuz albums in my library missing artwork.

Clearing the client image cache doesn’t help. In fact, it may have worsened things?
All of my library now shows broken artwork (no artwork or “genre” stock image on
everything).

Client is noticably slow, running at 67% CPU continuously.

Server is running at 27% CPU, 2GiB RAM, which is also elevated from normal.

Restarting (server or clients) doesn’t help.


Then I tried to add a new album - which I happened to need to listen for work.
It’s a folder of mp3s [sic] on my local fileserver. It does NOT show up.
Forcing a rescan doesn’t help. Restarting the server also doesn’t help, but NOW
the client shows a rescan is stuck.

No amount of restarts allows the rescan to complete. Manually identifying an
album doesn’t work at this time: the UI blocks (probably on the same process
that the rescan is stuck on? Even more potentially, this might be related to
the Qobuz integration??)

Restarting the server with the fileshare offline alleviates some of the symptoms:

  • Server CPU and RAM normal (990MiB and 0.6% CPU)
  • A test Qobuz album plays back
  • The client rescan indicator doesn’t show and manual album Edit/Identify is possible
  • However, client CPU usage is still ~70% and almost all album art still missing.

Of course, now all my local albums are offline.
Restarting the fileserver… immediately gets the Roon server stuck on the
rescan. Manually Identifying an album hangs the UI again. I can no longer
laterally navigate different versions of an album I know exist on Qobuz. Qobuz
playback fails again.

Describe your network setup

  • Everything wired 1Gb ethernet.
  • Roon on dedicated linux box.
  • Wifi and ipv6 disabled.
  • All software up-to-date (in fact, ~2 days ago(?) so might be causal?)

Summary

In conclusion, my analysis leads me to believe the rescan lockup is a large factor in this, but

(a) why did it happen (It happened spontaneously without me changing things on the fileshares)
(b) why does it block Qobuz / Identify
(c) what’s going on with the artwork and high load?

Hi @S_Heeren,
Thanks for reaching out to us for help with this issue. Did the Qobuz issue happen over the weekend or on Monday? There was an issue with Qobuz on those days that affected a lot of users.

To address the issue with the fileshare we will need to find the event in your logs. Can you reproduce the issue and let us know the date and time that it happens?

It happened yesterday, when I reported it. I think it was wednesday evening technically perhaps a little past midnight. Here is the playback history showing it cut off mid-track:

To address the issue with the fileshare we will need to find the event in your logs. Can you reproduce the issue and let us know the date and time that it happens?

It’s constantly reproducing. Perhaps not when my desktop (hosting the fileshares) is off-line. I cannot play any tracks (Qobuz nor local library) at all. Nor can I add music. In other words, Roon is 100% broken for me.

In more steps to troubleshoot

  1. I’ve repeatedly restarted with and without fileshares. Nothing unstucks the playback at all. However, I got this screen some times when Roon server restarted while a client was connected:

    The only way to get any Qobuz playback is to restart Roon server while fileshare is disabled.

  2. I then isolated the “41 tracks” that were keeping the storage sync busy. I can zip up these innocuous mp3s - they’re custom midi renders for theather projects that I work on. They will never realistically be identified, and that was never an issue. The first 21 tracks existed in my library since exactly Jan 25th 2023, and were never a problem to playback (even over ARC).

    Since removing these 41 mp3s in two folders, the rescan process NO LONGER stays busy. Qobuz playback kept working after bringing the the fileshares back online. HOWEVER, when I restarted Roon I still got the “Database update” splash screen when restarting Roon. Although the rescan indicator is not show, Qobyz playback is still stuck.

    Also, all album artwork is still broken.

The next step will be restoring a full database backup from Jan 26th.

Okay, restoring the backup (Jan26th) brought everything back to normal. Artwork cache is being repopuplated, Qobuz and local library playback fine, everything stays operational across server restart (without “Database upgrade” nag).

@daniel How shall we proceed? Do I re-introduce the 41 mp3 tracks or do we coordinate this at some point this week?

Clearly we suffered a database corruption issue (this has not been the first time, though, I’ve restored from a backup somewhere early last year when Roon refused to even load with an explicit “corruption” message similar to the “database update” nag posted abve). Signs are that somehow the 41 mp3s might be related. The rest of my library contains zero mp3s:
image

@daniel Still welcome advice on how to proceed before I try to add music again. Also, some artwork is still broken. It seems to not respond to either restarting server, clearing the image cache nor reinstalling Roon Remote (iOS). However, sporadically an album fixes itself?

E.g. Open Qobuz resisted fixing even with repeated manual re-identification (Edit/Identify). However, today the artwork is spontaneously there.

Another album just fixed itself when I manually re-identified it. Some artwork spontaneously re-identified with a different (wrong release) album cover. E.g. one out of 2 CDs in the box set spontaneously got the album cover associated with a 2019 release, whereas the other CD had simply kept the original 1998 artwork which matches the CD set I own:

Hopefully these detailed symptoms help you eliminate/get a lead on the type of unbalance/recovery that has been suffered.

Hi @S_Heeren,

Thanks for your additional information. Based on your account info, it appears that you’re running Roon Server within a docker container, which unfortunately falls outside the scope of Roon support.

If you’re able to move your server over to a supported format, we’d be happy to continue helping.

Is your server hardwired directly to your primary router?

Perhaps testing different DNS servers may help you with your connection to Qobuz - we have seen users have a better experience in the past if they change their Router’s DNS servers from the ISP provided ones to Cloudflare DNS, Quad9 or Google DNS. Can you please give this a try and let me know if it helps?

Thank you :pray:

If you’re able to move your server over to a supported format, we’d be happy to continue helping.

Can you explain how it matters? Containers are just linux after all. We’re not talking about privilege or network issues here.

Yes. However.

@benjamin With respect, I’m not sure you’ve read the information in this thread. This isn’t a connection issue, and never has been.

Clearly it came down to a database corruption. Specifically, of a variety that is not detected by the software startup sanity checks (which, as I’ve told you, did pick up another case of DB corruption last year).

If I can help you get the logs (which should be accessibly to you just as any other linux box, but hey, I’m imagining “trouble” that you might have accessing the relevant logs), I’m happy to assist.

Also, if you’re interested in guiding me getting you the MOST actionable data for a possible reproducer by e.g. increasing the log levels before retrying adding the 41 tracks that were part of the scan issue, I’m happy to work with you on that.

If you’re not interested (I understand! The workload is high enough, and if you can just stamp away an issue as “not supported configuration” that makes a lot of sense), that’s okay. I’m here to help YOU, not in reverse. As you might have noticed, I solved my own issues already.

So, just let me know and I’ll move on without further coordination. I can always create a new, targeted issue should I somehow repro something similar.

I went ahead and re-added the seemingly offending tracks. It just worked without reproducing the earlier issues (which made sense since half of those tracks had been in the library for 2 years).

Let me know if you ever find interest in the reason why the database got silently corrupted and stuck in such a way that playback was impossible. :person_shrugging:

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.