VistaLover

Again, autodidact is NOT to blame ; go back some pages in this thread and you'll read (some) users of FFmpeg (on WinXP and elsewhere) declaring they don't want FFplay at all, because they ONLY use dedicated GUI players for playback of media files ; and I don't recall off-hand why the XP shared builds were axed, too, but autodidact simply delivered what (XP) members here asked for ...

... It would appear that Shane is still monitoring this thread ; inside the Supermium-v144-r4_01 release notes, https://github.com/win32ss/supermium/releases/tag/v144-r4_01 this shows up: https://github.com/win32ss/supermium/releases/download/v144-r4_01/supermium_uao.zip Edit: Rather the fix was a consequence of the discussion in: https://github.com/win32ss/supermium/issues/1907 ...

Actually, "supermium_uao.exe" won't launch under XP SP3 (32-bit) because of two missing functions on XP's kernel32 system file: # Report By YY.Depends.Analyzer (Target:5.1.2600-x86) ## kernel32.dll * [ ] InitializeCriticalSectionEx - Supported OS: 6.0.6000, 6.1.7600, 6.2.9200, 6.3.9600, 10.0.10240 - Ref Module: supermium_uao.exe * [ ] LCMapStringEx - Supported OS: 6.0.6000, 6.1.7600, 6.2.9200, 6.3.9600, 10.0.10240 - Ref Module: supermium_uao.exe Above is a log acquired via the YY-Thunks CLI tool; the command I used was: YY.Depends.Analyzer "supermium_uao.exe" /IgnoreReady /ReportView:CheckBox /Target:5.1.2600 As @mjd79 suggested (), if you redirect the kernel32.dll function calls to Supermium's wrapper DLL "pwrp_k32.dll", you'll be able to make the executable XP-compatible ...

FWIW, this tool has existed since Oct 2024 (!), but was being offered exclusively to Patreon paid-subscription members : https://www.patreon.com/posts/supermium-uach-113234339 (... and it does work under Vista SP2 32-bit ) @NotHereToPlayGames , have you read this ?

That last statement has been only PARTIALLY true, or even completely FALSE (based on a user setting), since a great-many number of past Chromium versions; since the "mid-50's", shortly after XP/Vista support went away, Chromium also comes with its own Certificate Store, a la Firefox; the OS cert store can be used as a supplement, too, or completely disabled; I'm too lazy now to search for the very first Chrome version that bundled its own cert store, but as the question involves (recent) Supermium, here's some "enlightening" pictures of Supermium's own CertManager: "localcerts" are the ones imported from the OS CertStore; they can be made available to Supermium, or completely ignored, as per my setting in the picture above ... "crscerts" are Supermium's own CertStore root certificates; there's even the ability to export the store to a PEM file, but NOT import a cert from other sources... Site certs are actually "server" certs; these have to be verified against a cert-chain, possibly involving also "intermediate" certs stored transiently in the store, whose end is always a Root Certificate stored in either the browser's store or the OS store; when server certs expire, the server owner has to renew them with new ones issued by a Certificate Authority (paid-for or free, like "Let's Encrypt"); root certs have very long validity durations and when they expire, it's up to the browser or OS vendor to renew them; also, some root certs sometimes get revoked (because of them having been compromised), so the cert store, be it in a browser or the OS. has to be properly "maintained"; "legacy" WinOSes, no longer supported by MS, usually have stale OS cert stores, so these should either be manually updated somehow , or the user should, instead. turn to apps with their own, maintained, root cert stores ...

Yes, and Moonchild acknowledges this: Perhaps the issue is more visible with tabs-on-bottom ? On Vista, with Aero-enabled, I can't easily tell any difference, though...

And whose fault is that? Certainly NOT @autodidact's ; many users here, especially the "XP-die-hards", complained of "inflated" FFmpeg binary sizes; that they ONLY wanted a binary capable of just remuxing downloaded formats (and only with the h264/aac codecs) from youtube.com; nothing more; IOW, a "bare-bones" FFmpeg compile... So, "they" got what "they" asked for (and no more shared builds, on top of that) ... I, of course, was against such a request, because I also use FFmpeg outside of a yt-dlp context; e.g., the latest XP binary can't even fetch MPEG-DASH streams on its own, because it has been compiled without an XML parser (libxml2)); since I'm on Vista SP2 x86, I stayed silent, as the "Vista builds" (many thanks for those shared binaries, too ) continue to fulfill most of my needs under Vista; no complaints here of any sort, @autodidact !

