Leaderboard

StartAllBack 3.9.16

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20251011-3219d2d-uxp-b709881389-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20251011-3219d2d-uxp-b709881389-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20251011-3219d2d-uxp-b709881389-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20251011-d849524bd-uxp-b709881389-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20251011-d849524bd-uxp-b709881389-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20251011-d849524bd-uxp-b709881389-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20251011-d849524bd-uxp-b709881389-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20251011-d849524bd-uxp-b709881389-w7plus-avx2.7z No official UXP changes picked since my last build. No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - mailnews: fix OAuth2Providers path (16dc4c9168) - Add support for HTMLSlotElement.assignedElements() (#2) (169c949e49) - Merge pull request #37 from ClassicNick/Merge-20251005 (f24e68da7b) - style: color-mix: when either color resolves to NS_COLOR_CURRENTCOLOR, it will cause color value reevaluation and cause stack overflow. hack it to use parent color instead. (702d61e68e) - caps: hack - check `mCSP` RefCount to avoid circular calls (b709881389) Update Notice: - You may delete file named icudt*.dat inside program folder when updating from old releases. * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20250927-3219d2d-uxp-50b6047c84-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20250927-3219d2d-uxp-50b6047c84-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20250927-3219d2d-uxp-50b6047c84-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20250927-d849524bd-uxp-50b6047c84-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20250927-d849524bd-uxp-50b6047c84-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20250927-d849524bd-uxp-50b6047c84-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20250927-d849524bd-uxp-50b6047c84-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20250927-d849524bd-uxp-50b6047c84-w7plus-avx2.7z Official UXP changes picked since my last build: - No issue - Clarify Azure Back-end info. (c7e103b06e) - Revert "[gfx] Guard against possible race via gfxFontEntry::GetFontTable." (060e2965b8) - [gfx] Clarify comments. (6e19656e11) - Issue #2852 - Parse full cache-control headers. (16164b3d38) - [gfx] Use std::size rather than hardcoding an array size (3a121f34c8) - Issue #2852 - Follow-up: Add comment and fix formatting. (1bcdad3ef1) - Issue #2790 - Follow-up: Ensure both text and background are set. (c9e08cb2f5) - Revert "Issue #2258 - Part 4: Clean up unused pointers." (7b4bb08257) - Revert "Issue #2258 - Part 3: Allow sniffing with XCTO:nosniff + empty MIME type." (2d4d48db72) - Revert "Issue #2258 - Part 2: Move XCTO:nosniff check into sniffers." (73c9c1dd73) - Revert "Issue #2258 - Part 1: Support XCTO:nosniff when navigating." (0d00c84033) - Issue #2258 - Make sure we favor sniffing when the content-type header is empty. (659a3c0fcc) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. Update Notice: - You may delete file named icudt*.dat inside program folder when updating from old releases. * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

change user agent compatibility to firefox compatibility in preferences dialog.

https://github.com/yt-dlp/yt-dlp/issues/14456#issuecomment-3339167951: --extractor-args "youtube:player-client=default,-tv_simply"

I made an update to yt-dlp for Vista, while also applying the diff's we discussed (_video.py changed a bit, due to an error). Furthermore, I found a PyInstaller 6.15.0 for Vista here (whl) and used that with success. (didn't work on XP...)

Updated yt-dlp_Py3.14.0_x86_Vista. (with IOS patch ) @Reino; Please test if this still suits your needs.

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20251011-40a79c75-uxp-b709881389-xpmod.7z BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20251011-40a79c75-uxp-b709881389-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/boc-uxp/tree/custom * Notice: the profile prefix (i.e. parent folder names) are also changed since 2020-08-15 build, you may rename their names before using new binaries when updating from builds before 2020-08-15. -- New build of HBL-UXP for XP! Test binary: IceDove-UXP(mail) https://o.rthost.win/hbl-uxp/icedove.win32-20251011-id-656ea98-uxp-b709881389-xpmod.7z IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20251011-id-656ea98-ia-c642e3c-uxp-b709881389-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/icedove-uxp/tree/winbuild https://github.com/roytam1/iceape-uxp/tree/winbuild

Fortunately, my main system (Linux Mint) didn't have any issue compiling Brotli "automagically" when installing the dependencies for my newly compiled Python 3.14 (altinstall; that is, it is installed without interfering with system Python). Compiler is shipped with the distro. No problem, I was suspecting that already. It is.

Thanks ; they note: Hopefully, the brotli py3.14 wheel (file brotli-1.1.0-cp314-cp314-win32.whl) you kindly shared remains Vista-compatible; though, TBH, I'm not aware of any tests (within the context of yt-dlp or otherwise) I can submit it to ... Other than that, thank you for the details of the compilation procedure ; I agree it's not for the faint-hearted (or those lacking access to recent OS+H/W); when I, regrettably, find that PyPI misses wheels for a specific "module+module version+CPython+architecture" combination, I usually issue: python -m pip install module==specific_version and then let pip do its job in invoking setuptools+wheel to compile from module source; in the meantime, I cross my fingers for things to go as expected , which isn't always the case ; if the compilation succeeds, then pip will store in its cache a copy of the generated wheel, for easy re-usage; the local path to that wheel is being displayed in the command prompt window, so I always grab a copy from there ; of course, this is for pure Python modules, for ones with C/C++ extensions, a compiler must be made available to CPython (as you detailed yourself); CPython > 3.4 requires VS2015+, not compatible with my current OS ... Huh??? The above was meant to be written as: ... are compiled with adang1345's py3.13 (branch) implementation so that was a typo/oversight on my part ; apologies... Ofc I'm aware you've been using 3.13.7 for the win7 (+Vista) yt-dlp variants, that's why I wrote an update was due to recently released 3.13.8 ... ... That's your call, surely, but I'm more of a conservative person myself , who doesn't believe "the latest is the greatest"; however, if you're absolutely certain the yt-dlp code is fully compatible with recently released py3.14 (and the CPython itself doesn't come with any major bug), then go for it ; personally, I'd stick with the minimum CPython version mandated by yt-dlp, soon to be py3.10 (but it's also nice I can experiment with higher versions here, all thanks to adang1345 ) ... Best regards.

I used this: https://github.com/mstorsjo/llvm-mingw The 32bit build was compiled with Python 3.14.0 (x86) from adang1345 on Windows 10 IoT Enterprise LTSC. The 64bit build was compiled with Python 3.14.0 (x86-64) from adang1345 on Windows 7. To let Python use this compiler, place a file named `distutils.cfg` (see below) in `.\Lib\distutils` in Python install directory (create folder `distutils`). [build] compiler = mingw32 Build Brotli: Download source tarball and extract. In source directory run: python setup.py build_ext --compiler=mingw32 install Build wheel: python setup.py build_ext --compiler=mingw32 bdist_wheel In the directory where the built wheel is, run: pip install --force-reinstall brotli-1.1.0-cp314-cp314-win32.whl Huh??? .\yt-dlp_win7.exe -v [debug] Command-line config: ['-v'] [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@2025.10.05.061237 (win7_exe*) [debug] Python 3.13.7 (CPython AMD64 64bit) - Windows-7-6.1.7601-SP1 (OpenSSL 3.0.16 11 Feb 2025) [debug] exe versions: ffmpeg git-2025-10-04-e05f8ac-ffmpeg-windows-build-helpers (fdk,setts), ffprobe git-2025-10-04-e05f8ac-ffmpeg-windows-build-helpers, phantomjs 2.5.0 [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.1.0, certifi-2025.08.03, curl_cffi-0.13.0, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.5.0, websockets-15.0.1 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets, curl_cffi [debug] Extractor Plugins: NSigDeno (YoutubeIE) [debug] Plugin directories: C:\Users\Nico\AppData\Roaming\yt-dlp\plugins\bgutil-ytdlp-pot-provider\yt_dlp_plugins, C:\Users\Nico\AppData\Roaming\yt-dlp\plugins\yt-dlp-YTNSigDeno\yt_dlp_plugins [debug] Loaded 1833 extractors And the next Win7 builds will be Py3.14 based.

