Fix download errors by using mostly VISIONOS agent

[mysteryx93]

Closes #902 #962 #964

The downloader has been broken for some time, and that's the kind of issues that are extremely time-consuming to diagnose.

I have put Grok Build to the task, so this is AI-generated, and I have manually reviewed every line modified. All tests are now passing. 2 were still failing: Live Stream and Upscaler, because of outdated videos. The code is fine. I updated the video IDs. All tests now pass. So far Grok passed every test I gave it; it just keeps going until the tests pass.

Summary of changes

The failure was not the video. YouTube’s current ANDROID_VR 1.60.19 client (what YoutubeExplode still used) now returns LOGIN_REQUIRED / “Sign in to confirm you’re not a bot” for public videos, including u9Dg-g7t2l4. That makes the main cipher-less path fail, then the #902 cipher fallback also fails because player JS is no longer parseable.

yt-dlp already moved off that client. Its JS-less default is now VISIONOS, which still returns progressive URLs without a PO token.

What changed

1. Primary client: VISIONOS 1.02 — same client yt-dlp uses without Deno. No signature deciphering, and stream URLs actually work (HEAD 200).
2. Fallback: ANDROID 21.26.364 — for “made for kids” videos, which VISIONOS still cannot play. ANDROID still returns muxed itag 18.
3. SABR streams are skipped instead of aborting the whole manifest (Failed to extract the stream URL).

Still broken (unchanged YouTube limits)
• Age-restricted videos still need the cipher client. Player JS is still unparseable.

[mysteryx93]

To clarify: the agent fallback works for age-restricted.
Kids videos still fail. These are 2 separate cases.

[mysteryx93]

Do you want me to edit the PR or you handle it from here?

[Tyrrrz]

@mysteryx93 yes, please fix as much as you can youself, I'll clean up afterward

[mysteryx93]

I submitted the refactoring changes. It does considerably improve the code.

2 potentially major issues to look at before deploying.

The TVHTML5 code route is not being used at all; I tried all the unit tests and none hit that route. The new pathway was designed to handle the ForKids issue as well, making this one obsolete.

// The only client that can handle age-restricted videos without authentication is the
// TVHTML5_SIMPLY_EMBEDDED_PLAYER client.
// This client does require signature deciphering, so we only use it as a fallback.

Furthermore, looking at where it is called: StreamClient.GetStreamInfosAsync. We now have 2 separate places to handle fallback logic, which is definitely not ideal.

The whole "Retry with deciphering" fallback could perhaps be removed... but perhaps it would serve in the future too, so it's not an easy call.

[mysteryx93]

btw I made some comment about HttpRequestMessage; never mind you're using HttpClient, everything is fine there.

[Tyrrrz]

The TVHTML5 code route is not being used at all; I tried all the unit tests and none hit that route. The new pathway was designed to handle the ForKids issue as well, making this one obsolete.

// The only client that can handle age-restricted videos without authentication is the
// TVHTML5_SIMPLY_EMBEDDED_PLAYER client.
// This client does require signature deciphering, so we only use it as a fallback.

Furthermore, looking at where it is called: StreamClient.GetStreamInfosAsync. We now have 2 separate places to handle fallback logic, which is definitely not ideal.

The whole "Retry with deciphering" fallback could perhaps be removed... but perhaps it would serve in the future too, so it's not an easy call.

@mysteryx93 the TVHTML5 route was used for age-restricted videos, usually marked as such because of violence and/or sexual themes. So it's a separate issue.

[mysteryx93]

ah and those 2 tests are set as "Skip" so they weren't run. Those tests fail with "Failed to extract the cipher manifest"; which I suppose is why you disabled the tests. But they work in practice?

Still. We have the retry logic split into 2 areas. It's not ideal but not really an issue either. Considering the 2nd retry path with cipher is a considerably more different/complicated route.

[Tyrrrz]

Thanks!

[mysteryx93]

@Tyrrrz what's your thoughts about using an extra dependency to support cookies and YouTube Premium streams, with the same method yt-dlp is using?

Do you plan to take care of that eventually? Do you want to keep it fully dependency-free?

Or would you like me to generate the bulk with AI then we refactor it proper, copying yt-dlp's proven path? BUT keeping the dependency fully optional.

As of right now, it seems the cookie-authentication path is useless without proper deciphering support, which can only be done with a real JavaScript engine.