Who here has a Youtube-DL compile for WinXP?

[gaouser]

On 3/27/2025 at 2:06 AM, user57 said:

this might be a good moment to mention the "engine problem" again

first the one-core-api is giving a nice support for some win6+ apis 

since we talk about phyton stopping the xp support we can point out the engine question again

a engine often use functions of a certain OS, is written for that certain OS 

elder programming languages useally never had a such point
neither if it was c, c++, assembly, basic, delphi

because that are a programming language ... that dont need a certain "windows, linux, mac" function

today that is changing 

the new c++ styles often get tranlated into a different code (which then use a OS function) -> and then you have it your nt 6+ is involved
a such example would be the c-runtime - even tho you written a normal c++ code the c++ code still now involves that c-runtime
and that c-runtime use nt 6+ functions

for c++ mutex would be a such example
https://en.cppreference.com/w/cpp/thread/mutex
however there is not only a nt 6+ interpration for this (aka srw locks)
you also could use a thread based atom style to solve this problem 
there are some more, keyed_events, mutex windows functions as as createmutexa, creatthread styles, or criticalsection styles

when i saw a new project i saw the following problem
it uses DX11 
it uses phyton 
it uses cmake 
it needs VS2019 (aka new c++ styles + the c-runtime)
the project itself already where written with windows 10 functions

often you dont have insight into the things these use (i often call them engines)
lets say phyton break - then you cant compile it up because phyton decided to longer like xp
if cmake use nt6 then you also cant compile up
if visual studio wants a newer version you cant compile up
if directx wants a newer version of directx you also cant compile up

that makes it a lot to go through before you even can do anything

the new trends doing exactly so even ffmpeg is going into that direction (for example ffmpegs
cuda engine)

in this discussion it seems to be bond to phyton 

a possible solution would be a code translation from phyton to c++ (normal styles ones)
a good thing with c is that you can always have a c interpration in comparison to a other language without having a hard time with a lot of math like in assembly

assembly for example can represent any language - its because all languages create a assembly code in the end 
c++ made a good compromise (but new c++ styles going into a direction to be something like a java script)

im trying to point out that all of these try not to be just a programming language, they going into a different direction to like a script and engines

so if phyton is not possible anymore, i would suggest a translation to c++

UCRT itself uses WinSocks while my code doesn't... 

[K4sum1]

@nicolaasjan Can you enable issues on your yt-dlp GitHub repo?

I was about to report an issue to the yt-dlp GitHub, but I tried official yt-dlp to test, and it just doesn't have the issue, which means something is wrong with your fork. However issues aren't enabled on your repo, so I can't report it there.

This command with your fork downloads the worse AAC audio instead of the superior Opus audio for the video, even though I specify bestaudio in the command.

yt-dlp.exe -f "(bestvideo[height<=720]+bestaudio/best[height<=720])[vcodec!*=av01]" -o "%%(channel)s [%%(channel_id)s]/%%(upload_date)s - %%(title)s - (%%(duration)ss) [%%(id)s].%%(ext)s" --merge-output mkv --write-info-json --write-description --write-thumbnail --add-metadata --write-sub --all-subs --embed-subs "https://youtu.be/bCTObNkRGsg"

The same command in the official yt-dlp downloads the proper Opus audio for the video.

I can download the Opus audio with your fork by doing -F which gives me the Opus audio as 251, and then doing -f 251. So it can grab the audio fine, it just doesn't recognize it as being the best audio for the video.

Also while I was still making the issue, if I add -vU to the beginning of the above command, it properly downloads the Opus audio for the video. I don't know why.

Also I'm using the win7 version.

Edited June 5 by K4sum1

[nicolaasjan]

@K4sum1

Could you try again with the new update?

An important issue was fixed.

I tried in my Windows 7 VM with the following command:

yt-dlp --no-config -f "(bestvideo[height<=720]+bestaudio/best[height<=720])[vcodec!*=av01]" -t mkv "https://youtu.be/bCTObNkRGsg"

And it gave me an mkv file with opus audio:

Algemeen
Unique ID                                : 57964954628617501393979581759164836982 (0x2B9BA4E945544816E3D80FC0D01CEC76)
Volledige naam                           : C:\Users\Nico\I Built a Toilet Paper Slot Machine and It Actually Works! [bCTObNkRGsg].mkv
Formaat                                  : Matroska
Formaatversie                            : Version 4
Bestandsgrootte                          : 5,04 MiB
Duur                                     : 2 min 22s
Totale bitrate                           : 297 kb/s
Framerate                                : 30,000 FPS
Gebruikt programma                       : Lavf62.0.102
Gebruikte encoderbibliotheek             : Lavf62.0.102
ErrorDetectionType                       : Per level 1

