Qobuz playback broken: track/getFileUrl returns HTTP 410 (endpoint deprecated by Qobuz)

Open
  • Is something wrong?
#386 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 6 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
go
Domain
cli

Research direction

Start with external/qobuz/client.go, especially trackFileURL, apiFileURL, and validateSecret; then review the SofusA/qobine reverse-engineering notes referenced by the bundle scraper. Reproduce with a Qobuz account and the steps in the issue. Done means playback works with the current Qobuz endpoints and secret-validation errors distinguish endpoint deprecation from invalid signatures.

Written by the indexing model from the issue text.

Description

Summary

Qobuz playback is broken as of ~2026-08-28: every track fails with ERR: qobuz: playlist/get: HTTP 401 on a stale token, and after cliamp qobuz reset + fresh OAuth sign-in, authentication succeeds but playback fails with HTTP 410 from track/getFileUrl, followed by ERR: qobuz: no valid signing secret found.

Root cause

cliamp resolves streams via the legacy track/getFileUrl endpoint (external/qobuz/client.go, trackFileURL). Qobuz now returns HTTP 410 Gone for it — the endpoint has been deprecated. The current Qobuz web player uses /file/url + /session/start, which returns segmented AES-128-CTR-encrypted CMAF (qbz-1) instead of a plain file URL.

The code already documents this risk in the apiFileURL comment:

The current web player instead uses /file/url + /session/start, which returns segmented, AES-128-CTR-encrypted CMAF (qbz-1) requiring a full key-derivation + per-frame decryption pipeline. ... this is a known, monitored assumption.

That assumption just stopped holding.

Secondary bug: misleading error on secret validation

validateSecret() treats any trackFileURL error as an invalid secret, so a 410 from the dead endpoint surfaces as qobuz: no valid signing secret found during sign-in. This is a red herring — the secrets are still valid. Verified by re-scraping the current bundle (play.qobuz.com, /resources/8.2.0-b034/bundle.js) and testing each secret against track/getFileUrl with cliamp's exact trackFileURLSig scheme:

  • Berlin secret abb2... → HTTP 401 (signature accepted, auth required — secret is VALID)
  • Other secrets → HTTP 400 invalid signature (expected, they're timezone-variant decoys)

Since validateSecret probes an authenticated endpoint, all candidates "fail" (410 without auth / with auth) and interactive sign-in fails before credentials are saved.

Repro

  1. cliamp qobuz reset
  2. Start cliamp, select Qobuz, complete OAuth sign-in in browser (succeeds)
  3. Playing any track → ERR: qobuz: ... HTTP 410; during fresh sign-in → ERR: qobuz: no valid signing secret found

Suggested fix

  • Migrate to the /file/url + /session/start pipeline (qbz-1 CMAF decryption), per the SofusA/qobine reverse-engineering notes the bundle scraper already references.
  • Interim: distinguish 410 from signature failure in validateSecret so auth completes and the error is actionable.

Environment

  • cliamp v1.63.2 (latest release)
  • Linux x86_64
  • Qobuz Studio subscription
Dominant language
Go
Stars
4.4k
Forks
307
Avg merge
8d 12h
Merged PRs (30d)
28

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bjarneo/cliamp

All issues in bjarneo/cliamp

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.