fix(deezer): recover delisted tracks via FALLBACK instead of a retired CDN URL

[berettavexee]

The problem

When get_track_url returns None, get_downloadable falls back to _get_encrypted_file_url, which builds a legacy AES-ECB URL:

url = f"https://e-cdns-proxy-{track_hash[0]}.dzcdn.net/mobile/1/{path}"

Deezer has retired that CDN. None of the sixteen possible hosts resolve any more:

$ for c in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do
    getent hosts e-cdns-proxy-$c.dzcdn.net >/dev/null && echo "$c OK"
  done
$ # no output — all sixteen fail

So the fallback can never succeed. What the user gets instead is the download being attempted, retried, and failing with:

Cannot connect to host e-cdns-proxy-8.dzcdn.net:443 ssl:default [Domain name not found]

which points at their DNS resolver rather than at the real cause.

Impact

Measured on a real run of 50 loved tracks: 8 tracks (16%) went through this path. Each one burned both download attempts before failing, and the run produced 25 ERROR lines about a hostname that no longer exists.

The proportion depends on the account and catalogue — tracks with older or incomplete GW metadata are the ones that reach the fallback.

What those tracks actually are

This turned out to be the interesting part. They are not unavailable — they are delisted: superseded by another release, typically a remaster. Deezer reports FILESIZE_* = 0 for every tier, hands out no URL at any quality, and names the superseding release in FALLBACK.SNG_ID.

That is the same field get_downloadable already follows on WrongGeolocation. The two cases differ only in how Deezer says no — there the API says "not here", here it says nothing at all.

The fix

Two commits:

1. Remove the dead CDN fallback. _get_encrypted_file_url goes, along with the binascii, hashlib and AES imports that only served it.

2. Follow FALLBACK.SNG_ID when no URL comes back, reusing the existing recursion and its is_retry guard (Deezer's fallback chains can point at another dead entry, so the hop is taken once).

Result on the same 50-track run: all 8 tracks recovered, all 8 as FLAC. So the path that previously guaranteed a DNS error now returns the audio the user asked for. Only when there is no fallback at all does it raise, and the message then says what is actually wrong:

Deezer returned no download URL for this track at any quality, and it has
no fallback track (delisted?). The legacy CDN that used to serve as a
fallback has been retired.

Two details worth flagging for review

The fallback is requested at the caller's quality, not the downgraded one. A delisted track reports FILESIZE_* = 0 for every tier, so the existing FILESIZE downgrade loop always bottoms out at MP3_128. Passing that on would fetch the replacement at the lowest quality regardless of what it offers. requested_quality is captured before the loop and used for the new hop only; the WrongGeolocation branch is left as-is to keep this diff focused, though it arguably has the same issue.

The Blowfish key follows the served track. Recursing passes fallback_id as item_id, so dl_info["id"] — from which DeezerDownloadable derives the key — describes the bytes actually being decrypted. This is worth stating because getting it wrong is invisible: the file has the right extension, the right size and the right duration, and only fails when something tries to decode it.

I verified it rather than assuming it: all 48 recovered FLACs pass flac -t, which checks the stream MD5 stored in STREAMINFO. A wrong key could not survive that.

DeezerDownloadable is deliberately left untouched: its is_encrypted regex still has to match the modern /media/ CDN, and its extension fallback for URLs without one remains useful as a defensive measure.

Tests

Four unit tests in tests/test_deezer.py, all using the existing mock_deezer_client fixture:

• error raised when no URL comes back and there is no fallback
• no e-cdns-proxy URL can leak into the message
• a delisted track is recovered through FALLBACK.SNG_ID, at the requested quality, with the id following the served track
• a fallback that itself resolves nowhere raises instead of recursing

tests/test_meta.py::test_album_metadata_qobuz fails on dev both before and after this change — pre-existing and unrelated.

🤖 Generated with Claude Code