Video
ID                                       : 1
Formaat                                  : VP9
Formaatprofiel                           : 0
Codec-ID                                 : V_VP9
Duur                                     : 2 min 22s
Breedte                                  : 360 pixels
Hoogte                                   : 640 pixels
Beeldverhouding                          : 0,562
Frameratemodus                           : Constant
Framerate                                : 30,000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Taal                                     : Engels
Default                                  : Ja
Forced                                   : Nee
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

Audio
ID                                       : 2
Formaat                                  : Opus
Codec-ID                                 : A_OPUS
Duur                                     : 2 min 22s
Kanaal(en)                               : 2 kanalen
Channel layout                           : L R
Samplerate                               : 48,0 kHz
Bit depth                                : 32 bits
Compression mode                         : Lossy
Video vertraging                         : 7 ms
Taal                                     : Engels
Default                                  : Ja
Forced                                   : Nee

 

[K4sum1]

That fixed it for me, thank

[j7n]

Can you download videos that are in another language but have an alternate audio stream in English? Sometimes Youtoube shows a title in English, I download the video for later viewing and I find that I can't understand anything.

[nicolaasjan]

7 hours ago, j7n said:

Can you download videos that are in another language but have an alternate audio stream in English? Sometimes Youtoube shows a title in English, I download the video for later viewing and I find that I can't understand anything.

Can you try:

--extractor-args youtube:lang=en

?

[Edit]

Ignore that.

That is for the title, not for the audio.

Maybe first get the formats using `yt-dlp -F URL`.

Then choose for example this to get this mr. Beast video dubbed in Russian:

yt-dlp -f 136+140-1 https://www.youtube.com/watch?v=yhB3BgJyGl8

Or:

yt-dlp -f "bv*+ba[language=ru]" https://www.youtube.com/watch?v=yhB3BgJyGl8

 

Edited July 1 by nicolaasjan

[j7n]

It seems to work. I can add [language=en] to my existing format query. It seems to also download videos that are not in English (at all) instead of failing.

Lately many videos don't download. It gives one of these error messages: an experiement is forced to use SABR, or all TV formats use DRM. It then proceeds to download a very big VP9 file without sound. I need to watch the downloader dosbox to see if the error happens, cancel and try again, perhaps in 720 pixel height to get a good video.

[nicolaasjan]

13 hours ago, j7n said:

Lately many videos don't download. It gives one of these error messages: an experiment is forced to use SABR

It's a convoluted mess...

See issue #12482.

You may need to provide a PO Token. 

That said, I didn't yet have this warning (I download 1080p avc1/mp4a videos most of the time).

Quote

or all TV formats use DRM

Related?

[VistaLover]

There's something wrong with the latest (v2025.07.11) youtube-dl.exe build downloaded from GitHub: 

https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.11

https://github.com/nicolaasjan/youtube-dl/releases/download/2025.07.11/youtube-dl.exe

