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 1 hour ago 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 14 minutes 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 1 hour 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?