You're referring to the quickjs release claim, stated below: https://bellard.org/quickjs/ ... but they specifically mention the "bench-v8 (aka v8-v7) score", which I'm certain doesn't take into consideration using the library together with yt-dlp (especially on old, under-powered, H/W like the one many of us here use ) ... In any case, any performance improvement in general should have a beneficial impact even to us using quickjs for "youtube.com" purposes, and this is something that you verified yourself ...

There has been a new release (finally ) by its author, Bellard, of the quickjs JS runtime, necessary for de-scrambling YouTube's nsig challenges (present on most yt_player_clients, except for ANDR-V); the 32-bit binary can be found on: https://bellard.org/quickjs/binary_releases/quickjs-win-i686-2026-06-04.zip (64-bit binary: https://bellard.org/quickjs/binary_releases/quickjs-win-x86_64-2026-06-04.zip) quickjs is the only supported JS runtime on "legacy" WinOSes, like XP SP3/Vista SP2/Win7 SP1; I can't check on XP SP3 x86, but the new release does launch here (Vista SP2 x86): qjs -h => QuickJS version 2026-06-04 usage: qjs [options] [file [args]] -h --help list options -e --eval EXPR evaluate EXPR -i --interactive go to interactive mode -m --module load as ES6 module (default=autodetect) --script load as ES6 script (default=autodetect) --strict force strict mode -I --include file include an additional file --std make 'std' and 'os' available to the loaded script -T --trace trace memory allocation -d --dump dump the memory usage stats --memory-limit n limit the memory usage to 'n' bytes (SI suffixes allowed) --stack-size n limit the stack size to 'n' bytes (SI suffixes allowed) --no-unhandled-rejection ignore unhandled promise rejections -s strip all the debug info --strip-source strip the source code -q --quit just instantiate the interpreter and quit Additionally, the quickjs-ng fork has also seen a new release: https://github.com/quickjs-ng/quickjs/releases/tag/v0.15.1 https://github.com/quickjs-ng/quickjs/releases/download/v0.15.1/qjs-windows-x86.exe This runtime officially supports Win7 SP1 and later, but it can also work under Vista SP2 (but NOT on XP SP3): qjs -h => QuickJS-ng version 0.15.1 usage: qjs [options] [file [args]] -h --help list options -v --version print version string and then exit -e --eval EXPR evaluate EXPR -i --interactive go to interactive mode -C --script load as JS classic script (default=autodetect) -m --module load as ES module (default=autodetect) -I --include file include an additional file --std make 'std', 'os' and 'bjson' available to script -T --trace trace memory allocation -d --dump dump the memory usage stats -D --dump-flags flags for dumping debug data (see DUMP_* defines) -c --compile FILE compile the given JS file as a standalone executable -o --out FILE output file for standalone executables --exe select the executable to use as the base, defaults to the current one --memory-limit n limit the memory usage to 'n' Kbytes --stack-size n limit the stack size to 'n' Kbytes -q --quit just instantiate the interpreter and quit Both are fully supported by latest yt-dlp; performance-wise, they shouldn't differ much, if at all...

@NotHereToPlayGames : https://msfn.org/board/topic/187814-country-flags-missing-to-the-left-of-members-usernames/#findComment-1287938

... Well, I couldn't help noticing that member @Gregg (from the UK), who posted in the r3dfox thread (to which I'm subscribed ) and to which NHTPG kindly replied, now appears as "Guest Gregg" with no profile/membership at all ; I got the impression they were a 100% legitimate member, though ... Many thanks indeed for the prompt fix! Your efforts towards keeping MSFN "alive and kicking" are highly appreciated, and I'm not just saying this; MSFN is one of only two tech-forums I'm a member of, it really means much to me ... Well, for once you're wrong ; I do own a DeLorean myself, be it a plastic scale model of it ; actually, I got carried away by the forum's default date format, which is the one used in the US (i.e. MM/DD/YYYY); so, when composing my post, I mistook "06" as the day of the month (being accustomed to the European format of DD/MM/YYYY); so now you know ...

