VistaLover

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

Please, to avoid issues with "upstream" developer(s), always refer to the browser as Serpent 52; as already verified by another member, I, too, have no problem at all "fullscreen-ing" video content from banbye in my St52 copy: As you can expect, I do not have an account with banbye, so can't check whether what you report is specific to logged-in users of that video portal ... In general, site/player preferences are being stored inside browser and/or HTML5 cookies; I'd start by fully wiping out ALL banbye set cookies, clear the browser cache and restart browser - often times, a user setting (e.g. inside a content blocker like uBO, uMatrix, etc.) will block a site from writing/modifying needed cookies and thus site functionality will be impaired... I'd suggest to you to try the banbye site (its new iteration) in a fresh St52 profile and draw conclusions from then on ...

... That post is quite old by now ; the UXP-based browsers now are fully equipped with all the necessary plumbing (JS features) to fully support discoursed-based forums (their "full" version, not the "dumbed-down" one targeting unsupported browsers); however, their browser-detection scripts fail to recognise UXP-based browsers as "supported", so those sites offer to them that "simplified" version ... Some weeks ago, I had answered that same question posed by j7n but he didn't opt to apply my suggested solution, because it involves an adblocker extension (uBlock Origin legacy) and he did not want to install it himself, because a) he had already other arrangements in place to thwart ads b) he feared that installing that adblocker would, somehow, compromise the quality/speed of his browsing... Here at MSFN we are a democratic community, so I respect his reservations ; this doesn't mean others are discouraged from acting differently ... If one has already installed uBO, a custom filter can be added to block the script discourse-based forums serve to sniff browsers: ! Discourse-based forums ||*/assets/browser-detect-$script,important That should be added in the "My Filters" tab... OTOH, if you have a userscript manager installed (usually their names end in "*monkey" ), you can add a custom userscript like the one below: // ==UserScript== // @name CSS aspect-ratio [88] - Discourse Forums // @version 0.0.1 // @match *://*/* // @run-at document-start // @grant none // ==/UserScript== !function() { let CSS_supports = CSS.supports; CSS.supports = function(a) { return a === "aspect-ratio: 1" || CSS_supports(a); } }() This userscript doesn't block the browser-detecting script, it simply tells it that the feature it's looking for exists in the browser (it doesn't, as of now, in reality, but it isn't needed either for properly displaying those sites) ... So, @adata, you're being offered two current solutions for properly displaying and using ALL the discourse-based forums (not just the three you referenced in your post ) ... Best regards ! EDIT: If you're NOT running a recent version of Serpent 52, please DO update, preferably to this weekend's release!

Raise your hand anyone if you think below announcement is just a coincidence : https://forum.palemoon.org/viewtopic.php?f=5&t=30782 (I mean, do you see the "double standard" there? When he was referring to the users of "the forks" as "beta testers", his tone implied a negative connotation for the term; now, he's in need himself of "beta testers" for his own "official" browser, in which case those "testers" are a "good thing", of course ) ...

Something wrong there in your URI pasting ; for those that do want to read that patronising post, the link is: https://forum.palemoon.org/viewtopic.php?p=247714#p247714

I won't even bother falling into that "trap" and start commenting on it ; "The MSFN-type people" ? WT...? My little faith towards reconciliation has just evaporated ; back to your positions, "MSFN-type people", we're again back to "square one", otherwise put: The old SNAFU... A great pity, though ... If inactive for a large amount of time, your PMForums account will be, eventually, purged, but I don't think you'll lose any sleep over that, will you? ...

