VistaLover

... Apologies for bringing this up, but was any further (security) update released for Chrome v109 on WS 2008 R2 after last October's release, v109.0.5414.168 ? Thanks in advance for any info ...

... And where one would put the chairs? All in jest, as you said , it's quite obvious you intended to type "tabs" there... Take good care ...

... On Windows < 8, Supermium (Sm) has issues correctly rendering woffs (remote/web fonts) on web pages (in addition to emojis, which, unlike in Mozilla apps, seems to be a Chromium-specific issue ); you may need to install additional fonts in your Vista machine and/or use an extension for emojis; or you could try enforcing the GDI font rendering flag; some relevant GH issues: https://github.com/win32ss/supermium/issues/227 https://github.com/win32ss/supermium/issues/143 https://github.com/win32ss/supermium/issues/138 https://github.com/win32ss/supermium/issues/134 https://github.com/win32ss/supermium/issues/69 https://github.com/win32ss/supermium/issues/33

... But these two are supposed to really make a difference (i.e. considerably reduce RAM usage on XP) ONLY where the VC++2015-2019 redistributable (the last XP-compatible one was v14.28.29213.0) is already installed : https://github.com/win32ss/supermium/issues/235#issuecomment-1925433278

... For people on WinXP SP3 "trialing" the latest Sm-121-hf x86 release, win32 is kindly providing recompiled+rebased versions of files: that will reduce excessive RAM usage by the browser on pre-Vista OSes: https://github.com/win32ss/supermium/issues/204#issuecomment-1924048080 https://github.com/win32ss/supermium/issues/204#issuecomment-1924437338 https://github.com/win32ss/supermium/issues/204#issuecomment-1924647139

... As I and several others already wrote, that WidevineCDM dll requires Win7SP1+ functions to run; even on Win7SP1+, the CDM won't properly work on many "popular" DRM'ed services (Netflix, Spotify, hulu, etc.), because those sites demand its VMP (Verified Media Path) feature, but open-source (non-mainstream) implementations like Supermium aren't being sanctioned by Google for that purpose... https://github.com/win32ss/supermium/issues/169#issuecomment-1901651703 https://github.com/win32ss/supermium/issues/127 https://github.com/win32ss/supermium/issues/61

https://github.com/win32ss/supermium/issues/199

... For future references : https://wiki.mozilla.org/Firefox/CommandLineOptions and... https://wiki.mozilla.org/Firefox/CommandLineOptions#-purgecaches

... Yes, I was quite vexed myself when I read those "speculations" by "you-know-whom" MCP dev, interspersed with additional insults against "this" community here; that dev seems to know very little about "our" apps other than the fact they work on XP/Vista, too; this "our version of UXP vs theirs" argument sounds like a broken record by now; the differences are well defined and known by most members here, but, apparently, not by upstream; NM28, a fork of official PM, doesn't support WEs, so how could it have been that Astro's version implements WebEx features "they" don't implement? Once more, "they" are very quick to cast a stone upon "us" and actually did what they, in the recent past, accused us of doing: blaming the other party "out of habit" ... In his last paragraph, that dev tries to "soften" his criticism, I'll give him that, but then "father" MC himself intervenes to restore the "status quo"; how hypocritical (on all of them) to speak about "that level of hostility towards our (their) projects", when it's the years-long "treatment" they've been giving us to this day ... (Going to make myself a cup of hot chocolate now, with extra sugar added, to alleviate all that, unfortunate, bitterness disseminating from that "other forum" ) AstroSkipper: This whole situation surrounding your uBO efforts brings to mind the English saying: "No good deed goes unpunished", wouldn't you agree? Kindest regards

The off-line variety should've been downloaded ... https://cdn.epicbrowser.com/v120/mini_installer.exe And, this is just an educated guess , Epic-120 should require at least Win10 ... EDIT: There has been info by another member that, in fact, it does launch under Win7 ...

