VistaLover

... I'm trying somehow to understand, but, as a non-coder, I fail to do so ... Your previous working, FULL, FFplay.exe (32-bit) binary from early June, ffplay version N-124841-gb355200263-WINVISTA Copyright (c) 2003-2026 the FFmpeg developers built with gcc 16.1.0 (Rev5, Built by MSYS2 project) configuration: --disable-autodetect --enable-amf --enable-bzlib --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-zlib --enable-sdl2 --enable-gmp --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libx264 --enable-libx265 --enable-libdav1d --disable-debug --enable-libfdk-aac --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-libsrt --enable-libzmq --enable-libgsm --enable-chromaprint --enable-frei0r --enable-libaribb24 --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfribidi --enable-libgme --enable-libilbc --enable-libmodplug --enable-librubberband --enable-libzvbi --enable-openal --enable-libcodec2 --enable-ladspa --enable-libuavs3d --enable-libjxl --enable-libxeve --enable-libxevd --enable-libharfbuzz --enable-liblc3 --enable-libaribcaption --enable-lcms2 --enable-libdvdread --enable-libdvdnav --enable-liboapv --enable-libqrencode --enable-libquirc --enable-opengl --enable-gnutls --enable-gpl --enable-version3 libavutil 60. 32.100 / 60. 32.100 libavcodec 62. 36.101 / 62. 36.101 libavformat 62. 19.101 / 62. 19.101 libavdevice 62. 4.100 / 62. 4.100 libavfilter 11. 17.100 / 11. 17.100 libswscale 9. 8.100 / 9. 8.100 libswresample 6. 4.100 / 6. 4.100 was compiled with GCC16, was it not ? However, more recent FFplay (32-bit) builds, when again compiled with GCC16, end up exhibiting the crash-y behaviour I have reported so far; have you changed in some aspect the compiler itself (GCC16) since the start of June or are the recent crashes the result of upstream (FFmpeg) new code, that makes the final binary incompatible with NT 6.0 x86? The GCC15.2 compile launches OK here, ffplay version N-125551-ga09be9b91e Copyright (c) 2003-2026 the FFmpeg developers built with gcc 15.2.0 (Rev14, Built by MSYS2 project) configuration: --prefix=/local32 --bindir=/local32/bin-video --pkg-config=pkgconf --pkg-config-flags='--keep-system-libs --keep-system-cflags --static' --cc=gcc --cxx=g++ --ld=g++ --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int-conversion --disable-autodetect --enable-zlib --enable-sdl2 --enable-gpl --enable-libmp3lame --disable-debug --enable-libfdk-aac --enable-libass --enable-libxml2 --enable-libshine --enable-gnutls --enable-libx264 --enable-libx265 --extra-cflags=-DLIBXML_STATIC libavutil 61. 4.100 / 61. 4.100 libavcodec 63. 6.100 / 63. 6.100 libavformat 63. 4.100 / 63. 4.100 libavdevice 63. 2.100 / 63. 2.100 libavfilter 12. 2.100 / 12. 2.100 libswscale 10. 2.100 / 10. 2.100 libswresample 7. 2.100 / 7. 2.100 Simple media player usage: ffplay [options] input_file ... and I couldn't help noticing lots of "first-time-to-be-seen" configure flags : --pkg-config=pkgconf --pkg-config-flags='--keep-system-libs --keep-system-cflags --static' --cc=gcc --cxx=g++ --ld=g++ --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int-conversion As for my audio-only MP4 file, it plays there with NO crashes : So, does this mean it's goodbye GCC16.1 and welcome GCC15.2 ? (OT: the appalling forum's code viewer did push my patience to its limits, while trying to send this comment ; will it ever get fixed?)

The crash on the audio file isn't to do with it being tagged, because the crash is still invoked even without a tag (text metadata+cover): Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/mp41) File size : 39.6 MiB Duration : 57 min 0 s Overall bit rate mode : Constant Overall bit rate : 97.1 kb/s ContentType : Movie Writing application : Lavf62.6.100 rati : (Binary) Audio ID : 1 Format : AAC LC SBR Format/Info : Advanced Audio Codec Low Complexity with Spectral Band Replication Commercial name : HE-AAC Format settings : Implicit Codec ID : mp4a-40-2 Duration : 57 min 0 s Bit rate mode : Constant Bit rate : 96.0 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate : 48.0 kHz Frame rate : 23.438 FPS (2048 SPF) Compression mode : Lossy Stream size : 39.1 MiB (99%) Language : English Default : Yes Alternate group : 1 PS: The same untagged audio file plays OK with the latest n8.2-dev-2237 SHARED FFplay binary for XP:

