VistaLover

Many thanks for your tests and confirmation ; with some more free time on Saturday, I decided to explore how ALL stable VLC versions after 3.0.8 behave when fed the above audio HLS live stream; one can find older stable VLC releases in their "download" server: https://download.videolan.org/pub/videolan/vlc/ FTR, v3.0.7.1 (immediately previous to 3.0.8) behaves almost identically to 3.0.8; HLS streams (at least the demuxing part) are handled by the libadaptive_plugin.dll module; here's the CPU usage history of my Core2 Duo with ONLY VLC v3.0.8 streaming BBC R2: libadaptive_plugin.dll versions 3.0.9.2 and 3.0.10 are actually BROKEN when it comes to handling the BBC R2 HLS stream; I can hear the audio for ca. 30-40s, but then the stream turns muted (continues to play otherwise) ... From v3.0.11 onwards, the BBC R2 HLS audio stream does play consistently, but at elevated CPU consumption ; with each newer VLC release, the file size of the above DLL increases, but the CPU it uses remains constantly high; below is the CPU usage history of my Core2 Duo when ONLY VLC v3.0.23 is running, streaming BBC R2: I'm sure you can see the CPU spikes there ... If you're using yt-dlp.exe without a JS runtime (quickjs is the only option under XP SP3 x86), then the default player client there is android_vr (aka ANDR-V) and the formats it returns are ALL "https", not "m3u8" (PROTO column): yt-dlp -F "ffcitRgiNDs" [youtube] Extracting URL: ffcitRgiNDs [youtube] ffcitRgiNDs: Downloading webpage WARNING: [youtube] No supported JavaScript runtime could be found. Only deno is enabled by default; to use another runtime add --js-runtimes RUNTIME[:PATH] to your command/config. YouTube extraction without a JS runtime has been deprecated, and some formats may be missing. See https://github.com/yt-dlp/yt-dlp/wiki/EJS for details on installing one [youtube] ffcitRgiNDs: Downloading android vr player API JSON [info] Available formats for ffcitRgiNDs: 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 1 | mhtml | images storyboard sb1 mhtml 160x90 1 | mhtml | images storyboard sb0 mhtml 320x180 1 | mhtml | images storyboard 139 m4a audio only 2 | 1.33MiB 49k https | audio only mp4a.40.5 49k 22k low, m4a_dash 249 webm audio only 2 | 1.46MiB 54k https | audio only opus 54k 48k low, webm_dash 140 m4a audio only 2 | 3.51MiB 129k https | audio only mp4a.40.2 129k 44k medium, m4a_dash 251 webm audio only 2 | 3.77MiB 139k https | audio only opus 139k 48k medium, webm_dash 160 mp4 256x144 25 | 1.46MiB 54k https | avc1.4d400c 54k video only 144p, mp4_dash 278 webm 256x144 25 | 1.79MiB 66k https | vp9 66k video only 144p, webm_dash 394 mp4 256x144 25 | 1.41MiB 52k https | av01.0.00M.08 52k video only 144p, mp4_dash 133 mp4 426x240 25 | 3.08MiB 113k https | avc1.4d4015 113k video only 240p, mp4_dash 242 webm 426x240 25 | 2.68MiB 99k https | vp9 99k video only 240p, webm_dash 395 mp4 426x240 25 | 2.53MiB 93k https | av01.0.00M.08 93k video only 240p, mp4_dash 134 mp4 640x360 25 | 5.77MiB 213k https | avc1.4d401e 213k video only 360p, mp4_dash 18 mp4 640x360 25 2 | ≈ 9.28MiB 342k https | avc1.42001E mp4a.40.2 44k 360p 243 webm 640x360 25 | 6.80MiB 251k https | vp9 251k video only 360p, webm_dash 396 mp4 640x360 25 | 4.58MiB 169k https | av01.0.01M.08 169k video only 360p, mp4_dash 135 mp4 854x480 25 | 9.80MiB 361k https | avc1.4d401e 361k video only 480p, mp4_dash 244 webm 854x480 25 | 9.37MiB 345k https | vp9 345k video only 480p, webm_dash 397 mp4 854x480 25 | 7.91MiB 292k https | av01.0.04M.08 292k video only 480p, mp4_dash 136 mp4 1280x720 25 | 18.56MiB 684k https | avc1.4d401f 684k video only 720p, mp4_dash 247 webm 1280x720 25 | 17.27MiB 636k https | vp9 636k video only 720p, webm_dash 398 mp4 1280x720 25 | 13.88MiB 511k https | av01.0.05M.08 511k video only 720p, mp4_dash 137 mp4 1920x1080 25 | 49.02MiB 1807k https | avc1.640028 1807k video only 1080p, mp4_dash 248 webm 1920x1080 25 | 30.88MiB 1138k https | vp9 1138k video only 1080p, webm_dash 399 mp4 1920x1080 25 | 24.70MiB 910k https | av01.0.08M.08 910k video only 1080p, mp4_dash I have found the elevated CPU usage (in v3.0.11+) to be specific to the HLS streaming protocol ... Wise choice; and you should probably stay there, too... Words of wisdom ! Kind regards (and protect yourself from the heatwave ... )

