VistaLover

Greetings to all MSFN staff ; as other members have commented elsewhere, the MSFN forum has been flaky/erratic , at least for the past two weeks or so; the issue is more pronounced during night time in my time zone (CEST+01:00); according to a recent post by @Dave-H , this is due to constant bot attacks to the forum server, and the only person with direct access to the server itself, @xper , is on a (much deserved) summer vacation currently; I'm not 100% certain the issue I experience can also be attributed to the bot attacks, but here it goes: Below is a screencap of my MSFN account's notification settings: As I hope you can see for yourself (imgur has been reported to have some accessibility issues in some parts of the rest of Europe, but works fine here in Greece otherwise), the e-mail option has been enabled by me for all types of MSFN notifications; this accommodation has worked fine for me until (and including) July 28th 2026; the last e-mail notification I've received from MSFN was on 23:33 (UTC+03:00) : Then... NOTHING! When I log-in to my MSFN account in the browser (r3dfox-140/New Moon 28), the "Notifications List" appears to still work, with a visible alert of new notifications in the relevant button; below, a screencap taken yesterday (July 30th): I received no e-mail about those 3 notifications ; and the same thing continues for a third day in a row; one more notification today, for which I received no e-mail: So, this is something that, obviously, won't go away by simply waiting for it to rectify itself , hence this report ... TTBOMK, nothing has changed with regards to my e-mail address since July 29th, it continues to function OK for every other task I use it for, including getting email notifications from other forums/services (e.g. GitHub) ... FWIW, I've had the same issue occur to me once. maybe twice, in the past; I'd let one whole day go by without e-mail notifications from MSFN, then my course of action was to a) sign-out of my MSFN account b) clear all MSFN-related browser cookies c) clear browser cache d) restart browser e) sign-in to MSFN account anew f) navigate to https://msfn.org/board/notifications/options and re-affirm (un-tick/tick back) my e-mail related preferences; then, e-mail notifications would start arriving fine again, as before; I've tried that same procedure numerous times yesterday, but to no avail (as detailed, no e-mail even for today's 1 notification browser alert); any help would be much appreciated; MSFN e-mails for me constitute a form of MSFN archival (for when the forum goes off-line) and an easy way to search (within my e-mail client) for interesting members' posts inside threads I've subscribed to; so, I wouldn't want to miss this "precious" forum feature ... Kindest regards.

@kiza124 Perhaps below article is relevant on Win11 : https://www.ssl2buy.com/wiki/how-to-fix-unknown-publisher-warning Was that even on Win11 ? AFAIAA, roytam1 does not digitally sign his browsers' executables with a proper file signature; and, if you used a browser under Win11 to download, then the downloaded file should contain an Internet Zone file stream, enough on its own to trigger the security warning under Win11... PS: In New Moon itself, I've always set "browser.download.saveZoneInformation" (from default 2) to 0, to get rid of that file stream ...

https://github.com/e3kskoy7wqk/Chromium-for-windows-7-REWORK/issues/65

@Dave-H ; Would it be too much to ask if I kindly requested that ALL these recent OT posts about image-pasting+posting in the MSFN forum editor be moved to a topic of its own under: https://msfn.org/board/forum/23-site-amp-forum-issues/ ? This, practically dead, thread is not apt for such an issue, it'd be more visible in a "proper place", should other MSFN members with uBO configuration similar to NHTPG's experience the same predicament... Thanks!

Well, the flags are back for me now ; and so is the "Country" tab (last one, under "Apps") in my account settings! Confirmed! I didn't neglect to hit the blue "Save" button and, for good measure, I signed-out and then signed back in ; but the flags do persist when that setting has been disabled... Since I do like the flags to be displayed, this is a non-issue for me ...

Well, I hate as much as anyone to be a PITA , but, again, a member's country flag has gone AWAL ; things look more ominous now, because, unlike on the previous time, there's no sign anywhere of a member's country of origin in the form of even a tooltip (see the screenshot in my previous post); going to my MSFN account settings, https://msfn.org/board/settings/ I no longer see any setting related to "my country and/or my country's flag" ; is this now completely gone?

Since CIS 12.0.0.6870 is also the last compatible version with Vista SP2 x86, I, too, have a vested interest in obtaining the off-line installer for that version ; a quick search led me to https://forums.comodo.com/t/how-download-full-installation-of-older-versions-cis-official-links-wrong/320847 but, sadly, the Internet Archive hasn't salvaged it (they only have v12.0.0.6882, the one after it, which is Win7+ ); other archiving services don't seem to have it, either ... Will you be willing to share a download link? And will you be disclosing any info about the needed "medications" to "resuscitate" it ? Thanks for your time and efforts ...

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