Hi ; well, cmalex's py3.11.4 assemblies (one compatible with just XP and one with Vista+) aren't currently being hosted on GitHub (AFAIAA), but they can be ; OTOH, adang1345's py3.13.7 assembly is already hosted on GitHub, and so is 3dyd's custom PyInstaller build used to make the Win7/Vista yt-dlp distributions; it may be possible, at least in theory, to author a modded GA workflow file to point to the custom implementations of CPython+PyInst necessary to package the Win7/Vista builds; e.g., upstream are using their own, custom, build of PyInstaller to create the "official" yt-dlp releases; perhaps a consultation with your "AI friend(s)" (or a question on SO, etc.) could prove beneficial in fully automating even the (currently) manually created release assets ; just a thought from a dedicated (hardly intelligent ) friend of yours... Best wishes !

IMO the internet got 'bad' once 'normal' people found it. But I think that is more nostalgia for the most part. As for when that happened, I'd say (at least in the US) that happened once Classmates came around. Everyone who was in high school or college went onto there to keep touch afterwards. That site got stepped on by Facebook which was originally designed for college students, but became so popular that old people joined it to keep in touch with those who were on it. For the current generation that is moving into the world, Facebook is seen as a site for old people which is a quote I've heard from multiple people of the younger generations, an insight I am afforded since I 'moonlight' at an arcade. This is only my perspective on things, but normal/old people from 20 years ago were basically computer illiterate, and astonishingly, people of that same stereotype in the current day are still mostly computer illiterate despite having grown up in with computers in a fully connected world. Combine that with the mentality that corporations have of treating adults (employees) like children and you end up with web technologies designed to protect the computer illiterate but in a fashion doesn't feel like the correct way to do it. I find it amusing that the link to this article on the Guardian brings me to a page where half of it is covered by a blue privacy/cookie notification. But overall I think that there are certainly many good points about how the internet has evolved and it is actually better in many ways now than it used to be. It is certainly more useful, something I didn't really grasp because I never had a mobile phone that was new enough to do anything cool until just recently. I think it will get better and we will figure out how to evolve it to deal with the current issues it has. There are more eyes on it now than ever before and that means more ideas of how to do things will occur. But that doesn't mean that there won't be some new dumb trend that everyone adopts that we'll have to deal with. We may end up looking back and laugh about how we were all bent out of shape about captchas and cookie banners in the face of whatever annoying thing we'll be having to deal with.

It 's working here on New Moon.

Updated yt-dlp_Py3.13.7_x86_Vista. (with IOS patch )

... Hi ; most unfortunately, this isn't how things work ; Google , the owners of YouTube, have unleashed a war of annihilation against every kind of YT downloaders and they're NOT excluding/pardoning any of them based on the OS they're compatible with ; and, trust me, every breaking change Google implement (on purpose) isn't meant to leave "older" versions of downloaders unscathed ... XP-compatibility in Q4 of 2025 is also a concern for many Windows apps, not only Video Downloaders... I tend to stay clear of GUI media downloaders, so, alas, if you're in search for one of them, I'm afraid I won't be the person to recommend one to you... My own experience is that most of the GUI YT downloaders are frontends of the well-known CLI (Python) apps youtube-dl and its fork, yt-dlp; the GUI apps either use the standalone youtube-dl.exe or yt-dlp.exe binaries under the hood or use the respective libs inside their source code; as a consequence, whenever Google break youtube-dl/yt-dlp, the apps become broken, too ... Recently, Google implemented a breaking change of a great magnitude, which should explain your observation that yt-dlp and youtube-dl were impacted/broken, too, a stop-gap/interim solution has been implemented for both, but they were actually "stitched back together with duct tape", meaning they can break again at any time... More permanent solutions for YouTube downloading in those apps will leave, probably, any WinOS < Win10 uncovered (too early to tell with absolute certainty, maybe Win7 will be spared, but things are very grim for XP/Vista ) ; at the time of this writing, working versions can be found at: https://github.com/ytdl-org/ytdl-nightly/releases/download/2025.09.29/youtube-dl.exe (official nightly version) https://github.com/nicolaasjan/youtube-dl/releases/download/2025.09.29/youtube-dl.exe (fork of the above with a few custom modifications) https://github.com/nicolaasjan/yt-dlp/releases/download/2025.09.27.071342/yt-dlp_x86_winXP.exe If you're not familiar with those two CLI apps, am afraid this isn't the place to ask for help; however, ample HowTos can be found online with a simple web search, both apps have detailed wiki sections (assuming one already knows to invoke apps from the Windows command prompt) ... For developments related to both youtube-dl+yt-dlp, keep an eye on the dedicated MSFN thread: https://msfn.org/board/topic/184368-who-here-has-a-youtube-dl-compile-for-winxp Best regards ...

... Probably not their work , per se (seeing that they have the Polish flag before their username); published builds there are the impressive work of a Japanese person, whose username (in Japanese) is "あべちん" (that Google translates to "Abechin") ; in fact, I had contacted him some years ago about some issues in his FFmpeg builds, at a time when machine translation wasn't perfect (and AI totally absent); his blog's comment form, e.g. http://blog.k-tai-douga.com/article/191451101.html#comment (Leave a comment) wouldn't accept just Latin characters (I posted in English), so I had to include some Kanji characters, too, for my message to go through ... We did communicate in the end, the problems were mitigated in a future FFmpeg release...

Confirmed. Thanks.

Thank you @nicolaasjan for your yt-dlp builds. I have made a Windows XP compatible build of FFmpeg that targets a Pentium 4. I relied heavily on rdp and @Reino build scripts so thanks also to them. ffmpeg-8.1-630-635cb4543f-win32-static-xpmod-P4.7z libfdk-aac-2.0.3-158-d8e6b1a-win32-xpmod-P4.7z

alright, found problematic code and fixed, will be available in next build. https://github.com/roytam1/UXP/commit/16dc4c916886bfb6947726f0e8a38a9e474f7644

That's why I decided to make diffs again. 😐 I will apply the custom changes only to the "Vista" variant offered here. It will work on higher versions of Windows as well, so @Reino can test it. Updated yt-dlp_Py3.13.7_x86_Vista.

