Who here has a Youtube-DL compile for WinXP?

[johk]

This won't make you happy, but in my case is true that if I don't use quickjs, which I usually don't, the m3u8 formats are not listed, what I don't care much anyway, but that is what happens to me.

There is a difference in the video information retrieval, when not using the JS runtime, it downloads only the adroind JSON, but when using the JS runtime downloads the safari player JSON, the player Javascript and then downloads the m3u8.

But I don't know why this happens to me and not to you.

[youtube] kS-9ISzMhBM: Downloading android sdkless player API JSON
[youtube] kS-9ISzMhBM: Downloading web safari player API JSON
[youtube] kS-9ISzMhBM: Downloading player c1c87fb0-main
[youtube] [jsc:quickjs] Solving JS challenges using quickjs
[youtube] kS-9ISzMhBM: Downloading m3u8 information

 

Edited 7 hours ago by johk

[VistaLover]

@johk

What you describe is perfectly normal now ; when one a) doesn't pass YT logged-in cookies b) doesn't enable a JS runtime, then ONLY the android_sdkless (ANDR-S) formats are being available; these don't include any HLS (m3u8) formats (BTW, the ANDR-S client doesn't work at all with YT logged-in cookies).

OTOH, the web_safari (WEB-S) client formats (of the HLS type, only) were, up until a week ago, also accessible under the above scenario; but now, because Google  have put them behind an n/sig JS challenge, they do require a JS runtime (e.g. quickjs) to be enabled for them to become available to yt-dlp.

The IOS HLS formats are (at this time at least, can't vouch for how much longer ) accessible without a JS runtime, but they have to be explicitly requested with the 

--extractor-args "youtube:player_client=ios;formats=missing_pot"

argument; this will also yield the https IOS formats, which are inaccessible without also providing a PO Token  ...

Hope it's clear to you now  ...

[johk]

yes, clear as water, sorry.

As I go the default way, I was really missing something