... Well, I think I spoke too soon ; while, indeed, MP4 media files with h264+aac now don't cause an FFplay crash, a tagged (metadata+cover) MP4 file with audio-only (HE-AACv1) still leads to a crash: The same tagged audio file plays fine with previous FFplay n8.2-dev-1568 (from early June): That file was downloaded from BBC Sounds with yt-dlp (it has now expired); if it's any help, below its MediaInfo log: Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/mp41) File size : 39.6 MiB Duration : 57 min 0 s Overall bit rate mode : Constant Overall bit rate : 97.1 kb/s Title : Dance Sounds of the 90s with Vernon Kay, Party Classics With Ultra Naté In The Mix Description : Ultra Naté makes a mix for Vernon's Classic 90s Party. Writing application : Lavf62.6.100 Cover : Yes Cover type : Cover Comment : https://www.bbc.co.uk/programmes/m001yrds LongDescription : Ultra Naté makes a mix for Vernon's Classic 90s Party. Audio ID : 1 Format : AAC LC SBR Format/Info : Advanced Audio Codec Low Complexity with Spectral Band Replication Commercial name : HE-AAC Format settings : Implicit Codec ID : mp4a-40-2 Duration : 57 min 0 s Bit rate mode : Constant Bit rate : 96.0 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate : 48.0 kHz Frame rate : 23.438 FPS (2048 SPF) Compression mode : Lossy Stream size : 39.1 MiB (99%) Language : English Default : Yes Alternate group : 1 Image Type : Cover Format : JPEG Muxing mode : moov-meta-covr Width : 1 200 pixels Height : 675 pixels Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Compression mode : Lossy Stream size : 104 KiB (0%) This is turning into a nightmare ; thanks in advance for any insight...

Thanks a lot for recompiling ; I've downloaded and tested the new n8.2-dev-2273 VISTA binaries and can confirm the new FFplay.exe files work as expected : If it's not too much to ask , can you share what the issue was with the previous FFplay offering?

... But as I had pointed out here, your sample Polish radio stream still works in plain HTTP mode ... I never, for the life of me, understood WHY rich media content (streaming video and/or audio) has to be served over HTTPS ; this isn't about security at all, it's not like we're dealing with financial transactions where highly confidential/sensitive data/details are involved... The culprit, once more, is Google and their web-dominating browser, Chrome ; Chrome was the first browser/engine that disallowed the delivery of "mixed" content inside a page (with the known "mantra" of doing so to protect their users from on-line fraud), i.e., if the webpage has been loaded through HTTPS, likely to be a media service's web-player containing page, then the video/audio content inside the web-player HAS to be streamed over HTTPS, too, because otherwise Chrome would block it; thus, the media CDNs are now forced to stream via HTTPS, adding (practically) unnecessary TLS overhead (more easily perceived on old H/W) to the viewing/listening experience ...

@j7n are adamant on NOT using an extension-based adblocker (e.g. uBO) in the browser, because they harbour the conviction that such an extension would considerably impede their browser's performance ; in the past, both myself and other members here have suggested to them the installation and use of uBO, but they still think that their old ways of dealing with ads (blocking "known" ad-serving domains in their HOSTS file) is still sufficient/effective in the web-ecosystem of 2025+ ... Is this on a UXP-based browser (the object of these megathreads) ? Because if you're talking about recent Chromium/Firefox, these now come with built-in ways of dealing with (some of the) unwanted content ...

Thank you once more for these new releases ; however, I have to report that the latest ffplay.exe compiles for Vista x86, BOTH the static+shared binaries, are completely broken under Vista SP2 x86 (with ALL MS updates until EoS, and then some ); whatever media file you throw at FFplay.exe (e.g., via drag-n-drop) results in the app instantly crashing; below, an instance of a plain MP4 file containing h264 video + aac audio: Your previous VISTA release works as expected with that same MP4 file: FWIW, your latest FFplay.exe static compile for WINXP doesn't suffer from this issue and plays the MP4 file without any problem: You'll probably need a Vista SP2 x86 VM to troubleshoot this, as I have no clue as to what might have gone wrong; perhaps an updated third-party lib has in the interim (n8.2-dev-1568...n8.2-dev-2232) removed support for NT 6.0? We know it's not caused by upstream (FFmpeg source code), because your n8.2-dev-2232 compile for XP works OK; in addition, when I probe the MP4 file with latest FFmpeg for VISTA, it doesn't crash: ffmpeg version N-125505-gc57660fb18-WINVISTA Copyright (c) 2000-2026 the FFmpeg developers built with gcc 16.1.0 (Rev5, Built by MSYS2 project) configuration: --disable-autodetect --enable-amf --enable-bzlib --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-zlib --enable-sdl2 --enable-gmp --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libx264 --enable-libx265 --enable-libdav1d --disable-debug --enable-libfdk-aac --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-libsrt --enable-libzmq --enable-libgsm --enable-chromaprint --enable-frei0r --enable-libaribb24 --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfribidi --enable-libgme --enable-libilbc --enable-libmodplug --enable-librubberband --enable-libzvbi --enable-openal --enable-libcodec2 --enable-ladspa --enable-libuavs3d --enable-libjxl --enable-libxeve --enable-libxevd --enable-libharfbuzz --enable-liblc3 --enable-libaribcaption --enable-lcms2 --enable-libdvdread --enable-libdvdnav --enable-liboapv --enable-libqrencode --enable-libquirc --enable-opengl --enable-gnutls --enable-gpl --enable-version3 libavutil 61. 2.100 / 61. 2.100 libavcodec 63. 5.100 / 63. 5.100 libavformat 63. 3.100 / 63. 3.100 libavdevice 63. 2.100 / 63. 2.100 libavfilter 12. 2.100 / 12. 2.100 libswscale 10. 2.100 / 10. 2.100 libswresample 7. 2.100 / 7. 2.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Mastermind_Se8Ep12[2494504515559].mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf62.13.101 Duration: 00:25:41.93, start: 0.000000, bitrate: 968 kb/s Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(progressive), 768x432 [SAR 1:1 DAR 16:9], 837 kb/s, 25 fps, 25 tbr, 90k tbn (default) Metadata: handler_name : VideoHandler Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 125 kb/s (default) Metadata: handler_name : SoundHandler At least one output file must be specified Hopefully you'll be able to get to the bottom of this, as I do use FFplay.exe myself under Vista SP2 (32-bit) ; thanks for all your hard efforts already!