... ... Well, when basilisk-dev first went "public" here, he outlined his "intentions" in a crystal-clear fashion that I immediately understood and respected ever since; to summarise, off-the-top-of-my-head: 1. He is NOT inclined to support any other Windows OS beyond what the official UXP platform supports (currently, Win7SP1 and up; though, if I were to rekindle past debates, MCP had declined back then to extend UXP support to Vista (NT 6.x family) because the vendor (Microsoft) had, at the time, just ended Extended Support for it ; where does Win7 stand now?) ... 2. His support is ONLY limited to the official (stable) Basilisk binaries he himself compiles and publishes. 3. The main - but NOT exclusive - channel to reach out to him for support, with 1+2 above still being honoured, would be the PMForums dedicated Basilisk subforum . To the best of my knowledge, I have never gone against his wishes, so whatever "infuriation'/bitterness he tried to vent "there" doesn't touch me in the slightest... Additionally, 1. Whether basilik-dev doesn't want to be forewarned about potential bugs in the platform (UXP) his own application builds upon is his own prerogative (though slightly unfortunate, if my personal opinion was queried) ; it's basically the platform's master branch that we, fork users, get first to be exposed to; I think there's a misinterpretation of incentives plaguing the MCP camp: since when is "potential" bug reporting equal to "blaming us for them (the bugs)" ? My impression still is that any bug reporting (on any project) isn't meant as an accusation, rather as an attempt for betterment - I do file many bug reports on many open-source projects, when I sometimes happen to be in error (yes, I do ), the project's maintainer just labels my bug report as invalid (and usually explains why that is so), but never jumps onto accusations/name calling against me... 2. The "tagging" basilisk-dev part: Well, I did recently tag him myself, but it was only after a bug initially discovered in Serpent 52 was found to be reproducible in the latest official Basilisk binary, run on a sanctioned OS: I was hoping an acknowledgement of this bug (the "dropbox" one) would come from basilisk-dev that would have put things in motion towards its hopeful resolution by "upstream", but so far nothing of this sort has happened; was I in error to "tag" him about it (since the bug is present, too, in his own binaries)? I honestly don't think so... 3. ... As things stand, and that's already common knowledge to members here that read Roy Tam's weekly "release notes/changelogs", basilisk-specific code from here is only sparingly+selectively copied over to Roy's UXP-custom-branch; in fact, more often than not, his changelogs state: So I don't really see what that "Basilisk master branch" argument was about ; and, honestly, were you really "flooded" with unjustified reports about official Basilisk from St52 users, as hinted? Or was it, like, once or twice by some misguided St52 users who ought to have posted here but didn't even bother to search for "here" at all? In conclusion: I don't think I, personally, owe some form of apology to basilisk-dev for any wrong-doing; his post in the PMForums thread I'll describe as mostly emotionally-charged and/or somewhat biased ... Disclaimer: My views here reflect only me, personally, not MSFN as a whole or Roy Tam in particular... Kindest regards, a "happy" alpha-tester ...

...The "magnifying glass" icons in the column headers open popups that can be used to locate specific filterlists (via their name/description); the "funnel" button on the "software" column can be used to filter based on adblocker used; filtering for "Easylist" and (software) "uBlock Origin" gives me the "Easylist (Optimized)" FL (that I mentioned previously) as the third entry in the second results page:

... Er, that's just typical ol' Moonchild there , not surprised or impressed... That's why I specifically cited martok (the author of the code involved) as the person to be contacted, NOT MC... In any case, I don't feel guilty myself of proposing something "inappropriate", nor should @UCyborg apologise for his intervention (and his wording, in all of his posts in the linked PMForum thread, was very civil and to the point ) ... In fact, MC was ready to "wontfix" UXP#2452 (based solely on the unwarranted use of NoScript involved), so I just thought, out of genuine consideration in the broader term, that the case of "https://www.theregister.com", which never surfaced among the MCP discussions, be brought to martok's attention, too... Hang me in the town square, won't you? ... A simple yes or no, "thanks for letting us know", from their side would have sufficed... But, perhaps I'm being too naive... Any impartial by-standard will admit that "us" here act, in an indirect way, as α-testers of upstream's UXP master branch, as being the first to be more widely exposed to that code, despite "our" tree's divergence from "official" UXP; this view is, actually, shared/recognised by @dbsoft in this post ; mind you, MC had himself abolished PM's unstable branch/releases some years ago, because very little of his target audience actually used them and reported existing bugs ... And, FTR, I, personally, don't mind being "a guinea pig" ; no-one forces me to update every single weekend (I usually just update once a month or when important webcompat fixes arrive), and before ever updating, I always take a back-up of my current "dirty" profile, in case things break (extremely rarely); going back to a previous build is "a piece of cake" under that scenario ... ... I have always suggested that (even very recently, read this regarding the "dropbox" UXP bug, still "a thing" with official apps, too), but it was NOT feasible in this case because martok's code wasn't present in the latest official "stable" binary releases - I, and I suppose most here (excluding you ), wouldn't be able to compile that "upstream" sourcecode and test that URL on the resulting binaries... Focusing on just "the issue itself", martok responded here that he's unable to reproduce; so, was, in the end, the "www.theregister.com" induced crash in xul.dll (before the fix) particular to "our own" tree? In any case, martok has now prepared UXP#2459 and MC is probably OK to merge it, so all this discussion will become moot... ... Pardon me for asking, but do you think there will ever come a time when some bridges could be built between the two "communities"? We now have @basilisk-dev gracing us with his presence here (but, strictly speaking, not a member of MCP ), plus at least two MCP members are now members here (with different usernames), with at least another one silently following this thread (by his own admission) ... I'm not sure if it was just pretense, but MC seems to still have a beef because: Does this leave a small ray of light come through? Would MC ever accept one "genuine solution" by you for official UXP if you were ever inclined in the future to offer it (rhetorical question, probably...) ? Before anyone here accuses me of old-age-caused dementia , yes, I was here ALL along during the many dramas of the past, but I'd like to see a glass half-full rather than half-empty ; frankly, all this toxicity that existed/still exists between MCP and "us" burdens my soul and if mutual compromises between the two "parties" have to be made at some point, I'd be the first one to welcome them... Just my own humble opinion, though ... Best regards, always extremely thankful PS: December 2023 is well behind us now - any development regarding the "Glory to Hong Kong" song judicial saga (you're still with us here, your repo and blog are still alive, so I suppose things are calmer now?) ?