So, despite that the video itself ISN'T DRM'ed (e.g., when you watch it in FxESR-115.37.0 under Win7SP1, the DRM icon doesn't show up in the URLbar), for the embedded player to load it needs the browser to come with Widevine support, in case another video on CTVNews.ca uses DRM? This is so badly conceived ...

Thanks for this detailed info ; in case anyone wants to salvage/archive those builds: vlc-3.0.23-win32-a5b72d67 https://artifacts.videolan.org/vlc-3.0/nightly-win32/20260512-0219/ vlc-3.0.24-beta1-win32-4c608da1 https://artifacts.videolan.org/vlc-3.0/nightly-win32/20260529-0214/ It's unclear why they broke XP-compatibility in 3.0.24b1 after May 29th ; it might've been an inadvertent breakage, like they did with VLC-3.0.21, or as part of a conscious decision to drop NT 5.x support (recent 3.0.24b1 builds continue to work under Vista SP2) ; I guess very few people (especially on "legacy" WinOSes) monitor the "nightly" artifacts, so the XP-breakage, if not remedied in the meantime, will only hit the "masses" when 3.0.24 sees a final/stable release (and there's probably still time for that ) ...

The embedded video player doesn't even load in latest NM28 when one accesses: https://www.ctvnews.ca/toronto/video/2026/06/20/germany-fans-take-over-streets-of-toronto-ahead-of-world-cup-game/ TypeError: navigator.requestMediaKeySystemAccess is not a function in newrelic.js:6:8007 I had to use r3dfox (v140.0.4) to view the clip; BTW, the clip is neither DRM'ed nor geoblocked; NM28 should've worked!

Likewise under Vista SP2 x86, "portable" setup of VLC-3.0.24b1: qt debug: activating or triggering extension 'YouTube Search' lua debug: Reactivating extension YouTube Search lua: [yt-ext] platform=windows ytdlp=yt-dlp.exe lua debug: Creating dialog 'YouTube Search (yt-dlp)' qt debug: Creating a new dialog: 'YouTube Search (yt-dlp)' lua debug: Clicking 'F:\Applications\VLC Portable\VLC_3.0.24b1_Portable\VLC\lua\extensions\youtube_search.lua': 'Search' lua: [yt-ext] cmd: yt-dlp.exe "ytsearch10:Adele" -J --flat-playlist --no-warnings --encoding utf-8 lua: [yt-ext] bat cmd: yt-dlp.exe "ytsearch10:Adele" -J --flat-playlist --no-warnings --encoding utf-8 lua debug: Clicking 'F:\Applications\VLC Portable\VLC_3.0.24b1_Portable\VLC\lua\extensions\youtube_search.lua': 'Search' lua: [yt-ext] cmd: yt-dlp.exe "ytsearch10:Adele" -J --flat-playlist --no-warnings --encoding utf-8 lua: [yt-ext] bat cmd: yt-dlp.exe "ytsearch10:Adele" -J --flat-playlist --no-warnings --encoding utf-8 qt debug: Dialog 'YouTube Search (yt-dlp)' received a closeEvent lua debug: Deactivating 'YouTube Search' lua debug: Deleting dialog 'YouTube Search (yt-dlp)' lua debug: Waiting for the dialog to be deleted... qt debug: Deleting extension dialog 'YouTube Search (yt-dlp)' I can assure you that both yt-dlp.exe (32-bit) and hidecon.exe (32-bit) are sitting besides vlc.exe ...

I'm sorry to say that the same thing happens for me, too, when using a "portable" installation of VLC; yt-dlp.exe and hidecon.exe reside adjacent to vlc.exe; I've tried on both VLC 2.2.8/3.0.24b1 (32-bit) ; OS is Vista SP2 x86:

I realise VLC specifically is NOT the topic of this thread, but could you be so kind as to actually pinpoint/link to that version? On https://artifacts.videolan.org/vlc-3.0/nightly-win32/ you can see that their server retention goes back to last December, ONLY, so I expect, in the future, that older "artifacts" will be forever purged ; perhaps this last, XP-compatible, build deserves to be archived for posterity ... These recent VLC builds exhibit a very high CPU consumption on my old Core2 Duo processor when listening to radio (audio) streams using either the HLS/mpeg-dash streaming protocol, e.g. to BBC Radio 2 Live stream: http://as-hls-ww-live.akamaized.net/pool_74208725/live/ww/bbc_radio_two/bbc_radio_two.isml/bbc_radio_two-audio=96000.m3u8 I have identified the issue to be with recent versions of the "libadaptive_plugin.dll" module: .\plugins\demux\libadaptive_plugin.dll Swapping the 3.0.24 version with the 3.0.8 old one (from 2019!) reduces the CPU usage to just 25% of what the current version uses... Apologies again for the somewhat OT parts of this comment ... Best regards.

If it makes any difference, the "missing-titlebar-bug", https://github.com/Eclipse-Community/r3dfox/issues/177 https://github.com/e3kskoy7wqk/Firefox-for-windows-7/issues/147 , is caused by a change between v151.0a1-v4 (last GOOD build of the 151 branch) and v151.0.2 (first BAD build of the 151 branch); so, not that big of a "regression window" to dissect ...

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