VistaLover

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 ... C'mon, you know me better than that ... Sorry for being a PITA, best wishes !

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