The same stream is available through plain HTTP, http://paranormalium.waw.pl/radio/8000/mp3_48 so you can use that with an FFplay compile without HTTPS support built-in ...

... But the author has already mentioned that : The community of XP-using members here has to reach a consensus as to what should be the minimal configuration of the FFmpeg/XP compiles, so that autodidact doesn't have to jump through hoops to try and satisfy each and every one of you ; remember, this most kind person is offering an invaluable service out of the goodness of their heart ; compiling binaries is a time and CPU (read: electricity) consuming convoluted process...

Many thanks @Reino for updating your forum signature, now being "My fileserver" ...

That suggestion works fine here with WGET (the forum's faulty software wouldn't let me put below content inside "code" tags ):

This URL is no longer valid ; try the one below: https://board.eclipse.cx/viewforum.php?f=33

Exactly! I still keep a portable installation of Mozilla Firefox 52.9.1esr (the last to officially support XP/Vista) for "nostalgia" , and while it's still able to render many sites, it is forbidden to do so because it can't pass/complete CF and/or Anubis anti-bot challenges "protecting" those sites (even old-type ones, like "https://forums.mozillazine.org/viewforum.php?f=38") ...

Your signature ("My hobby website") still links to http://rwijnsma.home.xs4all.nl/ (this now, as announced, redirects to https://notxs4all.home.xs4all.nl/ which states: ) ; would you please consider updating that reference, too ? Many thanks for the new mirror, BTW ...

Go back some pages in this thread and you'll find this was a request from several of your XP co-users (aka XP "die-hards"), either complaining about the inflated filesizes of the static executables (hence the "death" of the static "ffplay.exe") or stating they have absolutely no use for FFplay: No, never. I have always double-click .mp4 and is opened in VLC to watch everything and I don't need anything else. I no need scripts for download @AstroSkipper, do you now get the picture why 1) static FFplay.exe was completely dropped 2) the FFmpeg+FFprobe compiles for XP are now built with only minimal support for codecs/muxers/filters etc. ? autodidact is not to blame for that; he just provided what "the popular demand" is for ... Later on, as a courtesy, he added an FFplay shared build ONLY, again with just basic libs, for those (few?) XP users wanting to make use of it: https://msfn.org/board/topic/184368-who-here-has-a-youtube-dl-compile-for-winxp/page/45/#findComment-1288102 More references of mine: https://msfn.org/board/topic/184368-who-here-has-a-youtube-dl-compile-for-winxp/page/45/#findComment-1288026 https://msfn.org/board/topic/184368-who-here-has-a-youtube-dl-compile-for-winxp/page/45/#findComment-1288100 Kind regards.

... But he specifically mentions pirated Win7 versions as prone to such "bricking" : (machine translation from Russian)

... OK, I found some related info over here ; but then, why would MS claim for "EventSetInfomation" to be a Win8+ function?

Because you shouldn't hit ENTER right after typing "qjs"; to get the help details for the app, type in the Windows Cmd Prompt "qjs -h" and then hit ENTER: 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 (apologies for the accidental submission of an incomplete post)

According to Microsoft, this is a Win8+ specific function: https://learn.microsoft.com/en-us/windows/win32/api/evntprov/nf-evntprov-eventsetinformation#requirements Are you sure about your assessment?

My own test results under Vista SP2 32-bit, Core2 Duo of 2008 era; VLC-3.0.24b1 (32-bit) "portable"; entering "Adele" as the search term and clicking the "Search" button, a cmd prompt window flickers for a fraction of a sec, then 10 search results finally appear, while at the same time I get a small pop-up window (with a rolling progress bar) informing me that the extension is NOT responsive and asks me whether I want to terminate it now: If I click "Yes" (Ναι), the pop-up disappears and I'm left with just the 10 search results; if I then click the "Load Rec" button, the search GUI hangs (Not Responding) and when trying to close the Search Window, the OS informs me that VLC is not responding and (practically) all I can do is just close it... If I don't click the "Load Rec" button but click any of the 10 search result buttons, again I soon get a GUI hang, which leads to full app hang, too ... In a nutshell, some improvement over the previous iteration of the script, but still not the desired/expected behaviour ...

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