VistaLover

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

... Huh, I see ... 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 ) ... 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" ... 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 ... The same with most "yt-dl.org" links contained inside: https://ytdl-org.github.io/youtube-dl/download.html 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 !

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 ...

https://github.com/advisories/GHSA-mj9c-f5v6-7665 Severity: High (8.1/10) https://chromereleases.googleblog.com/2025/06/stable-channel-update-for-desktop_30.html Manual mitigation, at the expense of performance, if you don't want to update: https://github.com/Alex313031/thorium/issues/1024#issuecomment-3038992237

Out of curiosity, I got myself a HK IP address and then tried to load: https://repo.palemoon.org/MoonchildProductions/UXP This is what I got: It would be far-fetched to think (would it? ) that MC specifically blocked access to his Gitea instance in Hong Kong, where roytam1 resides, as a means of thwarting further development of the UXP "XP forks", that he so much despises... In any case, @roytam1 are you behind the GFW in HK? Can you not use a geo-spoofing application (VPN, VPS, DNS, Shadowsocks, etc. ) to acquire, e.g., a European IP address and properly access RPO? Worst case scenario, one of "us" here could send you a tarball of the proper UXP repo, though currently this stands at ca, 252 MB:

RPO (repo.palemoon.org) is a server owned and paid-for by Moonchild himself; Gitea is just the version control software deployed on that private server to manage source development for UXP, Pale Moon and related projects; it's what is called a "private (self-hosted) Gitea instance" ; on the Anubis test page itself, one can read: ... so I believe MC is mainly concerned with excessive bandwidth consumption; please also note that he had already implemented geolocation-based ACLs (access-control-lists) to counter automated DDoS attacks and, as a consequence, in Hong Kong (where our own roytam1 lives ) RPO is blocked ...

... This only means further/wider proliferation of such MITM anti-crawler "services", with the web becoming even more "unpleasant" as time moves on (with a greater impact, of course, on older browser engines, on old/weak H/W); what's the point of having 500 (or more) Mbps fiber internet speeds when every tab you open in your browser will need additional time to pass complex JS tests? FTR, I keep, for historical purposes, a "portable copy" of NM27 (not the last one published, though), which isn't able to pass the Anubis test (e.g., on RPO Gitea repos); and even Serpent 52 struggles passing that test, especially if I don't disable "security/privacy"-oriented solutions (extensions and/or userscripts); privacy also falls victim here, because you're given no other choice on such web-policing "services": either "open" your "privacy fences" or be denied access to the site you're after ... This is all depression-inducing ...

https://repo.palemoon.org/MoonchildProductions/UXP/issues/1721 https://repo.palemoon.org/MoonchildProductions/UXP/commit/c030a50228349fa1b2c0b4fbc2e83752324dd4d7 https://www.palemoon.org/support/global-privacy-control

@IXOYE : In NM28, a SSUAO for ARTE is needed; posing as FxESR-128 on Win10x86 works for me in order to load its English homepage : general.useragent.override.arte.tv;Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0 ...

Upstream (i.e. UXP/Pale Moon) are already aware: https://forum.palemoon.org/viewtopic.php?t=32222 https://repo.palemoon.org/MoonchildProductions/UXP/issues/2721 Here a workaround is kindly offered (requires an additional extension ) ...

... Respectfully, I beg to disagree ... While 128 is the currently supported Firefox ESR version, the previous ESR (Firefox 115) is also supported, for the sake of Win7/8/8.1 users (support will end, supposedly, next September); the minimum Fx version supported by AMO, is, thus, 115 ... FirefoxESR-115 has the same User Agent String as the release channel Fx-115 had, which was (e.g., on Win7 SP1 32-bit): Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/115.0 For Firefox versions 110-119, the "rv:" value was frozen to 109, due to a Mozilla bug ... Below is r3dfoxESR-115.13.0 (a FirefoxESR-115 fork that is able to run under Vista SP2) with a SSUAO of: general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/115.0 visiting https://addons.mozilla.org/de/firefox/addon/traduzir-paginas-web/ : When the above SSUAO is "lowered" to Fx-114, general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/114.0 ... the issue you reported occurs: So, probably until the end of Sep 2025, Firefox 115 is now the minimum... Kindest regards.