New build of post-deprecated Serpent/moebius for XP! * Notice: This repo will not be built on regular schedule, and changes are experimental as usual. ** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions. Test binary: Win32 https://o.rthost.win/basilisk/basilisk55-win32-git-20250927-fb9f6eff8-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk55-win64-git-20250927-fb9f6eff8-xpmod.7z repo: https://github.com/roytam1/basilisk55 Repo changes: - ported from UXP: No issue - Clarify Azure Back-end info. (c7e103b0) (a9de514bd) - import from UXP: Revert "[gfx] Guard against possible race via gfxFontEntry::GetFontTable." (060e2965) (068d2d8b2) - import from UXP: [gfx] Clarify comments. (6e19656e) (840d26a08) - import from UXP: Issue #2852 - Parse full cache-control headers. (16164b3d3) (88a1c0050) - import from UXP: [gfx] Use std::size rather than hardcoding an array size (3a121f34) (fc33f4e70) - import from UXP: Issue #2852 - Follow-up: Add comment and fix formatting. (1bcdad3e) (c24c415a9) - import from UXP: Issue #2790 - Follow-up: Ensure both text and background are set. (c9e08cb2f) (39e14308a) - import from UXP: Revert "Issue #2258 - Part 4: Clean up unused pointers." (7b4bb082) (99f5c8f0f) - import from UXP: Revert "Issue #2258 - Part 3: Allow sniffing with XCTO:nosniff + empty MIME type." (2d4d48db) (a38d80555) - import from UXP: Revert "Issue #2258 - Part 2: Move XCTO:nosniff check into sniffers." (73c9c1dd) (2f8889ad7) - ported from UXP: Revert "Issue #2258 - Part 1: Support XCTO:nosniff when navigating." (0d00c840) (434f021fb) - import from UXP: Issue #2258 - Make sure we favor sniffing when the content-type header is empty. (659a3c0f) (fb9f6eff8)

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20250927-40a79c75-uxp-50b6047c84-xpmod.7z BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20250927-40a79c75-uxp-50b6047c84-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/boc-uxp/tree/custom * Notice: the profile prefix (i.e. parent folder names) are also changed since 2020-08-15 build, you may rename their names before using new binaries when updating from builds before 2020-08-15. -- New build of HBL-UXP for XP! Test binary: IceDove-UXP(mail) https://o.rthost.win/hbl-uxp/icedove.win32-20250927-id-656ea98-uxp-50b6047c84-xpmod.7z IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20250927-id-656ea98-ia-c642e3c-uxp-50b6047c84-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/icedove-uxp/tree/winbuild https://github.com/roytam1/iceape-uxp/tree/winbuild

... I'm sorry I have to say this , but once the hack currently implemented by upstream stops working (and it will stop ), for XP/Vista[/Win7] users, for which the scheduled workaround, deno, isn't compatible, "Apple-device" (iOS+web_safari) type of YouTube (HLS) streams will be the ONLY accessible options, at least until Google restricts them further with a POT implementation; the log below was generated with yesterday's Vista build of yours , it provides a glimpse of how things would look when "the hack" has been broken and the deno-enabling PR merged: yt-dlp_x86 --extractor-args "youtube:player_client=ios,web_safari" -vF "O5TS2CbBhKo" [debug] Command-line config: ['--extractor-args', 'youtube:player_client=ios,web_safari', '-vF', 'O5TS2CbBhKo'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT) [debug] yt-dlp version local@2025.09.25 [4429fd045] (win_x86_exe) [debug] Python 3.11.9 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.5.2 5 Aug 2025) [debug] exe versions: none [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.1.0, certifi-2025.08.03, mutagen-1.47.0, requests-2.32.5, sqlite3-3.45.1, urllib3-2.5.0, websockets-15.0.1 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1833 extractors [debug] [youtube] [pot] PO Token Providers: none [debug] [youtube] [pot] PO Token Cache Providers: memory [debug] [youtube] [pot] PO Token Cache Spec Providers: webpo [youtube] Extracting URL: O5TS2CbBhKo [youtube] O5TS2CbBhKo: Downloading webpage [debug] [youtube] Forcing "main" player JS variant for player 0004de42 original url = /s/player/a61444a1/player_ias.vflset/en_US/base.js [youtube] O5TS2CbBhKo: Downloading ios player API JSON [youtube] O5TS2CbBhKo: Downloading web safari player API JSON [debug] [youtube] O5TS2CbBhKo: ios client https formats require a GVS PO Token which was not provided. They will be skipped as they may yield HTTP Error 403. You can manually pass a GVS PO Token for this client with --extractor-args "youtube:po_token=ios.gvs+XXX". For more information, refer to https://github.com/yt-dlp/yt-dlp/wiki/PO-Token-Guide . To enable these broken formats anyway, pass --extractor-args "youtube:formats=missing_pot" [debug] [youtube] Extracting signature function 0004de42-main-107 [debug] Loading youtube-sigfuncs.0004de42-main-107 from cache [debug] Loading youtube-nsig.0004de42-main from cache [debug] [youtube] Decrypted nsig Nc-7Qm-M-NmbBoH => S5jQA8mpxn7KDw WARNING: [youtube] O5TS2CbBhKo: Some web_safari client https formats have been skipped as they are missing a url. YouTube is forcing SABR streaming for this client. See https://github.com/yt-dlp/yt-dlp/issues/12482 for more details [youtube] O5TS2CbBhKo: Downloading m3u8 information [youtube] O5TS2CbBhKo: Downloading m3u8 information [debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec, channels, acodec, lang, proto [debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec, channels, acodec, lang, proto, size, br, asr, vext, aext, hasaud, id [info] Available formats for O5TS2CbBhKo: ID EXT RESOLUTION FPS CH | FILESIZE TBR PROTO | VCODEC VBR ACODEC ASR MORE INFO ---------------------------------------------------------------------------------------------------------------------- sb3 mhtml 48x27 0 | mhtml | images storyboard sb2 mhtml 80x45 1 | mhtml | images storyboard sb1 mhtml 160x90 1 | mhtml | images storyboard sb0 mhtml 320x180 1 | mhtml | images storyboard 233 mp4 audio only | m3u8 | audio only unknown Untested, Default, low, IOS 234 mp4 audio only | m3u8 | audio only unknown Untested, Default, high, IOS 602 mp4 256x144 12 | ~ 2.55MiB 89k m3u8 | vp09.00.10.08 89k video only Untested, IOS 91 mp4 256x144 24 | ~ 5.55MiB 193k m3u8 | avc1.4D400C mp4a.40.5 WEB-S 269 mp4 256x144 24 | ~ 5.55MiB 193k m3u8 | avc1.4D400C 193k video only Untested, IOS 603 mp4 256x144 24 | ~ 5.06MiB 176k m3u8 | vp09.00.11.08 176k video only Untested, IOS 92 mp4 426x240 24 | ~ 10.22MiB 356k m3u8 | avc1.4D4015 mp4a.40.5 WEB-S 229 mp4 426x240 24 | ~ 10.22MiB 356k m3u8 | avc1.4D4015 356k video only Untested, IOS 604 mp4 426x240 24 | ~ 8.23MiB 286k m3u8 | vp09.00.20.08 286k video only Untested, IOS 93 mp4 640x360 24 | ~ 23.51MiB 818k m3u8 | avc1.4D401E mp4a.40.2 WEB-S 230 mp4 640x360 24 | ~ 23.51MiB 818k m3u8 | avc1.4D401E 818k video only Untested, IOS 18 mp4 640x360 24 2 | ? 11.63MiB 405k https | avc1.42001E mp4a.40.2 22k 360p, WEB-S 605 mp4 640x360 24 | ~ 14.13MiB 492k m3u8 | vp09.00.21.08 492k video only Untested, IOS 94 mp4 854x480 24 | ~ 41.82MiB 1456k m3u8 | avc1.4D401E mp4a.40.2 WEB-S 231 mp4 854x480 24 | ~ 41.82MiB 1456k m3u8 | avc1.4D401E 1456k video only Untested, IOS 606 mp4 854x480 24 | ~ 22.32MiB 777k m3u8 | vp09.00.30.08 777k video only Untested, IOS 95 mp4 1280x720 24 | ~ 72.92MiB 2538k m3u8 | avc1.64001F mp4a.40.2 WEB-S 232 mp4 1280x720 24 | ~ 72.92MiB 2538k m3u8 | avc1.64001F 2538k video only Untested, IOS 609 mp4 1280x720 24 | ~ 33.23MiB 1157k m3u8 | vp09.00.31.08 1157k video only Untested, IOS 96 mp4 1920x1080 24 | ~138.27MiB 4813k m3u8 | avc1.640028 mp4a.40.2 WEB-S 270 mp4 1920x1080 24 | ~138.27MiB 4813k m3u8 | avc1.640028 4813k video only Untested, IOS 614 mp4 1920x1080 24 | ~ 50.15MiB 1746k m3u8 | vp09.00.40.08 1746k video only Untested, IOS NB: I'm not even sure 4K video streams are being made available for either iOS or Safari ; opus audio is also unavailable; and the web_safari HLS streams are NOT parsed by default, they have to be explicitly requested via the '--extractor-args "youtube:player_client=web_safari"' cmdline flag (or equivalent config setting); personally, I'd hope the POT-less iOS streams remain accessible in the XP/Vista yt-dlp variants, though I realise this wish/expectation could be, simply, "a lot to ask for..." Best wishes!

