I just wanted to let everyone know that I’m tracking this cloesly. As a Qobuz partner, I suspect we have also received the information that was sent to other partners. However since it is Easter holiday in the UK and a couple of the likely recipients are out of the office this week, it’s a bit difficult to check.
However, David Craff, Qobuz’s Product Manager for Desktop, Web Player and Search Engine (hopefully he’s a bit better informed than Clara), posted about the issue on Audiophile Style last Friday stating that status updates would be posted on their Qobuz Club forum. To my knowledge that has yet to happen, but I’ll keep my eyes peeled and report back if I see any updates.
This issue is caused by a caching problem with our content delivery network (CDN). In practice, some of our delivery servers may be serving a corrupted or incomplete file.
Hmmm… it’s a little disingenuous of Qobuz to blame their CDN. My suspicion is that the root cause of the problem is Qobuz themselves migrating their primary source Servers to the Cloud and corrupting files in the process which then got cached onto the CDNs.
I doubt Clara could have hallucinated her response.
We’re migrating all our servers to the cloud and resizing our entire content distribution system.
How can their teams possibly compile a list of affected tracks? It has been a while since I last looked, however, most of the streaming services claim they have 50 to 60 million tracks. It seems like trying to find a needle in a haystack.
It isn’t possible to say as they do not provide any details. However I doubt that it may be using titles but by having found a common factor or factors. So they might simply create a list of, say, files or folders exceeding x MB data, or transfers to the CDNs during a given period etc. They may also only reduce the task by limiting it to popular items like tracks with streaming requests of over, say, 10,000 ( nominal). We shall just have to wait and see the result.
Like a lot of people, I’ve grown to view Qobuz as an essential service. So this disruption over weeks is deeply disappointing. It’s not only the patent technical incompetence in what is, after all, their core business. But the totally unprofessional lack of communication to their customers.
Update just posted on Qobuz Club on the ongoing issues:
Update April 9th 2026
We’ve just performed a cache purge with our CDN, which should resolve the issue for most tracks, including those not streamable via partner apps or Qobuz Connect.
If you previously experienced issues with specific tracks, we’d really appreciate it if you could try again and let us know if everything is now working properly, your feedback helps us. Thanks !
I won’t be back at home till sunday to test some affected tracks on my Vivaldi One. All I can say is that the Gorecki/Upshaw album I already linked previously still shows those odd discrepancies with the 2nd track being labeled as high res and the 1st and 3rd not being labeled as such.
I don’t know if this is tied to the other issue in some way, but this doesn’t look promising.
I just played the Górecki here from both Qobuz and Tidal with identical results. Tracks 1 and 3 are 16/44.1 while track 2 is 24/44.1. So it seems that this is a problem with the master from the record label, and unrelated to the Qobuz caching problems.
Did you have the chance to try it with Connect on a dCS device? Track 1 and 3 didn’t play for me last time.
They obviously play fine locally on my phone.
it’s a little disingenuous of Qobuz to blame their CDN. My suspicion is that the root cause of the problem is Qobuz themselves migrating their primary source Servers to the Cloud and corrupting files in the process which then got cached onto the CDNs.