Today (June 4th 2026) I noticed that I can no longer view a member's country flag to the (upper) left of their username (and above their avatar picture): There appears to be an empty placeholder for the country flag, as one can see when hovering over the "place" the flag should've been displayed, but the actual flag is MIA ; could this issue be looked into, please? PS1: In my account settings, I have chosen to always view members' country flags (if available) ... PS2: This is a reappearance of this older Forum issue ...

... Some explanation to be found here, courtesy of @AstroSkipper ...

(https://panda-free-antivirus.sooftware.com/windows/download/401339) Confirmed also in latest NM28 : (but works in r3dfox-140) @roytam1, any ideas why?

... I'm always puzzled by that type of a query ; both links you posted are currently live/valid, so, with respect, why can't you test yourself? Why do others have to test them for you? In any case, both extensions (not plugins, BTW) belong to a "hybrid" type of an extension, in reality a WebExtension format inside a JetPack extension format; you can see for yourself, if you open the XPIs with 7-zip; as such, they may install under NM28, but they WON'T function as expected (e.g., there's no way to even access their toolbar buttons) ... I haven't tested with latest St52/St55, but they would install there and SHOULD work as expected ; from past recollection, Browsec only offers 4 free/anonymous nodes; unsure what the current state of Windscribe would be; many years ago already, they had disabled the "anonymous" free tier option (initially 2GB, then just 1GB of monthly traffic was allocated to a fresh extension install), now all versions of their extension require you to register an account with them; a valid/verified e-mail address will grant you 10GB of monthly traffic, on a limited subset of their nodes; but v0.1.61, being an ancient one, might've been blocked from connecting to their servers ... PS: Please, don't confuse the official upstream apps with the roytam1 forks; use the terms New Moon 28 and Serpent 52 (55) for the latter; FYI, official Basilisk does not support WebExtensions...

The best/easiest way to tell is to launch Supermium and load "chrome://version/" in a tab; scroll down a bit and in "Executable path" you'll see where the main executable (chrome.exe) launches from ; one line below, there should be "Profile path" and it just tells you where on your disk Supermium's current profile is located (all default and custom browser settings and associated files) ...

... The time is now Sat May 16th 2026, 18:00 GMT and I'm experiencing severely throttled download speeds : Is this something on my end or server-side? My current IP is 46.12.xx.xxx ...

"extension_garbage_collector.cc" is a Chromium source file: https://chromium.googlesource.com/chromium/src/+/8496f370f/chrome/browser/extensions/extension_garbage_collector.cc ... and https://www.reddit.com/r/chrome/comments/1l0nd3l/what_does_this_chrome_garbage_collector_event_in/ https://www.reddit.com/r/WindowsHelp/comments/1itxbf8/what_is_this_in_my_event_viewer/ https://learn.microsoft.com/en-us/answers/questions/3890397/what-is-this-in-the-event-viewer I personally wouldn't worry that much about this; it's just an "informational" event, pertaining to "normal" browser functionality associated with its extensions system ... https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

No : https://forum.palemoon.org/viewtopic.php?t=23281 PS: I realise people on old/weak H/W (like myself ), in an attempt to squeeze more out of the browser, often turn to "about:config" for custom modifications of one or more "advanced" prefs (in the expectation they can potentially make their "old" box behave like a "recent" one ) ; besides the fact these "about:config" prefs are primarily directed at devs (and should not be tinkered by plain users), they are often poorly documented now (because MDN have a nasty habit of removing old documentation), so one can't be 100% sure what the actual/future ramifications of such a change will be; often times, it's just a placebo effect, at best ("I" manually modified the default value, so it "must" have improved performance); in the past, I used to do that myself a lot, but over the years I ended up with the conviction that leaving prefs at their default settings (configured by Mozilla devs) is probably the best policy ; but this is just me...

Have you actually compared this latest build to the 20260411/20260418-released ones? Because "suspect" isn't enough when troubleshooting "performance"-related issues (that are always bound to one's existing H/W and may differ considerably across other setups) ...