https://github.com/ytdl-org/youtube-dl#video-selection --playlist-start NUMBER Playlist video to start at (default is 1) --playlist-end NUMBER Playlist video to end at (default is last) --playlist-items ITEM_SPEC Playlist video items to download. Specify indices of the videos in the playlist separated by commas like: "-- playlist-items 1,2,5,8" if you want to download videos indexed 1, 2, 5, 8 in the playlist. You can specify range: " --playlist-items 1-3,7,10-13", it will download the videos at index 1, 2, 3, 7, 10, 11, 12 and 13. ... Then make sure you have perused ALL available CLI options (aka switches) for BOTH; for youtube-dl (often abbreviated as just yt-dl), the place to start is: https://github.com/ytdl-org/youtube-dl#options FWIW, yt-dlp is a more "advanced" tool (with more complex syntax and options), that requires some additional expertise on the part of the user ; yt-dlp is not guaranteed to continue to work under XP (and Vista) after this October, when its devs drop py3.9 support (to this day, no py3.10+ fork has been made public that can run on NT 5.x/6.0 ) ....

( Happy Easter to all those who observe it ! ) New r3dfox releases have appeared on its GitHub repo : https://github.com/Eclipse-Community/r3dfox/releases/tag/v128.9.0 ... and: https://github.com/Eclipse-Community/r3dfox/releases/tag/v136.0.4 Many thanks to the maintainer! ...

FYI: https://forum.videolan.org/viewtopic.php?f=14&t=141939 https://forum.videolan.org/viewtopic.php?p=460965#p460965 https://forum.videolan.org/viewtopic.php?f=14&t=160467 The "portable" directory will be populated with below content (settings): ./vlc.exe/portable/vlc/vlc-qt-interface.ini (GUI related settings) ./vlc.exe/portable/ml.xspf (playlist) ./vlc.exe/portable/vlcrc (app related settings) The "portabilised" (nightly) VLC instance will load its settings from said "portable" folder and won't ever touch (mess with) VLC settings extant in %APPDATA% ... Regards.

... I'm well aware , so that's why you weren't quoted ...

aka & nesting selector ... Partial (or full) support is behind custom (experimental) flags on earlier versions of both browsers: Probably useful info for people still on Win7 (where Cr109/Fx115esr are the last officially supported versions) ... https://repo.palemoon.org/MoonchildProductions/UXP/issues?q=CSS&type=all&state=open doesn't display an open issue for this CSS feature under UXP ... Additionally, the footer on https://techcommunity.microsoft.com/ (as well as other content after the "Additional Help & Learning Resources" bit) isn't rendered properly (it renders as a vertical left-hand column) in UXP, possibly the same issue, too ... FWIW, "Microsoft pages" do not contain only stuff exclusive to Win11 , once the nesting selector makes its way onto other web "frameworks" and sites, the breakage on UXP browsers will become more common ...

... Not to jinx things or anything , but you better finish your tests soon ; at the rate we're going, Google have been able to "break" youtube-dl (by serving "specially" crafted JS yt-players) every other day or two ...

126-r7 spoofs v132, for better webcompat :

... Please, STOP spreading untruths! The code is there on GitHub for those willing to read it; after all, Supermium is still OPEN source (minus the wrapper DLLs, that is): https://github.com/win32ss/supermium/issues/1290#issuecomment-2764577016