youtube-dl -vU => 

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-vU']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2025.07.11
[debug] Lazy loading extractors enabled
[debug] Single file build
[debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015
[debug] exe versions: none
[debug] Proxy map: {}
Traceback (most recent call last):
  File "C:\Users\nico\Desktop\youtube-dl_source\youtube_dl\update.py", line 48, in update_self
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 470, in open
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 580, in http_response
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 502, in error
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 442, in _call_chain
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 685, in http_error_302
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 470, in open
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 580, in http_response
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 508, in error
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 442, in _call_chain
  File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 588, in http_error_default
urllib.error.HTTPError: HTTP Error 404: Not Found

ERROR: can't find the current version. Please try again later.

The previous compile, of version 2025.06.26: 

https://github.com/nicolaasjan/youtube-dl/releases/download/2025.06.26/youtube-dl.exe

, behaves as expected:

youtube-dl -vU => 

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-vU']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2025.06.26
[debug] Lazy loading extractors enabled
[debug] Single file build
[debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015
[debug] exe versions: none
[debug] Proxy map: {}
youtube-dl is up to date (2025.06.26)

Many thanks for your ongoing efforts  towards maintaining support for "our" older OSes  ...

[nicolaasjan]

@VistaLover

That's because of line 37 in `./youtube_dl/update.py`.

    UPDATE_URL = 'https://yt-dl.org/update/'

For some reason it redirects to:

https://github.com/yt-dlp/yt-dlp/update/ ---> 404. 

In version 2025.06.26 (and previous versions) I had it set to:

    UPDATE_URL = 'https://ytdl-org.github.io/youtube-dl/update/'

(also 404, by the way)

My version is not supposed to be updated with `-U`. 

Do you perhaps have any idea how to change `update.py` for my fork to actually make it work with `-U`?

[Edit]

I think I managed to fix it. Took `update.py` from youtube-dl Nightly as an example. 

youtube-dl -vU
[debug] System config: []
[debug] User config: ['--console-title', '--rm-cache-dir', '-i', '-o', '/dev/shm/test-ytd/%(title)s.%(ext)s', '-f', 'bestvideo[height<=1080][ext=mp4][vcodec^=avc]+bestaudio[ext=m4a]/best[ext=mp4]/best', '--no-mtime', '--embed-thumbnail', '--force-ipv4']
[debug] Custom config: []
[debug] Command-line args: ['-vU']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2025.07.12
[debug] Lazy loading extractors enabled
[debug] Single file build
[debug] Python 3.10.12 (CPython x86_64 64bit) - Linux-5.15.0-143-generic-x86_64-with-glibc2.35 - OpenSSL 3.0.2 15 Mar 2022 - glibc 2.35
[debug] exe versions: ffmpeg N-120171-g05094c1749-20250705, ffprobe N-120171-g05094c1749-20250705, rtmpdump 2.4
[debug] Proxy map: {}
Latest version: 2025.07.12, Current version: 2025.07.12
youtube-dl is up to date (2025.07.12)
Removing cache dir /home/nico/.cache/youtube-dl ..

I also don't understand why @dirkf still hasn't updated the Installation section in the Readme. It's a complete mess.

 

BTW, I've made a significant change to `./youtube_dl/utils.py`, as I suggested here. Youtube-dl actually works now.

Edited yesterday at 08:54 AM by nicolaasjan

[VistaLover]

10 hours ago, nicolaasjan said:

That's because of line 37 in `./youtube_dl/update.py`.

    UPDATE_URL = 'https://yt-dl.org/update/'

... Huh, I see  ...

10 hours ago, nicolaasjan said:

For some reason it redirects to:

https://github.com/yt-dlp/yt-dlp/update/ ---> 404. 

This is very puzzling, indeed ; in fact, the "yt-dl.org" domain now auto-redirects to yt-dlp GitHub URLs, e.g. 

https://yt-dl.org => https://github.com/yt-dlp/yt-dlp

, which, of course, is a fork of the original youtube-dl project; I think dirkf doesn't have immediate access to the "yt-dl.org" server (wasn't that one blocked in Germany at some point?), so the answer about who arranged the autoredirection to yt-dlp might be possibly found inside the yt-dlp repo itself (too hot here currently for me to check, sorry ) ...

11 hours ago, nicolaasjan said:

My version is not supposed to be updated with `-U`. 

I know; however, I have a small list of test commands I issue with fresh releases of both youtube-dl (nightly branch) and yt-dlp (your "Vista" compatible build) and that same list was used to test your 2025.07.11 compile; that was how I noticed the change in behaviour for " -vU" ...

11 hours ago, nicolaasjan said:

Do you perhaps have any idea how to change `update.py` for my fork to actually make it work with `-U`?

[Edit]

I think I managed to fix it. Took `update.py` from youtube-dl Nightly as an example.

As I'm not proficient in Python (quite the opposite, in fact ), that was what I was about to suggest to you  ; glad you got it sorted already  ...

11 hours ago, nicolaasjan said:

why @dirkf still hasn't updated the Installation section in the Readme. It's a complete mess.

The same  with most "yt-dl.org" links contained inside: 

https://ytdl-org.github.io/youtube-dl/download.html

11 hours ago, nicolaasjan said:

BTW, I've made a significant change to `./youtube_dl/utils.py`, as I suggested here

I know  ; I had already modified locally the latest "official" Nightly release (2025.05.05) according to your posted diff on GH; let's hope a py3.4 solution becomes available if evil Google  start blocking Chrome > 97 UAs...

Best regards  !

[nicolaasjan]

43 minutes ago, VistaLover said:

As I'm not proficient in Python (quite the opposite, in fact ), that was what I was about to suggest to you  ; glad you got it sorted already  ...

I don't know anything about Python either, but I just uploaded the new `update.py` (with only one line changed) into the GitHub web editor and committed. 

[VistaLover]

15 hours ago, nicolaasjan said:

I think I managed to fix it.

... Some fine tuning is still needed, am afraid ; yes, I got build "2025.07.12" to update to "2025.07.12.1" via "-U" from the cmdline,

youtube-dl -vU =>

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-vU']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2025.07.12
[debug] Lazy loading extractors enabled
[debug] Single file build
[debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015
[debug] exe versions: none
[debug] Proxy map: {}
Latest version: 2025.07.12.1, Current version: 2025.07.12
Current Build Hash 58815fc0de70a06e76a9e9ca0337dfcdda59b1db0ffed12d150df626d8cd7735
Updating to version 2025.07.12.1 ...
WARNING: no hash information found for the release
Updated youtube-dl to version 2025.07.12.1

but a WARNING is issued during that process: 

Quote

WARNING: no hash information found for the release

Is this something that can be fixed somehow? FWIW, that warning isn't there when updating dirkf's "nightly": 

youtube-dl -vU => 

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-vU']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2025.02.28 [673277e51] (single file build)
[debug] ** This version was built from the latest master code at https://github.com/ytdl-org/youtube-dl.
[debug] ** For support, visit the main site.
[debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015
[debug] exe versions: none
[debug] Proxy map: {}
Latest version: 2025.05.05, Current version: 2025.02.28
Current Build Hash a1ab42ffb8175b7d32c87e986b5d9f476b952b239aae7a228fac4b6bd8a81b3e
Updating to version 2025.05.05 ...
Updated youtube-dl to version 2025.05.05

Thanks in advance  ...

[nicolaasjan]

8 hours ago, VistaLover said:

Is this something that can be fixed somehow? FWIW, that warning isn't there when updating dirkf's "nightly": 

Hmm...

I honestly have no idea.

The build hashes for `youtube-dl.exe` in my repo can be seen under Assets.

However, in the Nightly repo there are separate SHA2-256SUMS files. Maybe the program looks for these? (wild guess)

The executables in my repo aren't built by GitHub Actions, but manually uploaded.

I think you shouldn't worry about it to much.

[VistaLover]

8 hours ago, nicolaasjan said:

I honestly have no idea.

The build hashes for `youtube-dl.exe` in my repo can be seen under Assets.

However, in the Nightly repo there are separate SHA2-256SUMS files. Maybe the program looks for these? (wild guess)

I took a closer look at updated file "update.py":

https://github.com/nicolaasjan/youtube-dl/blob/embedthumbnail/youtube_dl/update.py

which you originally copied from: 

https://github.com/ytdl-org/ytdl-nightly/blob/master/youtube_dl/update.py

The update process correctly "calculates" the hashsum of "current" version, 

Latest version: 2025.07.12.1, Current version: 2025.07.12
Current Build Hash 58815fc0de70a06e76a9e9ca0337dfcdda59b1db0ffed12d150df626d8cd7735

which is indeed identical to the value displayed at 

https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.12

Which part of the code inside "update.py" is responsible for that? I understand that your tags/releases don't have a SHA2-256SUMSfile as asset...

Updating to version 2025.07.12.1 ...
WARNING: no hash information found for the release

According to 

https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.12.1

the missing hashsum value for youtube-dl.exe should be:

21534c1543d62f4543efff017da1c8dd18a47e64995fd7e8c84215a433752db5

Why isn't "update.py" able to "calculate" it and, more importantly, how can it be fixed? GitHub adding a "sha256:*" column under assets (not as separate asset) is a relatively new feature, AFAIAA...

In file update.py, I can identify two hashsum calculating blocks:

https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L84-L91

Is this one for "current" (non-updated) binary?

Then, there is:

https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L130-L138

which obviously pertains to the "updated" binary; I can see mentions there of files "SHA2-256SUMS" that your fork lacks; lastly, the WARNING is issued as a result of lines: 

https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L172-L174

Someone knowledgeable in Python needs to review the "update.py" file and come up with a "fix"; perhaps if you kindly ask dirkf in GitHub, he could oblige  ...

8 hours ago, nicolaasjan said:

I think you shouldn't worry about it to[o] much.

C'mon, you know me better than that  ...

Sorry for being a PITA, best wishes  !