Podcasts on YouTube Music or the main app: a placement rule for every subscription
You subscribe once, and the trouble starts there. A single channel can publish music uploads, podcast episodes, and ordinary videos, and YouTube reads that one subscription from two apps. YouTube Music surfaces part of the channel's output, the main app surfaces the rest, and your library splits along lines you never chose.
This post maps how subscriptions, podcasts on YouTube Music, uploads, background play, and offline listening behave in each app, then gives one placement rule per content type so playback lands in the right place. The second half of the answer is a curation layer that keeps the library itself unified, so it stops splitting every time you add a subscription.
How subscriptions actually behave
Most YouTube Music vs YouTube app comparisons turn into feature checklists. The structural fact matters more: a YouTube subscription attaches to a channel, not to a content type. One subscribe action creates one relationship, and in practice both apps read it. A channel's music uploads, podcast episodes, and videos arrive together because that is how the channel publishes them.
Neither app cleanly owns a channel. Choosing an app is really choosing where to read a feed that both apps only partially interpret: YouTube Music filters it through a music lens, the main app through a video lens. Music subscriptions on YouTube never stay contained to a single app for exactly this reason. The subscription follows the channel, and the channel carries everything.
Podcasts on YouTube Music: feeds that refuse to sit still
Podcast handling is the messiest corner of the split. Podcasts on YouTube Music arrive through channel feeds that were built for music and video, not through dedicated podcast subscriptions. A channel that publishes interviews alongside music uploads and regular videos delivers its episodes mixed into the same upload stream. There is no per-content-type subscription, only per-channel, so the episode you wanted arrives attached to everything else the channel makes.
Podcast listening tends to happen with the screen off, which pulls episodes toward the app built around audio.
That ambiguity collides with how people actually listen. Podcast listening tends to be screen-off listening, which pulls toward the app built around audio. The placement rule below still puts podcasts in the main app, because episode-style and video-first content plays best there, but the pull toward YouTube Music never fully resolves. Listeners who use YouTube as their podcast player need a way to separate interviews from music from research on their own terms; turning your subscriptions into a podcast-style audio feed covers one approach in depth.
Uploads, background play, and offline listening: the audio-first checklist
Each consumption habit pushes a content type toward one app or the other. The placement rule maps music to YouTube Music and podcasts and uploads to the main app. Background play and offline listening act as the tiebreakers when a channel could plausibly live in either place.
Background play is the tiebreaker: audio you play while doing something else belongs to the app built around sound.
- Music you play while doing something else: audio-first consumption points toward the app built around sound.
- Upload-heavy channels: live sets, mixes, and video-first music content pull back toward the main app, where the video experience lives.
- Mixed channels: split habits produce split libraries. The same channel can end up half music library, half watch later.
Offline listening follows the same logic. Content you keep for commutes or travel behaves like music and drifts toward YouTube Music, while one-off uploads you watch once and discard belong in the main app.
The principle behind the checklist is simple. Match each content type to the playback mode you actually use, not to the app you happened to open first.
Why channel-based subscriptions always leak
The deeper cause sits underneath both apps. Subscribing follows the channel, and every content type rides along whether you wanted it or not. A single channel can carry podcasts, music uploads, and regular videos in one feed, and no app lets you subscribe to just one slice of it.
Sort by app, then, and a remainder always appears. Music goes here, podcasts go there, and everything else, the research channels, the recipe channels, the tutorials, lands in permanent ambiguity. This is a taxonomy problem as much as a product problem. You do not need a better division of labor between two apps; you need a grouping layer that sits above both of them and treats a channel as belonging to a theme you define.
The placement rule: which app should own each content type
Content type | Play it in | Why |
|---|---|---|
Music | YouTube Music | Audio-first listening and music-first channels |
Podcasts and uploads | Main YouTube app | Episode-style and video-first content |
Everything else (research, recipes, interviews, tutorials) | Either, and neither | The ambiguous middle the two-app split cannot solve |
Two honest caveats. First, the rule optimizes playback, not library management. Your subscriptions still need a single home, because both apps read the same channel list. Second, following the rule perfectly still leaves your library split across two apps and one Google account. The rule tells you where to press play; it does not tell you where your subscriptions live. That is the second half of the answer.
One feed, two apps: local-first curation with Yougroup
Yougroup is an open-source Chrome extension, developed by Thoughtbubble, that adds the missing grouping layer. Its Lists let you group channels by theme: research, recipes, interviews, music. That is exactly the taxonomy the two-app split lacks, and it applies to every channel you subscribe to, regardless of which app ends up playing it.
On top of the Lists sits what the project describes as a "deduplicated, cross-list feed that consolidates uploads from every channel in every list into one clean view." A channel can belong to more than one list, so a consolidated view needs deduplication by design, and the feed becomes one place to read everything.
The extension "uses YouTube RSS feeds for public uploads with no YouTube Data API key required; API key is optional for richer details like duration and view counts." In other words, the feed works out of the box for public uploads, and richer metadata is opt-in. Yougroup is open-source and actively developed, not an abandoned experiment.
Queue control and watched state that stays local
Day to day, you manage the unified library by building playback queues. Sort a queue by newest, popular, or interleaved to match how you consume each list: newest for a research list you want current, popular for a backlog of long interviews, interleaved when several themes compete for attention. Marking an upload watched is a local action, with no server-side history and no account required, and queues open directly on YouTube, so the curation layer never replaces the playback experience you already prefer.
Watched state and curation data live entirely in Chrome extension storage. You get full consumption tracking without creating a second silo of account data. Once your channels sit in Lists, pruning the library each season becomes a matter of reviewing a theme rather than scrolling an undifferentiated subscription column.
Google-account sync vs Chrome-storage-only curation
The data models differ as much as the features. Both YouTube apps run on Google accounts and server-side history and sync, so your subscriptions and watched state live on Google's side of the fence. That centralization is worth remembering when you consider backing up your subscriptions before anything changes on the account.
Yougroup takes the opposite position: no Yougroup account, no hosted backend, no server-side sync, and no product analytics. All data stays in Chrome extension storage. For developers and privacy-minded readers, the open-source route goes further: clone the repository, build it, and load the unpacked extension in Chrome 114 or later, with full transparency into what the code does. The self-host mindset keeps playback in whichever YouTube app fits the content while you own the curation layer yourself. The curation layer is neutral infrastructure, not another account to manage.
The final rule: right app for playback, one local tool for the library
Music goes to YouTube Music. Podcasts and uploads go to the main app. Playback follows the media, and background play and offline habits break the ties.
Library management belongs to one neutral layer: curated Lists plus a deduplicated, cross-list feed covering every channel in every list. Because that layer is local-first, there is no new account, no sync silo, and no analytics, just Chrome extension storage.
If the split library has been bothering you, try Yougroup. It is open-source, runs in Chrome 114 or later, and comes from Thoughtbubble, and it stops the subscription library from splitting across apps every time you subscribe to a channel that publishes a bit of everything.