All default lyric providers are currently broken — add a keyless provider (LRCLib) to the defaults

All default lyric providers are currently broken — add a keyless provider (LRCLib) to the defaults

Summary

lyrics_providers ships with ["genius", "azlyrics", "musixmatch"]. Right now, from my network, all three fail at runtime:

• Genius: the bundled shared token is rate-limited, first request returns HTTP 429.
• AZLyrics: serves an anti-bot "request for access" interstitial (flagged IP ranges); no usable content comes back.
• MusixMatch: /search/ answers with HTTP 403 (TLS fingerprinting).

The fallback chain means a user just sees "downloaded without lyrics" — but the root cause is that every default provider is down, not one.

Meanwhile, free, working, keyless lyric sources exist and are already used by the wider ecosystem (beets, lrcget, LRCGET, Koel etc. talk to LRCLib every day). This issue argues that spotDL should ship a keyless provider as part of the defaults so lyrics embed out of the box again.

Evidence (empirical, from the machine that also reproduced #2572 end-to-end)

I confirmed each provider's behaviour with real requests, then wired up a Lrclib provider (lrclib.net, no auth) and verified it end to end:

• Downloaded a 20-track album with --lyrics lrclib: all 20 files came out with the lyrics embedded (USLT tag), readable in any player, and they match the lyrics the song's page shows (cross-checked a sample against the public song pages).
• lrclib.net/api/search?artist_name=...&track_name=... returns real lyrics (plain + synced LRC) with a duration match, no token, no browser tricks, no TLS fingerprints.
• Same machine, --lyrics genius → 429; --lyrics azlyrics → interstitial; --lyrics musixmatch → 403 on search.

Proposed change

Add a keyless lrclib provider (already drafted) and include it in the default list:

"lyrics_providers": ["lrclib", "genius", "azlyrics", "musixmatch"],

genius/azlyrics/musixmatch stay as fallbacks for the cases LRCLib misses (and it's an additive, non-breaking default change).

Why LRCLib, not another route

• It's a public JSON API — no scraping, no cookies, no UA tricks, no x_code. That removes a whole class of bot-detection breakage the current providers keep hitting.
• It powers the synced path already used by spotDL users (syncedlyrics/lrc sources), but as a first-class plain-lyrics provider it also fixes unsynced embedding (the actual #2572 complaint).
• It works from any network — the failures above are at least partly IP/geo dependent, which is why they don't reproduce for everyone and slip through.

I'm aware of the project's stance in #2302 (adding the synced provider instead); this is complementary: Lrclib covers the plain-lyrics case those sources also fall back to, with fewer moving parts.

Related

• #2572 (lyrics not embedded — this fixes the out-of-box experience)
• #2668 (Genius failing)
• #2741 (MusixMatch 403)
• PR #2770 (AZLyrics hardening, already open)

References

LRCLib API: https://lrclib.net/docs