Who here has a Youtube-DL compile for WinXP?

[nicolaasjan]

5 hours ago, autodidact said:

@nicolaasjan

I have attempted to make compatible 64-bit OpenSSL shared libraries using MSYS2.  If you would like to test them.

It works. 

[debug] Command-line config: ['-v']
[debug] User config "C:\Users\Nico\AppData\Roaming\yt-dlp\config.txt": ['--rm-cache-dir', '--console-title', '--js-runtimes', 'node', '-o', '~/Desktop/%(title)s.%(ext)s', '-S', 'res:1080,vcodec:vp9,acodec:opus', '--embed-thumbnail', '--add-metadata', '--convert-thumbnails', 'jpg', '--ppa', 'ffmpeg:-metadata synopsis=""', '--force-ipv4', '-N', '6', '--sponsorblock-remove', 'all']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out cp1252 (No VT), error cp1252 (No VT), screen cp1252 (No VT)
[debug] yt-dlp version nicolaasjan/yt-dlp@2026.01.09.064524 (win7_exe*)
[debug] Python 3.14.2 (CPython AMD64 64bit) - Windows-7-6.1.7601-SP1 (OpenSSL 3.6.0 1 Oct 2025)
[debug] exe versions: ffmpeg N-122272-g224b3ff82a-WIN7 (fdk,setts), ffprobe N-122272-g224b3ff82a-WIN7, phantomjs 2.5.0
[debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.01.04, curl_cffi-0.13.0, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.6.3, websockets-16.0, yt_dlp_ejs-0.3.2
[debug] JS runtimes: node-20.19.2
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets, curl_cffi
[debug] Plugin directories: C:\Users\Nico\AppData\Roaming\yt-dlp\plugins\bgutil-ytdlp-pot-provider\yt_dlp_plugins
[debug] Loaded 1853 extractors
Removing cache dir C:\Users\Nico/.cache\yt-dlp ..

yt-dlp_win7.7z

Edited January 13 by nicolaasjan

[nicolaasjan]

My yt-dlp branch now shows:

Quote

This branch is 1 commit behind yt-dlp/yt-dlp:master.

But this change is already applied in my own builds before the patch was officially merged. 

[johk]

As I don't think that it is fair to report this to yt-dlp, as I'm using your builds under Windows 7 (and the officials aren't valid for this), and so, just in case, the fault is in this build, I want to tell that your latest, this is 2026.01.19.143412, but not the previous, this is 2026.01.18.152406, there is a problem with DNS resolving.

Instead request the OS to resolve an A DNS record (this is the IPv4 IP) for the host of the video www.youtube.com (after re-review is not the host of the video, it doesn't even reach that step, is www.youtube.com), requests a ?65? DNS record (question mark, 6, 5, question mark), that is absolutely invalid (there is no such record in the standard and so replies the Google DNS server).

I use my own DNS resolver (local resolver, I mean, not external) and so I can inspect what is going on with DNS requests and so I'm seen it and reporting it.

Where is the fault coming? I don't have the knowledge to tell. Just that in the 18th of January, it works OK.

Regards.

 

EDIT: just to add up, I double checked the hash and file download isn't corrupted.

 

EDIT2: now that I think about it... 65 matches to the decimal value of the character A (capital A)... Might be some sort of UTF or ASCII thing? DNS is pure ASCII (or maybe ANSI), so no clue what has been introduced this issue.

 

LAST EDIT: ok I wasted the time digging it, using wireshark in loopback mode, and 65 means code 41, which means EDNS.

Why on earth yt-dlp is now requesting an EDNS record for www.youtube.com :-?

Edited yesterday at 06:50 PM by johk

[nicolaasjan]

2 hours ago, johk said:

I want to tell that your latest, this is 2026.01.19.143412, but not the previous, this is 2026.01.18.152406, there is a problem with DNS resolving.

I have little to no understanding of networking, so I'm afraid I can´t help you with this particular issue. 

I just tested a random video from YouTube in my Windows 7 VM and all went fine.

Edited 23 hours ago by nicolaasjan

[nicolaasjan]

What is the output of :

nslookup -querytype=TYPE65 www.youtube.com

(this checks if your local resolver/OS handles Type 65 queries correctly outside of yt-dlp)

And what is the output of a --verbose log?

Edited 23 hours ago by nicolaasjan

[nicolaasjan]

It could be, that the issue has arisen because I updated to the module curl_cffi 0.14.0. 

What happens when you add the `--force-ipv4` flag to your yt-dlp command?

[johk]

It is actually the curl stage, as it is what it fails when can't  do an OPT DNS query type 41 hex (65 is the decimal conversion)).

No, my DNS server/resolver software doesn't support it. I should have told, but I got tired of test, renames, edits... oh dear...

I know the software is old, but trusted, but, also, there shouldn't be need to hardcode EDNS queries on curl. Too paranoid, in my opinion.

I tested with the "--force-ipv4" and it is the same.

If the curl update is really necessary... I'll have to change the software, but it is really dumb reason :/

It works if I redirect queries to an external resolver (example: 1.1.1.1)... but defeats the purpose of using a local one in first place

Do you know what is really curious? That I almost always perform formats queries first, and it does this without a problem (querying correctly an A record for www.youtube.com), but when queries it again (or direct download, without query formats first) for download...  In other words, it happens at download time

Quote

[info] Writing video subtitles to: x:\I_support_NYC_Mayor_Mamdani_s_executive_order_11_-_here_s_what
_I_hope_it_focuses_on Louis_Rossmann 20260118 ZCaOuftYMMg 256x144 19-58 avc1.4d400c.en-orig.srt
[debug] Invoking http downloader on "https://www.youtube.com/api/timedtext?v=ZCaOuftYMMg&ei=4_tvaafa
Lt2IvdIPocaX0A8&caps=asr&opi=112496729&xoaf=4&xowf=1&xospf=1&hl=en&ip=0.0.0.0&ipbits=0&expire=176897
1859&sparams=ip%2Cipbits%2Cexpire%2Cv%2Cei%2Ccaps%2Copi%2Cxoaf&signature=D76B73CBED247243809B00D393F
A81C25F3A7B.47AC922C966E90FC4576A9BE345A85EAECABE737&key=yt8&kind=asr&lang=en&fmt=srt"
[download] Got error: Failed to perform, curl: (28) Resolving timed out after 20004 milliseconds. Se
e https://curl.se/libcurl/c/libcurl-errors.html first for more details.. Retrying (1/10)...
[download] Got error: Failed to perform, curl: (28) Resolving timed out after 20010 milliseconds. Se
e https://curl.se/libcurl/c/libcurl-errors.html first for more details.. Retrying (2/10)...
[download] Got error: Failed to perform, curl: (28) Resolving timed out after 20007 milliseconds. Se
e https://curl.se/libcurl/c/libcurl-errors.html first for more details.. Retrying (3/10)...
[download] Got error: Failed to perform, curl: (28) Resolving timed out after 20007 milliseconds. Se
e https://curl.se/libcurl/c/libcurl-errors.html first for more details.. Retrying (4/10)...

In the version of curl I have I don't have such an EDNS option to test.

Quote

curl 8.10.0 (x86_64-w64-mingw32) libcurl/8.10.0 LibreSSL/3.9.2 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 Wi
nIDN libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.63.0 ngtcp2/1.7.0 nghttp3/1.5.0
Release-Date: 2024-09-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 po
p3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli CAcert HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile l
ibz NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd

Edited 21 hours ago by johk

[VistaLover]

@johk

What happens if you switch to the 32-bit yt-dlp variant for Win7 ? 

https://github.com/nicolaasjan/yt-dlp/releases/download/2026.01.19.143412/yt-dlp_x86_win7.exe

That one doesn't come with the curl_cffi Python module bundled (it's currently only 64-bit); some sites require this module to work, but NOT youtube.com (yet) ...

1 hour ago, johk said:

In the version of curl I have I don't have such an EDNS option to test

curl_cffi is a Python binding (wrapper) for curl-impersonate, not for "ordinary" curl ; curl-impersonate uses Google's BoringSSL crypto lib (not Libre/OpenSSL), making it incompatible with < Win7  (I have Vista) ...

curl 8.15.0-IMPERSONATE (Windows) 

libcurl/8.15.0-IMPERSONATE 
BoringSSL 
zlib/1.3
brotli/1.1.0 
zstd/1.5.6 
c-ares/1.30.0 
WinIDN 
nghttp2/1.63.0 
ngtcp2/1.11.0 
nghttp3/1.9.0

Release-Date: [unreleased]

Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli ECH HSTS HTTP2 HTTP3 HTTPS-proxy HTTPSRR IDN IPv6 Largefile libz NTLM SSL SSLS-EXPORT threadsafe Unicode UnixSockets zstd

[johk]

1 hour ago, VistaLover said:

What happens if you switch to the 32-bit yt-dlp variant for Win7 ? 

https://github.com/nicolaasjan/yt-dlp/releases/download/2026.01.19.143412/yt-dlp_x86_win7.exe

That's it!!!

Oh lord , what a waste of day doing tests back and forth, searching for alternatives, finding BIND9 stopped support for Windows on 9.17.14.... Anything, but not with the x86 build...

I'll end with a correction to myself.

I should have said that EDNS is not for security only. I always mix it with DNSSEC (which actually is a feature of the upstream curl utility), despite this requires EDNS, too.But, anyway, there is no need for such implementation, IMHO.

Edited 18 hours ago by johk

[nicolaasjan]

I don't think there will be many users of the 64-bit version that also have an old local DNS resolver, but nevertheless I will downgrade curl_cffi to version 0.13.0 for the next release.
Forcing these modern DNS extensions on a legacy-OS target is counter-productive anyway.

Meanwhile, here is a 64-bit test version, so we can see if curl_cffi 0.13.0 doesn't give issues for you with 2026.01.19.143412.

[johk]

It works now.

But let me say one thing.

While it is legit to complain as I did, and also helps to know what is the issue and see if I can fix, or can be fixed, if it is necessary to use the latest curl_cffi, just do it.

Don't downgrade because a person complains. If I can use the x86, awesome, I'll use. In cases as with this tool, how many times are we dealing with over 2³² of data/memory needs to use the x64. It is more a matter of slightly better performance.

 

off-topic from here

Now, about the "modern DNS extensions". Actually they aren't modern... I mean, the original proposed standard RFC is from 1999, and then ratified as internet standard on 2013.

It is fair to use it, but, why now?

If I could I would update the hardware, OS, software, but... I don't live in a world of magic.

[VistaLover]

Best greetings @nicolaasjan  ; may I bring to your attention the "youtube IOS-client M3U8 formats" discussion found in GH#15569: 

https://github.com/yt-dlp/yt-dlp/issues/15569#issuecomment-3770540275

https://github.com/yt-dlp/yt-dlp/issues/15569#issuecomment-3771419465

https://github.com/yt-dlp/yt-dlp/issues/15569#issuecomment-3780166034

@bashonly, one of the main, current, yt-dlp devs, is being childishly stubborn  at not acknowledging (repeated) claims that the IOS-client M3U8 formats are (currently) actually downloadable without 1) YT cookies, 2) a JS runtime enabled, 3) a PO Token.

Could you, please, add there your own input (hopefully one that corroborates the "downloadable" claims)  before that issue gets locked for non-devs?

Many thanks in advance  ...

All the best for you!

[nicolaasjan]

1 hour ago, johk said:

Now, about the "modern DNS extensions". Actually they aren't modern... I mean, the original proposed standard RFC is from 1999, and then ratified as internet standard on 2013.

It is fair to use it, but, why now?

That's right.

But what's new is that libcurl (and thus curl_cffi 0.14.0) have now started to enforce these extensions (no idea why).

Since 0.14.0 doesn't offer any critical features that we can't live without on Windows 7, I will pin my version on 0.13.0 for as long as possible. At the moment there are no security issues with that version.

It's an uphill battle with yt-dlp always wanting the latest and "greatest".

Edited 10 minutes ago by nicolaasjan

[nicolaasjan]

54 minutes ago, VistaLover said:

Could you, please, add there your own input (hopefully one that corroborates the "downloadable" claims)  before that issue gets locked for non-devs?

Many thanks in advance  ...

Done.