“Update May 28th – June 19th”
That’s a three‑week window compressed into a single non‑update.
When companies do this, it usually means:
they have no meaningful progress to report.
“The process is still ongoing.”
This is corporate‑speak for:
we don’t know when this will be fixed.
No technical detail, no root cause, no ETA.
For a service that markets itself as audiophile‑grade and editorially premium, this level of communication is embarrassing.
If the problem also manifests itself in new albums published in Qobuz, then it means that they have not yet detected/fixed the cause (they only have a workaround with which they manually fix the effect of the cause).
Steve Swallow. Winter Songs, Track 5 "Five’, only plays 35%. Did this twice. First track still doesn’t play at all as I have already reported. I am in Italy.
Just a quick reminder that since this has been identified as a Qobuz backend/CDN issue, the root cause is upstream. It isn’t a problem with our individual local setups, networks, or specific high-resolution files.
Because the issue is fully understood and sits with the Qobuz’s infrastructure, adding further examples of failed tracks right now just creates unnecessary clutter in the thread.
We really just need to be patient and wait for the backend fix to be fully deployed, sooner than later, hopefully. If the problem persists after that infrastructure work is complete, we can start pooling our notes again. Until then, I don’t think there’s need for anyone to post further track details…
I should mention I’m not an official community moderator, but from what I’ve been tracking, further error details might not be needed. The last official request for track information was more than two months ago ([Support]).
Subsequent updates indicate that the root cause has been identified as the Qobuz CDN, and a resolution is being worked on. In the meantime, using Redbook standard files has been suggested as a temporary workaround. Since Roon is currently waiting on the external fix, additional logs likely won’t change much at this stage.
Another thank you for your continued patience on this sorely felt issue. We didn’t want to stay silent, no matter how scarce the update.
We are continuing to work with Qobuz on a resolution, but we don’t have new information to share at this time. If you’d like an update directly from Qobuz on their end, we encourage you to reach out to their support team.
In the meantime, we’ve made a small change on our side that should improve the experience when a track fails to load. This will be included in our next release.
We’ll update this thread as soon as there’s more to share.
Thanks for your feedback. It makes a huge difference. We know it’s not your fault. We know there’s little you can do. But knowing you are listening with some empathy makes all the difference.
Hello Roon Support team, I am experiencing an update regarding this Qobuz Japan streaming issue.
In addition to Track 2, I found that Track 4, “fortune” (96kHz/24bit Version), from the same album “Rooom” by “Aooo,” is experiencing the exact same problem. The playback fails (it stays at 00:00 or gets skipped).
Here are the updated details from my testing: - The Qobuz native mobile app can play both Track 2 and Track 4 perfectly in 96kHz/24bit without any errors. - If I change the Qobuz streaming quality to “CD Quality (16bit/44.1kHz)” within Roon settings, both tracks play fine. - Other tracks in the same 96kHz album play perfectly on Roon; it is only Track 2 and Track 4 that fail.
This issue affects all output connections (Roon Ready, USB, and I2S). It seems like there might be a metadata mismatch, a corrupt header, or a CDN sync issue between Roon’s decoder and Qobuz’s server for multiple files in this album.
Could you please look into this and request a re-index or re-upload from Qobuz for the album? Album Details: - Artist: Aooo - Album: Rooom (96kHz/24bit Version) - Affected Tracks: Track 2 “Polaris” and Track 4 “fortune” - Service: Qobuz Japan My Setup: - Core: Ediscreation Haydn - DAC: Mola Mola Tambaqui.
Hi everyone,