... That question means that you have actually missed my previous post here ; latest NM28 gladly accepts palefill-1.30.xpi as a compatible extension (and doesn't disable it permanently, if already installed) ... In all honesty, I didn't test on latest St52, as I left that as an exercise for you ; the observed bug with palefill (and other extensions that have strictCompatibility=true inside their instal.rdfs) was caused by ae7c40d, which first appeared in the 20260418 UXP releases (actual buildID dates may be slightly different inside individual apps); that commit was reverted in 12e7d14, which first appears in this weekend's (20260502) UXP releases; since these are platform-wide commits, I have no reason to think that St52 hasn't been "fixed", while NM28 has; if you find otherwise, please let us know ,,, Best regards.

Nothing of that sort happened here, on any of 3 browsers used at random (NM28/St52/r3dfox-140esr) ; but I don't trust Google to tell me which sites I should visit or not (relevant settings disabled, both under r3dfox and Supermium ) ...

With latest NM28 (32-bit) SSE2 (buildID=20260430023812), I can confirm that the new favicon appears invisible not only inside the bookmarks toolbar, but also inside the bookmarks sidebar: Don't ask me why, I have no clue ; this appears to be UXP-related, as the new favicon does appear inside r3dfox's bookmarks sidebar: The tab bar (and URLbar, in the case of NM28/St52+CTR) looks nice now , though (as already mentioned); we're on a good point already, some fine-tuning is still needed on UXP to make things perfect ... Actually, that one is the favicon the browser defaults to for sites without a proper favicon of their own...

Thanks a lot for the updated Vista SP2 x86 FFmpeg builds; while one can still find FFmpeg builds for Win7+ besides yours on VideoHelp.com (e.g. the ones offered by AnimMouse), Vista+ compatible ones are very hard to come by; you're probably the only person currently targeting this OS, so your efforts are highly appreciated ! I have no issue myself with the current configuration or filesizes of those builds; I do also use them outside of yt-dlp and find them to be capable of all tasks I put them under ; where disk space becomes an issue, I prefer to use the "shared" builds... While it's true that the "XP" builds will run under Vista SP2, the latter are compiled on a more recent compiler and are better optimised for more "recent" H/W; plus, they do differ on their "configuration" (e.g. I do appreciate "--enable-libshine" in the Vista builds): "XP" compiler: gcc 14.3.1 (GCC) 20250901 optimised for Pentium 4 "Vista" compiler: gcc 15.2.0 (Rev14, Built by MSYS2 project) @j7n, since you're on Server 2008R2 SP1, you should prefer the "VISTA" builds over the "XP" ones ... I have tested both build variants and in CPU-intensive jobs (video transcoding), the "Vista" variant is 4-6 % quicker here ; but I only have a Core2 DUO; I expect the difference to be higher in more powerful hardware... @autodidact, please continue to compile and kindly provide the "VISTA" builds; and if the "XP" "crowd" (which has been, historically, difficult to please ) has any issues with that, you can always post them inside the Vista subforum (which, sadly, sees very little action these days ) ... Kind regards.

Yep, that's totally true; ffprobe is often used by the yt-dlp code to "probe" elemental (raw) media streams, often before ffmpeg itself is invoked; both are needed; in fact, when posting issues in their tracker, the yt-dlp devs demand ffprobe logs (though I myself send them MediaInfo logs, instead) ; to save disk space, I use "shared" FFmpeg builds... ... YES, that's what I often do: But it's a shame that audio-only media files can't be played back with FFplay under Vista SP2 (and higher) via drag-n-drop, due to a SDL2 bug: There was a related, long-standing, SDL2 bug that one can read about in below links, https://forum.videohelp.com/threads/388189-ffplay-WASAPI-can-t-initialize-audio-client-error#post2513211 https://trac.ffmpeg.org/ticket/6891 https://stackoverflow.com/questions/46835811/ffplay-wasapi-cant-initialize-audio-client-ffmpeg-3-4-binaries but while this has apparently been fixed for media files containing both video+audio, the bug has now returned under a similar guise for audio-only media files; the original mitigation, to set the env var "SDL_AUDIODRIVER=directsound" still works; FWIW, this bug is NOT present under WinXP, because that OS does NOT have WASAPI; and is NOT present on FFplay builds compiled with SDL2 <= 2.0.5 (quite old by now) ...