YouTube Music as a playlist / library import source (mirroring the Spotify import)

[angusmaul]

Floating this as an idea before anyone sinks time into it, to gauge appetite.

The idea

Expose YouTube Music as an input (discovery/import) source, the way the existing Spotify playlist import works — i.e. read a user's own YT Music liked songs, subscribed/library artists, and personal playlists, match to MusicBrainz, and feed the results into Lidarr's normal search/download pipeline.

Why here rather than Lidarr core

Lidarr declined this natively (Lidarr#5745, closed not_planned), so a plugin is the natural home. And there's currently no YouTube-Music-account import anywhere in the *arr ecosystem — Lidify is library-based recommendations, and the only YTM path today is a manual Google Takeout → custom-import-list script.

Why Tubifarry specifically

• You've already solved playlist → MusicBrainz match → Lidarr for Spotify; this is the same pipeline with a different source.
• Tubifarry already embeds a YouTube Music API + auth/session path (used by SpotifyToYouTubeEnricher, e.g. [Bug] SpotifyToYouTubeEnricher Crash: ArgumentNullException in YouTubeMusicAPI (buttons[2] token null) #91), so the fragile bit — staying authenticated to YTM — may be largely reusable.

Possible staged scope

1. Authenticate to a user's YT Music account (browser headers / OAuth via the existing YTM client).
2. Pull liked songs, subscribed/library artists, and a given playlist.
3. Match tracks → artist/album against MusicBrainz (reuse the Spotify-import matcher).
4. Surface as a Lidarr import list (artist-level at minimum; album-level ideal).
5. Optional: periodic re-sync, adding only newly-matched items.

A v1 that only imports subscribed/library artists would deliver most of the value with almost no new matching code, since those are already artist-level (no track→album resolution needed) — feels like a low-risk first slice.

Questions for you

• Is this something you'd be open to in Tubifarry, or out of scope?
• If yes, how much of the Spotify-import + YTM-API plumbing is realistically reusable for the account-reading direction?
• Any known blockers on the YTM auth side you've already hit? (The enricher path suggests you've dealt with YTM session tokens before.)

Happy to help test on the YouTube Music side, and open to contributing if you can point me at the right seams (I'm not a .NET dev, so I'd need some guidance).

[TypNull]

Hi, thanks for the suggestion.

I'm not sure Tubifarry is the right place for this, because one of your premises isn't quite accurate:

Lidarr declined this natively (Lidarr#5745, closed not_planned), so a plugin is the natural home. And there's currently no YouTube-Music-account import anywhere in the *arr ecosystem

This isn't fully true. Lidarr actually has a PR for a YouTube import list. If you ask around, it might work. I haven't tested it myself, so I can't say for sure.

From my side: yes, I could implement YouTube, but it's a real up and down situation. Given the current state of maintenance on the YouTube Music package, I wouldn't want to base more code on top of it. Using the Google API seems possible and would probably be fine long term, but I have no experience with it and would need to look into it first.

On the Spotify angle: Spotify imports already work fine through Lidarr's native import list, right? So why go the workaround route over MusicBrainz? Or did Spotify cut Lidarr off? Either way, I won't be implementing Spotify. They changed their API and I don't agree with the new terms.

On the import list itself: that part is actually an easy task, so I don't fully understand what you're suggesting there. All import lists are pretty similar. The hard part is matching a YouTube ID to a MusicBrainz ID.

So the real dealbreaker is this: I don't currently trust the YouTube Music API package enough. It's already a hassle dealing with all the existing issues around it.

That said, the contributing guide should already explain how much of it works. Pull the repo, open it in Visual Studio, run the build twice, and run yarn for the Lidarr frontend. If you're willing to contribute, I'd be happy with that. I'm just concerned about the current YouTube Music package, but if you find another way around it, I'd be glad to see it.

[angusmaul]

Ah nice, thanks — and fair point, I completely missed Lidarr#5395. My "nothing exists" line was just wrong.

Dug into it a bit, and here's the catch that hits every option the same way: the official YouTube Data API v3 just doesn't expose the private YT Music library (liked songs, followed artists) — only videos/playlists/subscriptions. #5395 is built on the official API + an API key, so it's stuck on public playlists (and it's conflicted/stalled anyway). The only thing that actually sees the private library is ytmusicapi — browser-header auth, or a self-made Google Cloud "TV" OAuth client since Google killed the shared web OAuth last Nov. Which is exactly the package you don't want to pile more onto — totally get it.

So there's no non-fragile version to hand you, and it wouldn't really sit in Lidarr's C# core anyway. I'm just going to build a small standalone thing (Python + ytmusicapi) that matches to MusicBrainz and pushes into Lidarr over its API, keeping the flaky auth contained to that one app.

Anyway, makes sense Tubifarry isn't the spot for it. Appreciate you taking a proper look — if a durable auth route ever turns up I'll circle back. Leaving this here for the next person who searches.

[angusmaul]

Circling back as promised — I built the standalone app: Crossfadarr (Python + ytmusicapi + a Flask review UI; Docker image on GHCR). It reads your own YTM library (liked songs, library/subscribed artists), matches artists to MusicBrainz (alias/Unicode-aware, with per-artist confidence), and pushes approved artists to Lidarr over its API. Metadata only — it downloads nothing and touches no indexers.

You were right to be wary of the YTM package, and it's worth spelling out what I hit for anyone who searches this later:

• OAuth is currently a dead end. I built the device flow end-to-end and it mints a valid token (the official Data API accepts it), but YT Music's internal API rejects all OAuth bearer tokens with HTTP 400 — known upstream issue (400 Bad Request error when using oauth, but browser authentication works sigma67/ytmusicapi#676 / #682), no fix as of 1.12.1. The code ships in the app marked "rejected upstream" in case that changes.
• So v1.0 is browser-header (cookie) auth only, with the sharp edges documented: headers copied from an active browser session die in under an hour (cookie rotation); copying them from an incognito window you close without logging out avoids rotation and lasts weeks. Re-auth is manual, and the app surfaces auth failures with a direct link to the re-auth settings.

Containing the fragile auth in one small app — rather than basing more of Tubifarry on it — was the right call. Thanks for the steer, and for the pointer to Lidarr#5395 which clarified the official-API ceiling. If ytmusicapi's OAuth ever starts working again I'll wire it in and note it here.

[angusmaul]

Closing the loop on this one: Crossfadarr is now released — https://github.com/crossfadarr/crossfadarr (MIT, Docker image on GHCR).

@TypNull — thanks again for the direction here; it shaped the whole design and your skepticism about the YTM packages turned out to be exactly right. What we found building it:

• Cookie auth is as fragile as you said. Browser-header sessions can die within hours if the originating browser stays active (Google rotates live-session cookies). Copying headers from a private/incognito window that you then close extends that to weeks. The app treats re-auth as a first-class flow because of this.
• OAuth is a dead end right now, verified. We built the full device flow with a self-provisioned TV client — the token is valid (the official Data API accepts it) but YouTube Music's internal API rejects it with HTTP 400 on every endpoint. So there's currently no durable auth path for anyone, which validates keeping this out of Tubifarry/Lidarr core.
• You were right that matching is the real work. YTM→MusicBrainz needed alias- and Unicode-aware comparison (native-script artists like 澤野弘之), plus a zero-release-group check to catch bootleg/placeholder MB entities that would import as empty artists.

The standalone-app approach means all that fragility lives in one place, and Lidarr just receives clean MBID adds over its API. Happy for any of it to be useful as reference if you ever revisit a YouTube source.