Another update (sorry...) to yt-dlp for Vista, now made with the new and shiny Python 3.13.7 from adang1345. Link.

Updated yt-dlp for Vista (OpenSSL 3.5.2) here.

I wasn't misleading anyone. I said "pluck some 100 Euro notes", not pluck ONE 100 Euro note," or even "pluck a few 100 Euro notes!" We're all well aware that the cost of a modern PC is more than a few 100-Euro notes. I figured the reader would know how many notes would have to be plucked! But quibbles over adjectives aside, I think we actually agree! My whole point was that there's no such thing as a money tree! Most of us actually have to work quite hard to earn enough money to buy a modern PC; thus it was quite arrogant for someone to respond to a complaint about a Web site being deliberately blocked from working on an older PC with "just go out and buy a new one," as if that were a trivial thing for anyone to do!

98, SE, and ME do have VirtualAllocEx, only 95 doesn't. Use ImportPatcher or Dependency Walker to find all missing functions. If there are only a few, I can write a wrapper.

Hello Leokids123. You asked: "Can you disable your adblocker and enable Javascript?" Answer: Javascript is enabled in St52 when visiting Paypal. And this is the result when trying to sign in my Paypal account with ST52 and - hosts file adblocking disabled - DNS server adblocking disabled It is as NotHereToPlayGames said: "the SECURITY CHALLENGE CANNOT BE LOADED."

I did just discover that the paypal slide mouse screen in my older version of Serpent is DEPENDENT UPON the ISP that I use. I canceled my previous ISP but it remains active until the end of my billing cycle (I only have two more days) - I get no slide mouse screen in Serpent when connected via my previous ISP (cable). I *DO* get the slide mouse in Serpent (unsolvable - checkbox turns green but page does NOT advance) in Serpent when connected via my new ISP (fiber optic).

New build of post-deprecated Serpent/moebius for XP! * Notice: This repo will not be built on regular schedule, and changes are experimental as usual. ** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions. Test binary: Win32 https://o.rthost.win/basilisk/basilisk55-win32-git-20251011-74c412b6d-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk55-win64-git-20251011-74c412b6d-xpmod.7z repo: https://github.com/roytam1/basilisk55 Repo changes: - import from `custom` branch of UXP: Add support for HTMLSlotElement.assignedElements() (#2) (169c949e) (4c681e213) - import from `custom` branch of UXP: style: color-mix: when either color resolves to NS_COLOR_CURRENTCOLOR, it will cause color value reevaluation and cause stack overflow. hack it to use parent color instead. (702d61e6) (026a84877) - import from `custom` branch of UXP: caps: hack - check `mCSP` RefCount to avoid circular calls (b7098813) (74c412b6d)

@roytam1https://github.com/ClassicNick/Arctic-Fox/releases/tag/2024-10-18 I now have a slightly updated source code release of Arctic-Fox winbuild available. I also set up a Linux Mint 19.3 build machine, so hopefully I'll be able to learn how to push git commits.

now it works, added override to New Moon

I use this: https://yadi.sk/d/KpTGDPITsNWn7w the program itself is in the Timer_Fix folder. Brief description: Timer_Fix program with source code written in Visual Studio 6.0. The program has no interface; after launch, it will set the system timer to a period of 1 ms and leave it unchanged. The program will remain in the processes until the OS is rebooted. For convenience, it is best to place this program in “Startup” and completely forget about the problem of time passing. No issues have been found with using this method.

Yes, if there is interest I will update periodically. @xjani I was not aware of your work. I will check it out.

After installing v3.9.16 via this link and checking for updates through the app, I get a Updates available but for v3.9.15.

For some reason the StartAllBack website states the latest version is still 3.9.15, but this installer is in fact for 3.9.16. Also, the latest version isn't coming down via checking for updates through the app.

1. Run this .BAT file before Windows start: @echo off ::MTRR 0 - 256M UC @ F0000000 msr_set.exe 201 0000000F F0000800 msr_set.exe 200 00000000 F0000000 ::MTRR 2 - 256M WC @ E0000000 msr_set.exe 205 00000000 00000000 msr_set.exe 204 00000000 E0000001 msr_set.exe 205 0000000F F0000800 ::MTRR 1 - 512M UC @ C0000000 msr_set.exe 203 0000000F E0000800 msr_set.exe 202 00000000 C0000000 ::set Default Cache Type to 06h WB msr_set.exe /W 2FF 00000000 00000C06 ::MTRR 3 - Unused msr_set.exe 207 00000000 00000000 msr_set.exe 206 00000000 00000000 ::MTRR 4 - Unused msr_set.exe 209 00000000 00000000 msr_set.exe 208 00000000 00000000 then run Windows and if nothing bad will happen show me the output of MTRR_VAR under Windows 2. The default driver behaviour under Windows 9x so disastrous that it overwrites all WB registers from BIOS - so no, under 64-bit OSes all will work fine, BIOS works correctly here. 3. > 00000000BFEF0000 - 00000000BFF00000 : 0000000000010000 2 (Reserved), 64K And just for completeness - you BIOS has the bug described as Problem 2 here: https://msfn.org/board/topic/186768-bug-fix-vmmvxd-on-handling-4gib-addresses-and-description-of-problems-with-resource-manager-on-newer-bioses/