... Yes, this is really insane of them ; it's not as if discourse-based forums, mostly containing text, need the top-of-the-line JS/CSS features released with "yesterday"'s Google Chrome version ... ... Mozilla have extended Win7's support with Fx115esr until September, but discourse will cut this support 4 months prior, on May 1st! I soon got bored reading the linked announcement and the comments that followed it, their basic reasoning couldn't hold water if it wanted to: (and, correct me if wrong, but "they" can't use English properly, I think "including" should've been "include"); what "improved experiences" for crying out loud? People just post questions (in plain text), sometimes they attach a screengrab, and they expect a helpful reply (also mostly in text); why discriminate against older rendering engines? https://meta.discourse.org/t/dropping-ios-15-other-old-browsers-in-may-2025/358131/33 Will have to wait and see how much "broken" UXP will be after May 1st on discourse-based forums/"communities" (quite a lot of them, actually) ... (above is St52 with the ! Discourse-based forums ||*/browser-detect-$script,important custom uBO-legacy filter...) EDIT: Discourse's browser-feature-checking script is, apparently: https://d11a6trkgmumsb.cloudfront.net/assets/chunk.e772cb6376a12f35fc11.d41d8cd9.br.js:139:266343

A Supermium enthusiast has setup a "mirror" of the original site on GitHub: https://techguy16.github.io/supermium-website/ This should serve as an "interim" solution (fetching files directly from GitHub), until the main site has been properly fully restored (file downloads and the "file directory" are NOT working currently) :

... Has come back here, as of several minutes ; the maintainer wrote: Clearing your computer's DNS cache might help, too ; the site itself is useful for people on very old browsers (e.g. Opera 12), not able to handle Microsoft's GitHub Releases section...

... Very sad development , indeed: https://github.com/win32ss/supermium/issues/1252 https://github.com/win32ss/supermium/discussions/1251 ... I'm quite sure the Supermium naysayers, several of whom frequent these forum(s) , will be now throwing parties...

@Dave-H : https://github.com/win32ss/supermium/commit/fa695faf3889deb57b1e247293c7ceee10161172 ... "Experimental" features, by their nature, do entail the probability of "breaking" some sites, so that's why they're initially launched behind disabled prefs ; this has been happening for years now; adventurous users and/or testers are encouraged to enable those features (preferably on test profiles) and report any breakage experienced either to the browser vendor or the affected site admin(s) - this is how things work; if an obscure site breaks due to such a feature but Google has been left unaware, then that "feature" will make it onto a future Chrome update; Google very seldom revert Chrome changes (unless they're about very prominent sites/services), so in that case the onus will again be on the site admins to "comply" with latest Chrome (and that is why our "legacy" browsers often break) ... Noone here or on GitHub has reported how the BG site currently behaves on latest official Google Chrome (v134), without (the default) and with the offending flag enabled ; maybe the experimental feature in M126 that breaks the site got dropped by the Google Devs, or it's still there behind a disabled pref; if it "makes it" to, say, Chrome 136 (i.e. separated from experimental features and promoted into a default, standard, feature), then BG will render broken in M136 and they will have to fix the issue themselves ... This appears to have been your strong argument both here and in GH, but allow me to say this is NOT a given ; it all depends on how an individual site has been coded; 126-r6 was released on Dec 17th, followed by 126-r7 on Jan 23rd and 132-r0 on Mar 1st; yet you were the first (unlucky?) person to report a breakage almost 3 months after r6's initial public release... Other site admins may be already "tailoring" their site's code under the hood to "foolproof" it against future Google Chrome releases (dev channel is already at version 136), so "other sites" might not break in Sm-132, even if BG currently does ... In any case, "your" issue will get hopefully fixed in Sm-v132-r1 (provided one doesn't touch the "#enable-experimental-web-platform-features" internal flag there) ... Should you wish to keep using 126-r6/r7, you know by now what to do... Cheers ...

... Might be related: https://forum.palemoon.org/viewtopic.php?f=17&t=32150 ... or not ; FWIW, it works here right now, so you may need to resort to a Europe-based VPN node, if available of course ...