... FWIW, this very same bug can be observed in the latest St55 (32-bit, buildID=20240125063308) ; I suspect the "fix" is similar, at least according to: https://github.com/roytam1/basilisk55/commit/323bda6dcc13f3875ef36bbce15b59107ac0f09e BTW, I haven't updated my daily driver, St52, but I expect the bug to be there, too, since it affects ALL UXP-based apps ...

... OT : This simple MUC search doesn't tell the whole story : https://support.microsoft.com/en-us/topic/windows-installer-4-5-is-available-bf06be18-3e0a-d5eb-4549-b482f67e1c46 https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Msi/windows-installer-redistributables.md (TL;DR: KB942288 is Windows_Installer-v4.5; redistributables existed for XP SP2/3 through to Vista SP0/1 - and their Server counterparts ; existed, because now evil MS have removed them from the Download Center )

... Er, you might want to correct that LINK of yours there (I'm reading this "heated" thread today, on a Sunday, so just stumbled on that) ...

... You do have DRM-enabled web browsers under Win7+, but NOT for that long ... Google own the Widevine CDM (blackboxed, closed-source module that deals with DRM decryption) and while themselves have stopped supporting Win7/8/8.1 in their main browser (Chrome), they have prolonged Win7 support in the CDM because their sidekicks, Mozilla, still support those OSes in their Fx115esr branch (until autumn this year?) and, guess what, that branch still ships with a version of Widevine CDM (licenced by Google) that should work on those OSes - after Mozilla drops Win7/8/8.1 support, all bets are off... Win7 will inevitably become like Vista SP2, where the CDM doesn't work at all in any supported browser, so all those "compatible ones" will cease working then ...

... A tiny bit OT , but could you be so kind as to disclose some additional details about this M108 Chromium fork? Is this something that needs OneCore API installed, hence making it an XP SP3 exclusive "option" ?

... When an extension provides its own "update URL" (inside its install.rdf file), this takes precedence over the "default" updating process by the browser the extension is installed in ... IIANM, uBO "beta" (as in 1.16.4.31b2) updates itself via "GitHub", so you just removed that update pathway... If you pay more attention at @Mathwiz's post, he wrote: (AMO: addons.mozilla.org); this update pathway is controlled by the browser itself (NOT by the extension) and it's realised by the browser "querying" (at set intervals) the default extensions repo (AMO in the case of St55) for an updated, compatible, version of all the already installed extensions - this function is controlled in St55 by below about:config pref: extensions.update.url;https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=55.0&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% and since, as you hinted, uBO-legacy and uBO-WE have the same extensionID, the browser can and will update it, eventually, to the compatible, WE, version extant in AMO... Kindest regards. PS: UXP-based browsers have cut all "ties" to AMO, which is currently hosting only WEs, thus this issue can't be witnessed in St52/NM28/etc. ; but, "we" do have, few as they may be, dedicated St55 users here ...

This is just a technicality, but youtube-dl NEVER "officially" dropped Windows XP SP3 support; the python script itself, to this day, remains compatible even with such an old CPython version as py2.6 and py3.2 (!), though, for best results under XP, CPython 2.7.18 (EoS for that OS) and CPython 3.4.10 (EoS for that OS) should be used... The provided, standalone, Windows executable youtube-dl.exe, has been historically compiled with the py2exe Python module and comes bundled with CPython 3.4.4 32-bit (WinXP SP3, SSE+ compatible). In the case of yt-dl, "official" is open for interpretation, because the team of devs behind https://github.com/ytdl-org/youtube-dl and the last "stable" release https://github.com/ytdl-org/youtube-dl/releases/tag/2021.12.17 retired (read: abandoned the project) a few years ago, but that same repo is under new management currently (ownership transfer) by, sadly, only ONE maintainer, @dirkf, who vowed to keep support for older python versions (and, by association, older WinOSes like XP/Vista ). The new maintainer doesn't believe in a "stable" releases scheme and has instead opted to adopt a "nightly" releases scheme, to be found under: https://github.com/ytdl-org/ytdl-nightly/tags The binaries there are compiled from source code of the original repo, thus I do still consider these releases as "official", i.e. they're NOT FORKS ... In closing, if you'd allow me to be somewhat pedantic , the XP-compatible builds of yt-dlp.exe most kindly released by nicolaasjan to this community wouldn't be a thing if it weren't for cmalex, who compiled himself flavours of CPython 3.8.x/3.9.x that will launch under XP - so, IMHO, he, too, deserves some credit! ...

Thanks ; the "issue" and its workarounds are documented in https://github.com/MrS0m30n3/youtube-dl-gui/issues/249 https://github.com/MrS0m30n3/youtube-dl-gui/issues/65

They're NOT there by default, even if one goes with the "portable" package... That one still creates a "youtube-dlg" directory in my "Roaming" Windows profile (%appdata%\youtube-dlg), with a "settings.json" and a "log" file in it, where a recent version of youtube-dl.exe should reside ... FYI, a fresh "install" of the app now won't fetch the youtube-dl.exe binary by clicking "cog wheel -> Update", because the old hard-coded URI no longer works ... BTW, if you want mp4/m4a files to be properly tagged, you also need a compatible AtomicParsley.exe 32-bit binary... Perhaps @AstroSkipper is willing to share some extra configurations needed for the app to recognise youtube-dl.exe/yt-dlp.exe extant inside those (manually created) additional directories ...

... The bitness of that executable isn't the only issue with it, apparently ; this PyInstaller-compiled binary has been bundled with py3.10, it seems ... One might check its requirements/dependencies to see if they support py3.8 and then, perhaps, attempt to compile a 32-bit executable based on the py3.8.13+ custom compilation that's used to provide yt-dlp_x86.exe for XP... Though, I suspect, this won't be an easy task for anyone who tries that ... This is, ofc, better suited into a more specific thread, I've gone OT already, am afraid ...

... But I did tell you so : CLI = Command Line Interface Both apps will try and use ALL the DL speed your line will allow for (provided they're updated so they're not throttled by most evil Google ); yt-dlp also comes with the "-N x" option (multi-threaded, aka parallel downloading for the same clip). One can always download the latest (nightly) release from GitHub: https://github.com/ytdl-org/ytdl-nightly/releases/tag/2024.01.23 (you need the .EXE) Those dropbox links may eventually expire/return a 404 in the future, and this is beyond @nicolaasjan's control, unfortunately ... ... Well, why would that happen anyhow (is your H/W failing?) ? TBH, problems inside your browser (St52 in this case) shouldn't be immediately associated to the OS itself, but I could be wrong ... There's infinite documentation online to "get used to" , e.g. https://www.indeed.com/career-advice/career-development/how-to-run-program-in-command-prompt Personally, I'd feel "crippled" if not able to run CLI apps on this old Windows laptop (as CLI apps often require fewer system resources ) ...

... Launching your browser in a new, pristine, profile is an essential troubleshooting procedure and I'm dead certain details of the "How-To" have been already mentioned several times across the lifespan of these threads (now in "Season 05" ) ... Please make a sincere effort to get yourself acquainted with it ; the knowledge-base article I'll link below speaks of Mozilla Firefox, but it can be applied to St52/St55, too: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles https://support.mozilla.org/es/kb/usar-el-administrador-de-perfiles-para-crear-y-eli Backing up your dirty profile from time-to-time is always a good precautionary measure against profile corruption/loss/inadvertent unwanted modification ; you can get access to your profile's contents via: MenuBar -> Help -> Troubleshooting Information (aka about:support) -> Profile Folder -> Open Folder (button) Running too many content blockers is NEVER a good idea, not to mention it increases your browser's RAM consumption; as I've written recently, I'm ONLY running myself uBO-legacy (I haven't had any adverse effect till now), while testimonies of successfully running uBO+ηMatrix are frequent here ; make a choice between uBO and ABU and lose one of them ; less is more! (my 2c, ofc ...) youtube-dl.exe and yt-dlp.exe are standalone CLI (no GUI) executables that don't require any installation and don't "mess" with one's system; in their default configuration, they'll write some minimal detail inside your Windows profile, but they can also be configured to be "truly portable" by loading a config file adjacent to the executable itself! TBH, I'm a bit surprised you hadn't yet come across them during your quest for YT downloaders, as these apps are well-known/popular in this retro-computing community ... Best regards .

¡Hola! It would've made things easier for any troubleshooter to also post links to the actual YT video(s) you're having trouble with ; in any case, the one depicted in your attachments appears to be: https://www.youtube.com/watch?v=VIEQCxpMdDY Having now updated to the latest St52 release myself [v52.9.0 (2024-01-18) (32-bit)], I tried your YT video with the "y2mate" service, and have found it to behave as expected (in my current, "dirty", profile at least) : I had a similar successful result when I tried the same video with the second, "GenYT", service; after the YT video player had fully loaded, I pressed the red "Generate Download Links" bar and then : (success with that service - but with a different YT video - has been already confirmed here ) I know I'm not being helpful enough, but the standard troubleshooting procedures should apply in your case, too... 1. First, try to reproduce in a fresh St52 profile; if all's OK, then 2. Launch your dirty profile in Safe Mode - do note that if you have NoScript installed, uninstall it fully because it might still interfere even in Safe Mode. If the problem isn't observed in SM, one of your extensions/extension setting(s) (in your dirty profile) is interfering with those two sites - the problem may have become evident just now, due to core browser changes (or, even, site changes) ... 3. If the problem is observed even in Safe Mode (with NS fully removed), then one (or more) of your custom "about:config" settings is to blame for the breakage... In the unlikely event you can reproduce the "issue" even in a FRESH St52 profile, then both I and AstroSkipper have custom settings that make these sites work in our dirty profiles - or something else is happening at your end ... I've stopped using "online-video-downloaders" years ago; they come and go as the wind blows ; Google is always after them (and, in the case of copyrighted music content, the RIAA and similar), many first download the selected media content to their own servers and then the user has to fetch from there, and to fund their services they often use aggressive advertising and/or crypto-mining ... For YT (and other media portals) I exclusively use youtube-dl and/or yt-dlp (standalone CLI apps built on Python); the first has (nightly) releases still supporting WinXP, while the second one (which is more feature-rich) has unofficial WinXP ports; use the Forum Search to learn more ) ...

... That script (the actual JS code in it) first surfaced one year ago, in the PMForums: https://forum.palemoon.org/viewtopic.php?p=235705#p235705 by member @adoxa ; I have no way to tell whether both (different forum) usernames belong to the same person ; it was MSFN I originally copied it from, but later traced its origin to the "upstream" forum... And a word from Discourse admins regarding them blocking UXP-based browsers (and how, down the line, the userscript circumvents that block): https://meta.discourse.org/t/browser-detection-script-only-malfunctioning-on-pale-moon-32-x/273848

... And this causes a slight inconvenience in that portions of content (e.g. in the last posts before the lock) can't be properly quoted via the forum's native "wizard" ; so, bear with me while I use "plain" quote boxes below ... @adata wrote here: I wrote here: It turns out that https://community.openstreetmap.org evades the suggested uBO custom filter because they're NOT serving their script from an "assets" subfolder, but rather from an inconspicuous, at first unrelated, "brotli_asset" subfolder : https://community-cdn.openstreetmap.org/brotli_asset/browser-detect-99f42f91bffa8ca1606d62b70bb92f981d83921e78ccdbd3d9538f07007f27ac.js A much wider RegExp in the suggested custom filter will also catch that "naughty" forum: ! Discourse-based forums ||*/browser-detect-$script,important (but an inadvertent breakage might be caused to some other random site, hard to tell ...) @mina7601 wrote here: You're welcome , but I snitched it from here ...