johk

yes, clear as water, sorry. As I go the default way, I was really missing something

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

http://kmeleonbrowser.org/forum/read.php?19,154431,158596,page=35#msg-158595 Just in case you need something to add.

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.

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.

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 In the version of curl I have I don't have such an EDNS option to test.

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 :-?

From my experience, Japanese content is highly suitable to be geo-fenced. They protect a lot of things from overseas access.

As of... about a month, or two, can't tell exact, NewMoon 28 is unable to login to AOL nor Yahoo (same parent company, same back/front systems). After input the password, nothing but a spinning circle on the submit button. Latest version/build, the same issue persists.

For the shake of test I tried the Windows 7 (32bits) binary posted with quickjs (thanks to the developer of this tiny engine) and I wonder how powerful computers do the people that develop things have? Literally, it hangs a few times through the compute, even for a fraction of a second, while resolving the YouTube challenge :/ Multiply that 2 times, as I check the available formats, and then download the desired format, and the benefits of downloading+playing performance vs viewing on the page, starts to vanish. It has been requiring more and more compute time through time but... wow Or the whole process gets optimized or... YouTube is winning by far. For those interested, I only have a Core 2 Duo. As most here, old hardware, yes. EDIT: I wasn't initially able to make the latest published x64 version (2025.11.01.082330) work with quickjs (my fault by setting the path "--js-runtimes quickjs:'c:\balbla\'" instead "--js-runtimes quickjs:'c:\balbla\qjs.exe'" because I didn't want a PATH path either ;) ) and maybe it has a slightly better performance, but not much. EDIT2: as a side note, I know that the performance drop is not by yt-dlp, nor this build, but the damn YouTube JS and the JS engine, but... just ranting.

In the case of ffmpeg, as I use for more purposes, I use upx to reduce the disk size to around 50% on each file. In terms of run time, it doesn't make to work slower. Give it a try: https://upx.github.io/ (Don't worry to use old versions, I use an old 3.x)

I just read the external JavaScript requirement and... I think I'll give up using it from here. They say that a headless browsers defeats the purpose of yt-dlp, but... an engine over a hundred MiB, a half of Firefox 115 installation doesn't? Come on... I might regret and come back to yt-dlp again, but I think I will switch to the nightmare slow downloads from web download helpers. It is more sane, from my point of view. I'm expectant for the upcoming events...

As a side note, the standalone Windows XP version doesn't work on Windows 7 x64 with the error pointing to GetCPFileNameFromRegistry on kernell32.dll, but no problem with the native. I used to run this version on Windows 7 x64 (as I switched from OS to OS and avoid two installs (aside this I can confirm that the Windows 7 version is slightly faster on its native platform, as you pointed out nicola)). I read quick, but would your release have support/be released after september? Thanks for your efforts nicolaasjan :)

Thanks @Joseph_sw I already had an override and that enabled. I ended removing the override the other day without success. I think toggling the preference fixed it :oS Weird things.

I waited till a new version to report that for X.com/Twitter.com NewMoon 28 is... "This browser is no longer supported". As no one else has reported, am I the only one? This happens on a fresh profile (so no preferences interfering) since a couple of updates. I'm "using" Firefox 115 for X.com/Twitter.com now but... while is smoother with JavaScript is so heavy...