[ie/crunchyroll] Make additional audio languages available

[Hattshire]

Description of your pull request and other information

Fetch additional audio languages for crunchyroll streams if available.

Template

Before submitting a pull request make sure you have:

• At least skimmed through contributing guidelines including yt-dlp coding conventions
• Searched the bugtracker for similar pull requests
• Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check all of the following options that apply:

• I am the original author of this code and I am willing to release it under Unlicense
• I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

• Fix or improvement to an extractor (Make sure to add/update tests)
• New extractor (Piracy websites will not be accepted)
• Core bug fix/improvement
• New feature (It is strongly recommended to open an issue first)

[pukkandan]

@Grub4K - you are maintaining this IE, correct?

[rdamas]

I'm curious: what is the use case for querying the information for up to eight or even more languages a video is available for, when I'm most probably only interested in exactly the video I've selected? Each query is another network request...

[Jules-A]

I'm curious: what is the use case for querying the information for up to eight or even more languages a video is available for, when I'm most probably only interested in exactly the video I've selected? Each query is another network request...

I'm not quite sure what this PR is trying to accomplish but the current default is disgustingly slow with the amount of requests it makes so I'm using a closed PR from ProDev2 that added language selection so it only requests the language I specify (https://github.com/Jules-A/yt-dlp/tree/cr-langs if you want to try it). Grub4K seems obsessed on keeping such stuff to a useless plugin that no-one will end up using so don't know if language selection will ever officially return.

[Hattshire]

I'm curious: what is the use case for querying the information for up to eight or even more languages a video is available for, when I'm most probably only interested in exactly the video I've selected?

The link that gets copied from the web app is the one with Japanese audio, and there was no option to change the audio.

Each query is another network request...

I can rewrite it as an extractor argument like the hardsub option, I felt that offering more options available for the Format List was more natural from a user in search of a dub perspective.
But it makes sense reducing the request count.

[rdamas]

The link that gets copied from the web app is the one with Japanese audio, and there was no option to change the audio.

Hmm. Not for me.

• The link from the calendar is always for a video with the language I choose.
• In the player you can change language, it'll redirect to the link for the chosen language.
• Crunchyroll save this language setting for this show for your next visit.

But that's probably offtopic here.

[Grub4K]

The link that gets copied from the web app is the one with Japanese audio, and there was no option to change the audio.

Hmm. Not for me.

Same story here:

$ yt-dlp --login --print language https://www.crunchyroll.com/watch/GK9U3KPKW
ja-JP
$ yt-dlp --login --print language https://www.crunchyroll.com/watch/G0DUNKEKJ
en-US

But that's probably offtopic here.

No, this is a valid concern, and exactly the reason why I did not want to implement this before, since doing so will either break the download archive or, like in this case, playlist filtering. It's a lose-lose in that case.

Problem: I think there were cases where passing different urls (the changed one after language change) would turn out the same language version. If someone can provide an example where it doesnt work as expected, please show it here so we can re-evaluate.

The only way I can think off that will solve this while maintaining compatiblity is this:

• Replace the current id with the id for the media stream (so new ids are actually unique, since one url could now point to multiple languages)
• Provide the old id as _old_archive_ids (so existing archives don't break)
• Propagate language selection from playlist to individual url by using smuggle_url (so that playlist filtering and _RETURN_TYPE = 'video' are still valid)
• Create an extractor arg to allow multiple languages to be downloaded (default to downloading only the main selected language)
  • This has to be overridden by the smuggled selection from the playlist, otherwise filtering would break
    If anyone can reproduce the mismatch then above would have to be implemented.

---

Having said that, I am not completely opposed an extractor arg to force language, given that @pukkandan agrees that it is okay that the download archive breaks when providing an extractor arg. Alternatively, Grub4K@96b2919 can still be merged to reduce playlist queries without impacting compat

[pukkandan]

The only way I can think off that will solve this while maintaining compatiblity is this:

• Replace the current id with the id for the media stream (so new ids are actually unique, since one url could now point to multiple languages)

• Provide the old id as _old_archive_ids (so existing archives don't break)

• Propagate language selection from playlist to individual url by using smuggle_url (so that playlist filtering and _RETURN_TYPE = 'video' are still valid)

• Create an extractor arg to allow multiple languages to be downloaded (default to downloading only the main selected language)

  • This has to be overridden by the smuggled selection from the playlist, otherwise filtering would break
    If anyone can reproduce the mismatch then above would have to be implemented.

I believe this is the ideal solution and is similar to how I had implemented funimation before. Does this have any drawbacks except for complexity?

[Grub4K]

I believe this is the ideal solution and is similar to how I had implemented funimation before. Does this have any drawbacks except for complexity?

No, not as far as I can tell, however nobody took the time to properly implement it yet. Since I cannot reproduce, didn't get sent any reproduction cases (cough cough), it's a fair effort, AND will change the ids used I was hesitant to implement it myself