audio: use versioned Spotify storage resolution

[dereksix]

What changed

• Thread the selected audio format from the player through AudioFile and CdnUrl into SpClient.
• Resolve audio through Spotify's versioned storage-resolve/v2/files/audio/interactive/{format}/{file_id} route first.
• Retain the legacy interactive route as an automatic fallback for older clusters and accounts.
• Add a unit test that locks the route order and format component.

Why

The current signed Spotify desktop client uses the versioned storage route and includes the selected audio-format identifier. Librespot still called the older unversioned route without a format. That route remains available in some environments, so removing it would create avoidable compatibility risk; this change prefers the current contract while preserving the known fallback.

Impact

Successful legacy behavior is unchanged when the v2 route is unavailable. The requested format now stays attached to storage resolution instead of being known only by the decoder/player layer.

Validation

• cargo fmt --all -- --check
• cargo test -p librespot-core -p librespot-metadata -p librespot-audio -p librespot-playback
• cargo clippy -p librespot-core -p librespot-metadata -p librespot-audio -p librespot-playback --all-targets -- -D warnings
• Production fork PCM canary and attended jukebox soak: fresh Spotify PCM, six of six handoffs completed, and zero measured dead air.

[kingosticks]

Out of interest, did this actually fix a problem you had?

…

On Fri, 14 Aug 2026, at 2:45 PM, dereksix wrote: What changed • Thread the selected audio format from the player through `AudioFile` and `CdnUrl` into `SpClient`. • Resolve audio through Spotify's versioned `storage-resolve/v2/files/audio/interactive/{format}/{file_id}` route first. • Retain the legacy interactive route as an automatic fallback for older clusters and accounts. • Add a unit test that locks the route order and format component. Why The current signed Spotify desktop client uses the versioned storage route and includes the selected audio-format identifier. Librespot still called the older unversioned route without a format. That route remains available in some environments, so removing it would create avoidable compatibility risk; this change prefers the current contract while preserving the known fallback. Impact Successful legacy behavior is unchanged when the v2 route is unavailable. The requested format now stays attached to storage resolution instead of being known only by the decoder/player layer. Validation • `cargo fmt --all -- --check` • `cargo test -p librespot-core -p librespot-metadata -p librespot-audio -p librespot-playback` • `cargo clippy -p librespot-core -p librespot-metadata -p librespot-audio -p librespot-playback --all-targets -- -D warnings` • Production fork PCM canary and attended jukebox soak: fresh Spotify PCM, six of six handoffs completed, and zero measured dead air. You can view, comment on, or merge this pull request online at: #1738 Commit Summary • d948599 <d948599> spclient: prefer versioned audio storage route • 8de886d <8de886d> audio: pass format to storage resolution File Changes (5 files <https://github.com/librespot-org/librespot/pull/1738/files>) • *M* audio/src/fetch/mod.rs <https://github.com/librespot-org/librespot/pull/1738/files#diff-b132d14b7cee994889336aa0e65f3a00a6c1416c76b4d46c4452ef89ef7b8f86> (15) • *M* core/src/cdn_url.rs <https://github.com/librespot-org/librespot/pull/1738/files#diff-3a758cdec423ee8463c2a12a27d489d313b53fb79d338d495cb85109cdaf4efb> (15) • *M* core/src/spclient.rs <https://github.com/librespot-org/librespot/pull/1738/files#diff-f260086ef3fd14313478af019594b2ba1e86946a2906a52036641ff1391abc10> (45) • *M* metadata/src/audio/file.rs <https://github.com/librespot-org/librespot/pull/1738/files#diff-61dfbbc73ed5258738f493d44cadf8e81b364ae838dc95bbf82bdcd502c65dd1> (26) • *M* playback/src/player.rs <https://github.com/librespot-org/librespot/pull/1738/files#diff-1b550ae8c2dfcb42fe4328abb560702e7345603215fff908c0b5a227abff0fc6> (3) Patch Links: • https://github.com/librespot-org/librespot/pull/1738.patch • https://github.com/librespot-org/librespot/pull/1738.diff — Reply to this email directly, view it on GitHub <#1738?email_source=notifications&email_token=AAHEHKDVAHYX7YDNGQLLZVD5J4JYDA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DEOBQGI3TSMBWGCTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVRTG633UMVZF6Y3MNFRWW>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHEHKEYA4EB6ZZ4W2ROYFL5J4JYDAVCNFSNUABFKJSXA33TNF2G64TZHMYTCMBXGU4TOOJWHNEXG43VMU5TKMJVGIZDEOBXGM2KC5QC>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dereksix]

Yes, it was prompted by a real production problem, but I ran a controlled A/B before replying and the accurate answer is that I cannot attribute the fix to this change alone.

The original symptom was intermittent Spotify starts where Connect reported playback but librespot produced zero PCM, with HTTP 400 and audio-key errors in the logs. While comparing current desktop-client traffic, I found the versioned storage route and format component used here.

For the A/B I built two binaries from the same production commit with the same session/local-control reliability changes. The only source differences were the five files in this PR: one build used v2-first plus legacy fallback, and the other used only the legacy unversioned route.

The first v2 arm completed 20/20 cold non-local tracks with fresh, continuing PCM and zero retries. The following legacy arm completed 12/20, then Spotify's audio-key service began returning error audio key 0 2. Every subsequent v2 and legacy arm failed with the same audio-key error, including an ABBA rerun with identical 2.1-second key-request pacing. No route-specific storage-resolve, CDN, or HTTP 400 error appeared in either arm.

So the A/B was inconclusive for storage resolution and showed that the later failures were account/session/time-dependent audio-key failures, not a v2-vs-legacy difference. I have also observed v2 return 404 once and the legacy fallback succeed, which validates retaining the fallback.

In short: this change corrects protocol drift I observed while investigating a real failure, and the patched build has been stable in normal use, but I do not have evidence that the storage route itself fixed the production issue. I'm happy to reframe or close the PR if a protocol-alignment change without a deterministic regression is not useful, or add route-level instrumentation if you would like a more isolated test.