... Well, NOT for Safari (WEB-S), but they are for iOS (IOS): yt-dlp -vF "BdGH9jgSjkU" [debug] Command-line config: ['--ffmpeg-location', '..\\FFmpeg', '--downloader-args', 'ffmpeg:-v 8 -stats', '-vF', 'BdGH9jgSjkU'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out cp1253 (No VT), error cp1253 (No VT), screen cp1253 (No VT) [debug] yt-dlp version local@2025.09.27 [88e2a2de8] (win_x86_exe) [debug] Python 3.13.7 (CPython AMD64 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.0.16 11 Feb 2025) [debug] exe versions: ffmpeg n6.1-dev-2615-N-112499-ga76b409 (setts), ffprobe n6.1-dev-2615-N-112499-ga76b409, phantomjs 2.1.1, rtmpdump 2.4-102-ga3a600d-get_iplayer [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.1.0, certifi-2025.08.03, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.5.0, websockets-15.0.1 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1833 extractors [debug] [youtube] [pot] PO Token Providers: none [debug] [youtube] [pot] PO Token Cache Providers: memory [debug] [youtube] [pot] PO Token Cache Spec Providers: webpo [youtube] Extracting URL: BdGH9jgSjkU [youtube] BdGH9jgSjkU: Downloading webpage [youtube] BdGH9jgSjkU: Downloading tv client config [debug] [youtube] Forcing player 0004de42 in place of player a61444a1 original url = /s/player/a61444a1/player_ias.vflset/en_US/base.js [youtube] BdGH9jgSjkU: Downloading tv player API JSON [youtube] BdGH9jgSjkU: Downloading web safari player API JSON [youtube] BdGH9jgSjkU: Downloading ios player API JSON [debug] Loading youtube-nsig.0004de42-main from cache [debug] [youtube] Decrypted nsig V7EvyWFb_ePZPOi => oPTz67zi2fhD0w [debug] [youtube] Decrypted nsig uJsaqyJjIXjIMyX => x2fOZfn_9WVCRA [debug] [youtube] BdGH9jgSjkU: ios client https formats require a GVS PO Token which was not provided. They will be skipped as they may yield HTTP Error 403. You can manually pass a GVS PO Token for this client with --extractor-args "youtube:po_token=ios.gvs+XXX". For more information, refer to https://github.com/yt-dlp/yt-dlp/wiki/PO-Token-Guide . To enable these broken formats anyway, pass --extractor-args "youtube:formats=missing_pot" [youtube] BdGH9jgSjkU: Downloading m3u8 information [youtube] BdGH9jgSjkU: Downloading m3u8 information [debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec, channels, acodec, lang, proto [debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec, channels, acodec, lang, proto, size, br, asr, vext, aext, hasaud, id [info] Available formats for BdGH9jgSjkU: ID EXT RESOLUTION FPS CH | FILESIZE TBR PROTO | VCODEC VBR ACODEC ABR ASR MORE INFO -------------------------------------------------------------------------------------------------------------------------------------- sb3 mhtml 48x27 0 | mhtml | images storyboard sb2 mhtml 80x45 0 | mhtml | images storyboard sb1 mhtml 160x90 0 | mhtml | images storyboard sb0 mhtml 320x180 0 | mhtml | images storyboard 233 mp4 audio only | m3u8 | audio only unknown [en] Untested, Default, low, IOS 234 mp4 audio only | m3u8 | audio only unknown [en] Untested, Default, high, IOS 249-drc webm audio only 2 | 7.25MiB 51k https | audio only opus 51k 48k [en] low, DRC, TV, webm_dash 250-drc webm audio only 2 | 8.93MiB 63k https | audio only opus 63k 48k [en] low, DRC, TV, webm_dash 249 webm audio only 2 | 7.21MiB 51k https | audio only opus 51k 48k [en] low, TV, webm_dash 250 webm audio only 2 | 8.92MiB 63k https | audio only opus 63k 48k [en] low, TV, webm_dash 140-drc m4a audio only 2 | 18.26MiB 129k https | audio only mp4a.40.2 129k 44k [en] medium, DRC, TV, m4a_dash 251-drc webm audio only 2 | 15.93MiB 113k https | audio only opus 113k 48k [en] medium, DRC, TV, webm_dash 140 m4a audio only 2 | 18.26MiB 129k https | audio only mp4a.40.2 129k 44k [en] medium, TV, m4a_dash 251 webm audio only 2 | 15.91MiB 113k https | audio only opus 113k 48k [en] medium, TV, webm_dash 602 mp4 256x144 15 | ~ 12.81MiB 91k m3u8 | vp09.00.10.08 91k video only Untested, IOS 91 mp4 256x144 30 | ~ 23.57MiB 167k m3u8 | avc1.4D400C mp4a.40.5 [en] Untested, WEB-S 269 mp4 256x144 30 | ~ 23.57MiB 167k m3u8 | avc1.4D400C 167k video only Untested, IOS 160 mp4 256x144 30 | 4.40MiB 31k https | avc1.4d400c 31k video only 144p, TV, mp4_dash 603 mp4 256x144 30 | ~ 23.12MiB 164k m3u8 | vp09.00.11.08 164k video only Untested, IOS 278 webm 256x144 30 | 9.08MiB 64k https | vp9 64k video only 144p, TV, webm_dash 394 mp4 256x144 30 | 5.66MiB 40k https | av01.0.00M.08 40k video only 144p, TV, mp4_dash 92 mp4 426x240 30 | ~ 43.94MiB 312k m3u8 | avc1.4D4015 mp4a.40.5 [en] Untested, WEB-S 229 mp4 426x240 30 | ~ 43.94MiB 312k m3u8 | avc1.4D4015 312k video only Untested, IOS 133 mp4 426x240 30 | 9.57MiB 68k https | avc1.4d4015 68k video only 240p, TV, mp4_dash 604 mp4 426x240 30 | ~ 39.49MiB 280k m3u8 | vp09.00.20.08 280k video only Untested, IOS 242 webm 426x240 30 | 10.60MiB 75k https | vp9 75k video only 240p, TV, webm_dash 395 mp4 426x240 30 | 9.68MiB 69k https | av01.0.00M.08 69k video only 240p, TV, mp4_dash 93 mp4 640x360 30 | ~ 97.41MiB 691k m3u8 | avc1.4D401E mp4a.40.2 [en] Untested, WEB-S 230 mp4 640x360 30 | ~ 97.41MiB 691k m3u8 | avc1.4D401E 691k video only Untested, IOS 134 mp4 640x360 30 | 18.95MiB 134k https | avc1.4d401e 134k video only 360p, TV, mp4_dash 18 mp4 640x360 30 2 | 61.07MiB 433k https | avc1.42001E mp4a.40.2 44k [en] 360p, TV 605 mp4 640x360 30 | ~ 88.79MiB 630k m3u8 | vp09.00.21.08 630k video only Untested, IOS 243 webm 640x360 30 | 24.07MiB 171k https | vp9 171k video only 360p, TV, webm_dash 396 mp4 640x360 30 | 20.46MiB 145k https | av01.0.01M.08 145k video only 360p, TV, mp4_dash 94 mp4 854x480 30 | ~150.81MiB 1069k m3u8 | avc1.4D401F mp4a.40.2 [en] Untested, WEB-S 231 mp4 854x480 30 | ~150.81MiB 1069k m3u8 | avc1.4D401F 1069k video only Untested, IOS 135 mp4 854x480 30 | 30.51MiB 216k https | avc1.4d401f 216k video only 480p, TV, mp4_dash 606 mp4 854x480 30 | ~135.96MiB 964k m3u8 | vp09.00.30.08 964k video only Untested, IOS 244 webm 854x480 30 | 39.73MiB 282k https | vp9 282k video only 480p, TV, webm_dash 397 mp4 854x480 30 | 33.93MiB 241k https | av01.0.04M.08 241k video only 480p, TV, mp4_dash 136 mp4 1280x720 30 | 107.76MiB 764k https | avc1.4d401f 764k video only 720p, TV, mp4_dash 247 webm 1280x720 30 | 78.17MiB 554k https | vp9 554k video only 720p, TV, webm_dash 300 mp4 1280x720 60 | ~537.81MiB 3814k m3u8 | avc1.4D4020 mp4a.40.2 [en] Untested, WEB-S 311 mp4 1280x720 60 | ~537.81MiB 3814k m3u8 | avc1.4D4020 3814k video only Untested, IOS 298 mp4 1280x720 60 | 192.41MiB 1365k https | avc1.4d4020 1365k video only 720p60, TV, mp4_dash 612 mp4 1280x720 60 | ~426.09MiB 3021k m3u8 | vp09.00.40.08 3021k video only Untested, IOS 302 webm 1280x720 60 | 122.09MiB 866k https | vp9 866k video only 720p60, TV, webm_dash 398 mp4 1280x720 60 | 98.26MiB 697k https | av01.0.08M.08 697k video only 720p60, TV, mp4_dash 301 mp4 1920x1080 60 | ~883.96MiB 6268k m3u8 | avc1.64002A mp4a.40.2 [en] Untested, WEB-S 312 mp4 1920x1080 60 | ~883.96MiB 6268k m3u8 | avc1.64002A 6268k video only Untested, IOS 299 mp4 1920x1080 60 | 357.68MiB 2537k https | avc1.64002a 2537k video only 1080p60, TV, mp4_dash 617 mp4 1920x1080 60 | ~844.54MiB 5989k m3u8 | vp09.00.41.08 5989k video only Untested, IOS 303 webm 1920x1080 60 | 229.47MiB 1627k https | vp9 1627k video only 1080p60, TV, webm_dash 399 mp4 1920x1080 60 | 165.16MiB 1171k https | av01.0.09M.08 1171k video only 1080p60, TV, mp4_dash 623 mp4 2560x1440 60 | ~ 1.94GiB 14096k m3u8 | vp09.00.50.08 14096k video only Untested, IOS 308 webm 2560x1440 60 | 714.57MiB 5068k https | vp9 5068k video only 1440p60, TV, webm_dash 400 mp4 2560x1440 60 | 437.55MiB 3103k https | av01.0.12M.08 3103k video only 1440p60, TV, mp4_dash 628 mp4 3840x2160 60 | ~ 3.87GiB 28064k m3u8 | vp09.00.51.08 28064k video only Untested, IOS 315 webm 3840x2160 60 | 2.03GiB 14721k https | vp9 14721k video only 2160p60, TV, webm_dash 401 mp4 3840x2160 60 | 813.80MiB 5772k https | av01.0.13M.08 5772k video only 2160p60, TV, mp4_dash i.e. WEB-S stops at 1080p60, while IOS further offers 1440p60 and 2160p60 ; when the tv client "goes bust" (either because the implemented "player 0004de42" hack stops working (and/or upstream move to the deno dep) or Google enforce the POT requirement on it - like they did yesterday for the tv_simply client), iOS formats will be the only source for >=1440p resolutions; until IOS itself "goes bust", too ...

Well, at least there is Deno v1.27.0, the last one that works on Windows 7 (only 64bit...). https://github.com/yt-dlp/yt-dlp/issues/14404#issuecomment-3327285821 [debug] Command-line config: ['-vUF', 'https://www.youtube.com/watch?v=flexhqu1zhg'] [debug] User config "C:\Users\Nico\AppData\Roaming\yt-dlp\config.txt": ['--rm-cache-dir', '--console-title', '--extractor-args', 'youtube:bypass_native_jsi;deno_no_jitless', '--list-formats-as-table', '--no-mtime', '-o', '~/Desktop/%(title)s.%(ext)s', '-S', 'res:720,vcodec:h264,acodec:mp4a', '--embed-thumbnail', '--add-metadata', '--convert-thumbnails', 'jpg', '--ppa', 'ffmpeg:-metadata synopsis=""', '--force-ipv4', '--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@2025.09.23.052315 (win_exe) [debug] Python 3.13.7 (CPython AMD64 64bit) - Windows-7-6.1.7601-SP1 (OpenSSL 3.0.16 11 Feb 2025) [debug] exe versions: ffmpeg git-2025-09-14-bdb81d9-ffmpeg-windows-build-helpers (fdk,setts), ffprobe git-2025-09-14-bdb81d9-ffmpeg-windows-build-helpers, phantomjs 2.5.0 [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.1.0, certifi-2025.08.03, curl_cffi-0.13.0, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.5.0, websockets-15.0.1 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets, curl_cffi [debug] Extractor Plugins: NSigDeno (YoutubeIE) [debug] Plugin directories: C:\Users\Nico\AppData\Roaming\yt-dlp\plugins\yt-dlp-YTNSigDeno\yt_dlp_plugins [debug] Loaded 1833 extractors Removing cache dir C:\Users\Nico/.cache\yt-dlp ... [debug] Fetching release info: https://api.github.com/repos/nicolaasjan/yt-dlp/releases/latest Latest version: nicolaasjan/yt-dlp@2025.09.23.052315 yt-dlp is up to date (nicolaasjan/yt-dlp@2025.09.23.052315) [debug] [youtube+NSigDeno] [pot] PO Token Providers: none [debug] [youtube+NSigDeno] [pot] PO Token Cache Providers: memory [debug] [youtube+NSigDeno] [pot] PO Token Cache Spec Providers: webpo [youtube+NSigDeno] Extracting URL: https://www.youtube.com/watch?v=flexhqu1zhg [youtube+NSigDeno] flexhqu1zhg: Downloading webpage [debug] [youtube+NSigDeno] Forcing "main" player JS variant for player 0004de42 original url = /s/player/2b83d2e0/player_ias.vflset/en_US/base.js [youtube+NSigDeno] flexhqu1zhg: Downloading tv simply player API JSON [youtube+NSigDeno] flexhqu1zhg: Downloading tv client config [youtube+NSigDeno] flexhqu1zhg: Downloading tv player API JSON [youtube+NSigDeno] flexhqu1zhg: Downloading player 0004de42-main [debug] [youtube+NSigDeno] Deno command line: deno run C:\Users\Nico\AppData\Local\Temp\tmpkq8t1kxl [debug] [youtube+NSigDeno] Decrypted nsig CgOJja7cldvYMEu => WV3WYPF2UPHWkQ [debug] Saving youtube-nsig.0004de42-main to cache [debug] [youtube+NSigDeno] Deno command line: deno run C:\Users\Nico\AppData\Local\Temp\tmpf_1d82in [debug] [youtube+NSigDeno] Decrypted nsig 5tJUPxD_Bi4bcSP => onOnwCzMQinnaQ [debug] Sort order given by user: res:720, vcodec:h264, acodec:mp4a [debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec, channels, acodec, lang, proto [debug] Formats sorted by: hasvid, ie_pref, res:720(720.0), vcodec:h264(7), acodec:mp4a(9), quality, fps, hdr:12(7), source, channels, lang, proto, size, br, asr, vext, aext, hasaud, id [SponsorBlock] Fetching SponsorBlock segments [debug] SponsorBlock query: https://sponsor.ajay.app/api/skipSegments/0854?service=YouTube&categories=%5B%22filler%22%2C+%22intro%22%2C+%22preview%22%2C+%22music_offtopic%22%2C+%22interaction%22%2C+%22outro%22%2C+%22sponsor%22%2C+%22selfpromo%22%5D&actionTypes=%5B%22skip%22%2C+%22poi%22%2C+%22chapter%22%5D [SponsorBlock] No matching segments were found in the SponsorBlock database [info] Available formats for flexhqu1zhg: ID EXT RESOLUTION FPS CH | FILESIZE TBR PROTO | VCODEC VBR ACODEC ABR ASR MORE INFO ------------------------------------------------------------------------------------------------------------------------------- sb2 mhtml 48x27 2 | mhtml | images storyboard sb1 mhtml 80x45 1 | mhtml | images storyboard sb0 mhtml 160x90 1 | mhtml | images storyboard 249-drc webm audio only 2 | 319.04KiB 40k https | audio only opus 40k 48k low, DRC, TV-S, webm_dash 250-drc webm audio only 2 | 397.98KiB 50k https | audio only opus 50k 48k low, DRC, TV-S, webm_dash 249 webm audio only 2 | 316.67KiB 40k https | audio only opus 40k 48k low, TV-S, webm_dash 250 webm audio only 2 | 394.90KiB 50k https | audio only opus 50k 48k low, TV-S, webm_dash 251-drc webm audio only 2 | 731.72KiB 93k https | audio only opus 93k 48k medium, DRC, TV-S, webm_dash 251 webm audio only 2 | 727.11KiB 92k https | audio only opus 92k 48k medium, TV-S, webm_dash 140-drc m4a audio only 2 | 1.00MiB 130k https | audio only mp4a.40.2 130k 44k medium, DRC, TV-S, m4a_dash 140 m4a audio only 2 | 1.00MiB 130k https | audio only mp4a.40.2 130k 44k medium, TV-S, m4a_dash 394 mp4 256x144 24 | 530.40KiB 67k https | av01.0.00M.08 67k video only 144p, TV-S, mp4_dash 278 webm 256x144 24 | 682.80KiB 86k https | vp9 86k video only 144p, TV-S, webm_dash 160 mp4 256x144 24 | 796.09KiB 101k https | avc1.4d400c 101k video only 144p, TV-S, mp4_dash 395 mp4 426x240 24 | 725.21KiB 92k https | av01.0.00M.08 92k video only 240p, TV-S, mp4_dash 242 webm 426x240 24 | 746.23KiB 94k https | vp9 94k video only 240p, TV-S, webm_dash 133 mp4 426x240 24 | 1.75MiB 227k https | avc1.4d4015 227k video only 240p, TV-S, mp4_dash 396 mp4 640x360 24 | 2.36MiB 306k https | av01.0.01M.08 306k video only 360p, TV-S, mp4_dash 243 webm 640x360 24 | 1.48MiB 192k https | vp9 192k video only 360p, TV-S, webm_dash 134 mp4 640x360 24 | 4.55MiB 590k https | avc1.4d401e 590k video only 360p, TV-S, mp4_dash 18 mp4 640x360 24 2 | 5.56MiB 720k https | avc1.42001E mp4a.40.2 44k 360p, TV-S 397 mp4 854x480 24 | 4.36MiB 565k https | av01.0.04M.08 565k video only 480p, TV-S, mp4_dash 244 webm 854x480 24 | 6.62MiB 858k https | vp9 858k video only 480p, TV-S, webm_dash 135 mp4 854x480 24 | 8.15MiB 1056k https | avc1.4d401e 1056k video only 480p, TV-S, mp4_dash 779 webm 1080x608 24 | 3.81MiB 494k https | vp9 494k video only 480p, TV-S, webm_dash 780 webm 1080x608 24 | 6.63MiB 859k https | vp9 859k video only 480p, TV-S, webm_dash 398 mp4 1280x720 24 | 8.70MiB 1128k https | av01.0.05M.08 1128k video only 720p, TV-S, mp4_dash 247 webm 1280x720 24 | 11.59MiB 1502k https | vp9 1502k video only 720p, TV-S, webm_dash 136 mp4 1280x720 24 | 17.79MiB 2306k https | avc1.4d401f 2306k video only 720p, TV-S, mp4_dash

... Well, isn't this the norm lately? Bad news from everywhere ... But if it involves yt-dlp/youtube-dl, then it must surely come from most satanic Google ... During the last years, "they"'ve been mercilessly throwing in the direction of the popular YT-downloaders whatever they could devise to thwart their normal operation ; proprietary HTML5 player blobs with encrypted signature (n-sig), (lately) streams protected with PO Tokens, various manipulations of signed-in cookies, irreversible breakage of the "hack" to download age-gated clips without being signed-in, very intense IP blocking client-side, using their proprietary streaming protocol called SABR, even full-blown DRM on (TV) streams was trialed some weeks ago (plus other things I forget) ... All this time, the yt-dlp devs tried the best they had in their arsenal to combat Google's anti-download agenda; up until now, the n-sig decrypting "issue" had been successfully dealt with with frequent updates on the yt-dlp side (as soon as a new yt-player showed up), using for decryption what is called a Native JS Interpreter (pure-Pyrhon-based); successful decryption of n-sig is vital these days, because it's an "all or nothing case"; many months ago, YT would let you download at significantly throttled speeds without a decrypted n-sig, but currently you're plainly being denied any download ... The Native JS Interpreter worked fine until (and including) yt-player 0004de42 ; then, yt-player 2b83d2e0 has started to propagate across YT CDNs: https://github.com/yt-dlp/yt-dlp/issues/14400 I have to rely on the expertise of the yt-dlp devs, but, most sadly, it appears this new yt-player is a new kind of a formidable beast that is no match for the Python-based JSinterp ... At the moment, a stop-gap solution has been implemented, https://github.com/yt-dlp/yt-dlp/pull/14398 but, as it's noted, ... hence: https://github.com/yt-dlp/yt-dlp/issues/14404 I do remember well that in the past, in the case of an unsolvable signature, PhantomJS would kick-in; it didn't work in all cases, the 32-bit executable requires Vista+ and the project has now become an "abandonware", thus having been rejected, for "security" reasons, by the overwhelming majority of the yt-dlp "fanbois" (most of them already on Win11) ... I haven't closely followed yt-dlp development ever since they dropped py3.7 support, but has PhantomJS already been dropped as a JSInterp fallback inside the yt-dlp code? In any case, the proposed "solution" by the yt-dlp team isn't suitable for the retrocomputing (Windows) communities whichever way you look at it ; deno is built on recent versions of Node JS and, as such, requires Win10+; the standalone Windows executable they provide is ONLY 64-bit ; this means: a) 32-bit OSes are unsupported (unless someone can compile deno from source as a Windows x86 binary) b) every Windows OS below 10 will be unsupported (that will include Win8.1, that official yt-dlp still supports); this is the part that infuriates me the most : our "brave" retrocomputing heros have gone to great lengths to backport recent CPython versions to XP+Vista (cmalex , literally from the front line ), Vista+Win7 (Vladimir Andreevich), Win7+ (Aohan Dang), just so that XP/Vista/Win7 users can continue to use yt-dlp, but most evil Google , with just one strike, will nullify all those combined efforts ; because how good would yt-dlp/youtube-dl be if it can't fetch YouTube ? Yes, the upstream original app, youtube-dl, that never had a JSInterp fallback (namely PhantomJS) to begin with, in the last months relied mainly on yt-dlp "solutions" to fix its broken JSInterp, whenever the case arose ... Given that youtube-dl caters specifically to older CPython versions (hence, older OSes capable of running said older CPython versions), its predicament is more pronounced: https://github.com/ytdl-org/youtube-dl/issues/33186 Since every open-source app/project out there seems to support almost every Linux distro (a hyperbole, perhaps, but you get the drift ), it's legacy Windows OS users, again, that will be screwed over ... So full of wrath right now... FWIW, yt-player 2b83d2e0-main has just arrived in my neck of the woods : yt-dl -vF "hS4uoPz_A00" [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['--ffmpeg-location', '.\\FFmpeg', '--external-downloader-args', '-v 8 -stats', '-vF', 'hS4uoPz_A00'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2025.06.29 (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: ffmpeg n6.1-dev-2615-N-112499-ga76b409, ffprobe n6.1-dev-2615-N-112499-ga76b409, phantomjs 2.1.1, rtmpdump 2.4 [debug] Proxy map: {} [youtube] hS4uoPz_A00: Downloading webpage [youtube] hS4uoPz_A00: Downloading TVHTML5 API JSON [youtube] hS4uoPz_A00: Downloading player 2b83d2e0-main WARNING: [youtube] Falling back to generic n function search ERROR: Unable to extract nsig function code (caused by RegexNotFoundError('Unable to extract Initial JS player n function name; please report this issue on https://github.com/ytdl-org/youtube-dl/issues , using the appropriate issue template. Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose option and include the complete output.',)); please report this issue on https://github.com/ytdl-org/youtube-dl/issues , using the appropriate issue template. Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose option and include the complete output. Traceback (most recent call last): File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1856, in _decrypt_nsig File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1968, in _extract_n_function_code File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1971, in _extract_n_function_code_jsi File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1948, in _extract_n_function_name File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1892, in generic_n_function_search File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\common.py", line 1093, in _search_regex youtube_dl.utils.RegexNotFoundError: Unable to extract Initial JS player n function name; please report this issue on https://github.com/ytdl-org/youtube-dl/issues , using the appropriate issue template. Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose option and include the complete output. Traceback (most recent call last): File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1856, in _decrypt_nsig File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1968, in _extract_n_function_code File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1971, in _extract_n_function_code_jsi File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1948, in _extract_n_function_name File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1892, in generic_n_function_search File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\common.py", line 1093, in _search_regex youtube_dl.utils.RegexNotFoundError: Unable to extract Initial JS player n function name; please report this issue on https://github.com/ytdl-org/youtube-dl/issues , using the appropriate issue template. Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose option and include the complete output. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\YoutubeDL.py", line 886, in wrapper File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\YoutubeDL.py", line 982, in __extract_info File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\common.py", line 573, in extract File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 2480, in _real_extract File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 2006, in _unthrottle_format_urls File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1833, in inner File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1825, in inner File "D:\a\ytdl-nightly\ytdl-nightly\youtube_dl\extractor\youtube.py", line 1858, in _decrypt_nsig youtube_dl.utils.ExtractorError: Unable to extract nsig function code (caused by RegexNotFoundError('Unable to extract Initial JS player n function name; please report this issue on https://github.com/ytdl-org/youtube-dl/issues , using the appropriate issue template. Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose option and include the complete output.',)); please report this issue on https://github.com/ytdl-org/youtube-dl/issues , using the appropriate issue template. Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose option and include the complete output. Commiserations...

Yes, form the user perspective it does the same thing, it works a little bit different however as it doesn't replace system files and instead injects custom extending files into processes. And is available for Vista and 7, instead of just Vista as the original extended kernel was

Yes! Because Supermium uses the OPERATING SYSTEM'S "certificate store" and the firewall flagged that the "cert store" was being updated. Now that the OS's cert store is getting your paypal working, you could try importing the OS certs into the non-chrome browsers.

Vista beats 10 and 8!

Most notorious telemetry updates for Win 7 and their descriptions: KB4493132-x86-x64 (End of support notification for Windows 7) KB4524752-x86-x64 (End of support notification for Windows 7 Pro) KB971033-x86-x64 (Update for Windows activation verification technologies) KB2952664-x86-x64 (System compatibility update for transition to Windows 10) KB2977759-x86-x64 (Diagnostics for compatibility issues for transition to Windows 10) KB3021917-x86-x64 (System diagnostics and telemetry for transition to Windows 10) KB3035583-x86-x64 (Update installs the ‘Get Windows 10’ app) KB3068708-x86-x64 (Update to improve quality and telemetry diagnostics) KB3075249-x86-x64 (Update adds telemetry points to the consent.exe file) KB3080149-x86-x64 (Update for CEIP and telemetry diagnostics) KB3081954-x86-x64 (Update to improve working folders and telemetry) KB3123862-x86-x64 (Updated capabilities for upgrading to Windows 10) KB3139923-x86-x64 (Update adds telemetry points to consent.exe file) KB3150513-x86-x64 (Updated configurations for compatibility diagnostics) KB3161608-x86-x64 (Update adds telemetry points to consent.exe file) KB3163589-x86-x64 (Message about running an outdated version of Windows) KB3172605-x86-x64 (Update adds telemetry points to consent.exe) KB3173040-x86-x64 (Notification about the expiration of the Windows 10 upgrade offer) KB3125574-v4 (also inludes unnamed telemetry)

One thing is clear. The mentioned updates are for Windows XP Embedded and definitely not for Server 2003. So that won't work. and truth be told a bit off-topic.

@Dave-H Yesterday I had trouble to access Google and other web sites using HTTPSProxy. What had happened? I checked and found out that HTTPSProxy's cacert.pem was faulty. I downloaded a new one manually from this link https://curl.se/ca/cacert.pem and copied it in HTTPSProxy's program folder. I deleted all certificates in certs folder and after starting the proxy I could access all sites without any problems. Updating cacert.pem in SysTray menu is working again. So what is the teaching of that? You have to check and deeply too. Comparing two files only due to size and date is not enough. A binary comparison is necessary or comparing hash values. You can do it for example with Total Commander. So download a fresh cacert.pem from link above and compare it to yours just to be sure your certs are valid and proper in your HTTPSProxy's program folder. Here is a screenshot of my Intermediate Certificate Authorities (there are Microsoft related certificates too): https://imgur.com/G2ogHnj I don't know if they are relevant, they seem to be expired. And here my Third Party Root Certificate Authorities: https://imgur.com/vY3dnq8 What is your current time server? And please upload a new WindowsUpdate.log! Maybe something has changed. A lot of Windows users have reported getting error code 0x80072f8f due to activation problems. So my next question. Is your Windows XP Professional properly activated? Do you have Windows Genuine Advantage (WGA) Validation Tool installed and what is your version? As far as I know the latest version for XP is 1.9.40.0. And I know a lot of questions. Sorry!

New year is coming. Happy 2022! A little guess about the shape of things to come. 1) Omicoof breaks the narrative, but its "escape" will be blamed on the "unvaccinated." It will be allowed to spread wildly and cause lots of disruptions (schools, flights, work, etc.). All of this disruption due to lots of people getting sick all at once will be blamed on the "unvaccinated," even though case loads, etc., will be worse in the vaccinated. This data will all be made foggy, hidden, disrupted, and misreported, of course. The scapegoat must remain. The goal of this uncontrolled omicoof disruption will be more blame upon the "blameworthy" while offering the Regime and its mouthpieces an exit ramp ("The Science changed because the 'unvaccinated' screwed up"). They'll still push "vaccines" in this time even though it's nonsensical, but this will all be in preparation for Phase 2. 2) "Cyber pandemic," massive disruptive cyber attacks interrupting LOTS of stuff, far more disruptive than coof. They've telegraphed this for over a year. Believe it or not, it will kind of be the "unvaccinated" who are blamed for this Cyber Pandemic, but the shift will be from the "unvaccinated" to the "digitally anonymous," who are predominantly "unvaccinated" because they refused to get coof Digital ID "passports." We'll see a massive shift in narrative and scapegoating from the "unvaccinated" to the "digitally anonymous" (or something equivalent), these will be linked to make a scapegoating bridge (like "deplorable" to "unvaccinated"), and a new, hard scapegoating campaign will commence. The goal is always to get to fully controllable Digital ID. It will be racist, sexist, misogynistic, threat to public health, threat to cybersecurity, etc., to refuse a Digital ID, and it will be a full-court press against the "digitally anonymous." That's my best guess for the adventure we face in the first half of 2022, at least so far, reading the entrails the Regime keeps putting out. Make no mistake and take heart, though. They have plans, but they didn't expect to lose this hard this fast. Keep fighting! Author : James Lindsay

I tried it (the .dll) and I didn't experience any crashes , thanks again , win32 . Though, I agree that personal experiences may vary (different hardware) . I'm running quite ancient hardware (by the modern day standards). One PC is with some old Quad Xeon (circa 2009-2010) and another with one of the first Haswells. I already told you and the others : Kaspersky crashes are it's "normal" behaviour , you can search and read it yourself , so we can't be sure whether the dll is faulty or not . As for me , I trust win32 and his experience and I see the dll is working fine. All I'm trying to say , test the DLL with NORMAL software , not that KGB "something" . I'm not sure with what to respond to your topic, since I already suggested mallwarebytes or the brain.exe. About chrome , for me it's just running without any mods with this kernel , there are a lot of folks here that use it too. If firefox works for you , chrome should work too. But you need 64 bit version . Make sure you are running chrome x64.