[GH-ISSUE #861] Add get_channel_type method #526

Open
opened 2026-02-27 23:01:17 +03:00 by kerem · 6 comments
Owner

Originally created by @mayty on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/861

Is your feature request related to a problem? Please describe.
I have a workflow that goes like this:

  1. Get channelId from YouTube handle using v3/channels YouTube data api
  2. Scrape this channelId using ytmusicapi

The issue happens on step 2, as channelId produced in the first step can lead to channels of different types, which need to be scraped using different methods:

  • @RammsteinOfficial -> UCYp3rk70ACGXQ4gFAiMr1SQ -> YTMusic.get_artist()
  • @4tunenocopyrightmusic881 -> UC44hbeRoCZVVMVg5z0FfIww -> YTMusic.get_user()
  • @LinusTechTips -> UCXuqSBlHAE6Xw-yeJA0Tunw -> YTMusic.get_channel()

Describe the solution you'd like
A method to determine channel type:
YTMusic.get_channel_type(channelId: str) -> ChannelType

Describe alternatives you've considered
If for determining channel type the same request is required as for channel scraping, scraping result can be returned instead of type only:
YTMusic.get_generic_channel(channelId: str) -> tuple[ChannelType, GetArtistResponse | GetUserResponse | GetChannelResponse]

Originally created by @mayty on GitHub (Jan 28, 2026). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/861 **Is your feature request related to a problem? Please describe.** I have a workflow that goes like this: 1. Get `channelId` from YouTube handle using `v3/channels` YouTube data api 2. Scrape this `channelId` using `ytmusicapi` The issue happens on step 2, as `channelId` produced in the first step can lead to channels of different types, which need to be scraped using different methods: - `@RammsteinOfficial` -> `UCYp3rk70ACGXQ4gFAiMr1SQ` -> `YTMusic.get_artist()` - `@4tunenocopyrightmusic881` -> `UC44hbeRoCZVVMVg5z0FfIww` -> `YTMusic.get_user()` - `@LinusTechTips` -> `UCXuqSBlHAE6Xw-yeJA0Tunw` -> `YTMusic.get_channel()` **Describe the solution you'd like** A method to determine channel type: `YTMusic.get_channel_type(channelId: str) -> ChannelType` **Describe alternatives you've considered** If for determining channel type the same request is required as for channel scraping, scraping result can be returned instead of type only: `YTMusic.get_generic_channel(channelId: str) -> tuple[ChannelType, GetArtistResponse | GetUserResponse | GetChannelResponse]`
Author
Owner

@sigma67 commented on GitHub (Jan 29, 2026):

Sure, any suggestion how to achieve it other than trial and error? Because that can be done by the user easily right now.

<!-- gh-comment-id:3817256822 --> @sigma67 commented on GitHub (Jan 29, 2026): Sure, any suggestion how to achieve it other than trial and error? Because that can be done by the user easily right now.
Author
Owner

@mayty commented on GitHub (Jan 29, 2026):

From what I can see, it can go like this (based on the html I see in my browser):

flowchart TD
    A[Request Page] --> B{Div class inside header}
    B -->|"`ytmusic-immersive-header-renderer`"| C[Artist]
    B -->|ytmusic-visual-header-renderer| D{"Has `ytmusic-menu-renderer` at the same level as `ytmusic-subscribe-button-renderer`"}
    D -->|Yes| E[User]
    D -->|No| F[Channel]

that can be done by the user easily right now

While it can be done on the user side, implementing it this way seems pretty sketchy and requires multiple network calls:

def guess_account_type(channel_id: str) -> str:
    try:
        client.get_artist(channel_id)
        return 'artist'
    except KeyError:
        pass
    channel_response = client.get_channel(channel_id)
    return 'podcast' if 'episodes' in channel_response else 'channel'
<!-- gh-comment-id:3817854279 --> @mayty commented on GitHub (Jan 29, 2026): From what I can see, it can go like this (based on the html I see in my browser): ```mermaid flowchart TD A[Request Page] --> B{Div class inside header} B -->|"`ytmusic-immersive-header-renderer`"| C[Artist] B -->|ytmusic-visual-header-renderer| D{"Has `ytmusic-menu-renderer` at the same level as `ytmusic-subscribe-button-renderer`"} D -->|Yes| E[User] D -->|No| F[Channel] ``` --- > that can be done by the user easily right now While it can be done on the user side, implementing it this way seems pretty sketchy and requires multiple network calls: ```py def guess_account_type(channel_id: str) -> str: try: client.get_artist(channel_id) return 'artist' except KeyError: pass channel_response = client.get_channel(channel_id) return 'podcast' if 'episodes' in channel_response else 'channel' ```
Author
Owner

@sigma67 commented on GitHub (Jan 31, 2026):

Right, the guess_account_type is obviously not an option.

Just to make it clear, this library doesn't operate on the HTML page. It uses the JSON API that YouTube Music is built on.

<!-- gh-comment-id:3828049898 --> @sigma67 commented on GitHub (Jan 31, 2026): Right, the `guess_account_type` is obviously not an option. Just to make it clear, this library doesn't operate on the HTML page. It uses the JSON API that YouTube Music is built on.
Author
Owner

@sigma67 commented on GitHub (Jan 31, 2026):

They all use the /browse endpoint, so if you can figure out a surefire way based on the JSON response to tell which of the three types it is, feel free to submit a PR.

Please use an enum for the return value. I do wonder if it might not be more convenient to simply return the correct response after determining the type of the account (because that's what the user would most likely do anyway?)

<!-- gh-comment-id:3828063033 --> @sigma67 commented on GitHub (Jan 31, 2026): They all use the `/browse` endpoint, so if you can figure out a surefire way based on the JSON response to tell which of the three types it is, feel free to submit a PR. Please use an enum for the return value. I do wonder if it might not be more convenient to simply return the correct response after determining the type of the account (because that's what the user would most likely do anyway?)
Author
Owner

@Daveson217 commented on GitHub (Feb 1, 2026):

@mayty, what are possible value/options for proposed ChannelType other than artist? Is there a classification somewhere?

<!-- gh-comment-id:3830264490 --> @Daveson217 commented on GitHub (Feb 1, 2026): @mayty, what are possible value/options for proposed _**ChannelType**_ other than _artist_? Is there a classification somewhere?
Author
Owner

@mayty commented on GitHub (Feb 1, 2026):

@mayty, what are possible value/options for proposed ChannelType other than artist? Is there a classification somewhere?

@Daveson217 artist, user, and channel, corresponding to get_artist, get_user, and get_channel methods. In my PR I called enum ProfileTypes, so there is no weird ambiguity of channel type "channel"

<!-- gh-comment-id:3832143007 --> @mayty commented on GitHub (Feb 1, 2026): > [@mayty](https://github.com/mayty), what are possible value/options for proposed _**ChannelType**_ other than _artist_? Is there a classification somewhere? @Daveson217 *artist*, *user*, and *channel*, corresponding to `get_artist`, `get_user`, and `get_channel` methods. In my PR I called enum `ProfileTypes`, so there is no weird ambiguity of channel type "channel"
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ytmusicapi#526
No description provided.