Fix Tidal 404 handling: share links, missing lyrics, and the crashing handler

[sjbrownrigg]

The problem

Pasting a link straight from Tidal's share sheet crashes:

$ rip url https://tidal.com/album/152697662/u
...
  File "/usr/lib/python3.12/logging/__init__.py", line 392, in getMessage
    msg = msg % self.args
TypeError: not all arguments converted during string formatting

Two separate bugs stack up here, and together they make the failure very hard to diagnose — the traceback points at logging, and says nothing about the URL.

1. The /u suffix is parsed as the item id

Tidal's share sheet appends /u. URL_REGEX takes the last path segment as the item id, which it has to do because Qobuz album urls look like /<locale>/album/<slug>/<id>. So the suffix wins:

>>> URL_REGEX.match("https://tidal.com/album/152697662/u").groups()
('tidal', 'album', 'u')
>>> URL_REGEX.match("https://tidal.com/album/152697662").groups()
('tidal', 'album', '152697662')

streamrip then requests album u, which 404s.

2. The 404 handler crashes instead of reporting

if resp.status == 404:
    logger.warning("TIDAL: track not found", resp)
    raise NonStreamableError("TIDAL: Track not found")

The message has no format placeholder but an argument is passed, so msg % args raises TypeError as soon as the record is formatted — before the NonStreamableError on the next line is ever reached. Any 404 from the Tidal API surfaces as a logging traceback rather than the intended error. This has been present since b01382f (#623).

3. A track with no lyrics is dropped entirely

get_metadata() fetches lyrics for tracks. The lyrics endpoint 404s for any track nobody has written lyrics for, and _api_request turns that into NonStreamableError — but the lyrics fetch only caught TypeError, so the error escaped get_metadata().

PendingTrack.resolve() reasonably treats a NonStreamableError from get_metadata() as "this track cannot be streamed", so the track was skipped. A track was dropped from an album download purely because it had no lyrics:

WARNING  TIDAL: item not found (404): .../tracks/152697671/lyrics
ERROR    Track 152697671 not available for stream on tidal

On a 12-track album this silently cost 4 tracks.

Note on prior art: #911 by @scratchmex reported and fixed the /u issue first, back in November 2025, and was confirmed by @CharliePalm. Credit for spotting it goes there. I've implemented it differently only because url.rstrip("/u") strips characters, not the suffix — https://tidal.com/album/1u/u becomes .../album/1, and .../track/uuu/u becomes .../track. Tidal ids are numeric in practice so it rarely bites, but the anchored regex avoids it. Happy to close this in favour of #911 with that one line adjusted, if the maintainers prefer — the other two fixes here are independent and can be split out.

What this changes

• Fix crash when Tidal returns 404 — add the missing placeholder and log resp.url, which is the useful part. A 404 now reports NonStreamableError as intended.
• Fix Tidal share links ending in /u — strip the suffix from tidal.com urls before matching. Scoped to tidal.com, so Qobuz's /<locale>/album/<slug>/<id> form and Deezer urls are untouched.
• Don't drop Tidal tracks that have no lyrics — catch NonStreamableError alongside TypeError around the lyrics fetch. Lyrics are optional metadata and must not decide whether audio gets downloaded. Verified against the four tracks above: all four now resolve.

Testing

Added test_tidal_share_url_with_u_suffix, covering /u, /u/ and /browse/.../u. It fails on dev (3 subtest failures) and passes with the fix.

Verified the existing forms still parse to the same ids: tidal.com/browse/track/..., listen.tidal.com/track/..., qobuz.com/fr-fr/album/<slug>/<id>, qobuz.com/us-en/album/name/id123456, deezer.com/en/track/....

pytest tests/ gives 60 passed, 7 skipped, and 1 failure in test_meta.py::test_album_metadata_qobuz (a genre assertion) which also fails unmodified on dev, so it is unrelated to this change.