Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,441

  • Joined

  • Last visited

  • Days Won

    104

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    (https://panda-free-antivirus.sooftware.com/windows/download/401339) Confirmed also in latest NM28 : (but works in r3dfox-140) @roytam1, any ideas why?
  2. VistaLover
    ... 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...
  3. VistaLover
    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) ...
  4. VistaLover
    ... 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 ...
  5. VistaLover
    "extension_garbage_collector.cc" is a Chromium source file: https://chromium.googlesource.com/chromium/src/+/8496f370f/chrome/browser/extensions/extension_garbage_collector.cc ... and https://www.reddit.com/r/chrome/comments/1l0nd3l/what_does_this_chrome_garbage_collector_event_in/ https://www.reddit.com/r/WindowsHelp/comments/1itxbf8/what_is_this_in_my_event_viewer/ https://learn.microsoft.com/en-us/answers/questions/3890397/what-is-this-in-the-event-viewer I personally wouldn't worry that much about this; it's just an "informational" event, pertaining to "normal" browser functionality associated with its extensions system ... https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
  6. VistaLover
    No : https://forum.palemoon.org/viewtopic.php?t=23281 PS: I realise people on old/weak H/W (like myself ), in an attempt to squeeze more out of the browser, often turn to "about:config" for custom modifications of one or more "advanced" prefs (in the expectation they can potentially make their "old" box behave like a "recent" one ) ; besides the fact these "about:config" prefs are primarily directed at devs (and should not be tinkered by plain users), they are often poorly documented now (because MDN have a nasty habit of removing old documentation), so one can't be 100% sure what the actual/future ramifications of such a change will be; often times, it's just a placebo effect, at best ("I" manually modified the default value, so it "must" have improved performance); in the past, I used to do that myself a lot, but over the years I ended up with the conviction that leaving prefs at their default settings (configured by Mozilla devs) is probably the best policy ; but this is just me...
  7. VistaLover
    Have you actually compared this latest build to the 20260411/20260418-released ones? Because "suspect" isn't enough when troubleshooting "performance"-related issues (that are always bound to one's existing H/W and may differ considerably across other setups) ...
  8. VistaLover
    ... That question means that you have actually missed my previous post here ; latest NM28 gladly accepts palefill-1.30.xpi as a compatible extension (and doesn't disable it permanently, if already installed) ... In all honesty, I didn't test on latest St52, as I left that as an exercise for you ; the observed bug with palefill (and other extensions that have strictCompatibility=true inside their instal.rdfs) was caused by ae7c40d, which first appeared in the 20260418 UXP releases (actual buildID dates may be slightly different inside individual apps); that commit was reverted in 12e7d14, which first appears in this weekend's (20260502) UXP releases; since these are platform-wide commits, I have no reason to think that St52 hasn't been "fixed", while NM28 has; if you find otherwise, please let us know ,,, Best regards.
  9. VistaLover
    Nothing of that sort happened here, on any of 3 browsers used at random (NM28/St52/r3dfox-140esr) ; but I don't trust Google to tell me which sites I should visit or not (relevant settings disabled, both under r3dfox and Supermium ) ...
  10. VistaLover
    With latest NM28 (32-bit) SSE2 (buildID=20260430023812), I can confirm that the new favicon appears invisible not only inside the bookmarks toolbar, but also inside the bookmarks sidebar: Don't ask me why, I have no clue ; this appears to be UXP-related, as the new favicon does appear inside r3dfox's bookmarks sidebar: The tab bar (and URLbar, in the case of NM28/St52+CTR) looks nice now , though (as already mentioned); we're on a good point already, some fine-tuning is still needed on UXP to make things perfect ... Actually, that one is the favicon the browser defaults to for sites without a proper favicon of their own...
  11. VistaLover
    Thanks a lot for the updated Vista SP2 x86 FFmpeg builds; while one can still find FFmpeg builds for Win7+ besides yours on VideoHelp.com (e.g. the ones offered by AnimMouse), Vista+ compatible ones are very hard to come by; you're probably the only person currently targeting this OS, so your efforts are highly appreciated ! I have no issue myself with the current configuration or filesizes of those builds; I do also use them outside of yt-dlp and find them to be capable of all tasks I put them under ; where disk space becomes an issue, I prefer to use the "shared" builds... While it's true that the "XP" builds will run under Vista SP2, the latter are compiled on a more recent compiler and are better optimised for more "recent" H/W; plus, they do differ on their "configuration" (e.g. I do appreciate "--enable-libshine" in the Vista builds): "XP" compiler: gcc 14.3.1 (GCC) 20250901 optimised for Pentium 4 "Vista" compiler: gcc 15.2.0 (Rev14, Built by MSYS2 project) @j7n, since you're on Server 2008R2 SP1, you should prefer the "VISTA" builds over the "XP" ones ... I have tested both build variants and in CPU-intensive jobs (video transcoding), the "Vista" variant is 4-6 % quicker here ; but I only have a Core2 DUO; I expect the difference to be higher in more powerful hardware... @autodidact, please continue to compile and kindly provide the "VISTA" builds; and if the "XP" "crowd" (which has been, historically, difficult to please ) has any issues with that, you can always post them inside the Vista subforum (which, sadly, sees very little action these days ) ... Kind regards.
  12. VistaLover
    Yep, that's totally true; ffprobe is often used by the yt-dlp code to "probe" elemental (raw) media streams, often before ffmpeg itself is invoked; both are needed; in fact, when posting issues in their tracker, the yt-dlp devs demand ffprobe logs (though I myself send them MediaInfo logs, instead) ; to save disk space, I use "shared" FFmpeg builds... ... YES, that's what I often do: But it's a shame that audio-only media files can't be played back with FFplay under Vista SP2 (and higher) via drag-n-drop, due to a SDL2 bug: There was a related, long-standing, SDL2 bug that one can read about in below links, https://forum.videohelp.com/threads/388189-ffplay-WASAPI-can-t-initialize-audio-client-error#post2513211 https://trac.ffmpeg.org/ticket/6891 https://stackoverflow.com/questions/46835811/ffplay-wasapi-cant-initialize-audio-client-ffmpeg-3-4-binaries but while this has apparently been fixed for media files containing both video+audio, the bug has now returned under a similar guise for audio-only media files; the original mitigation, to set the env var "SDL_AUDIODRIVER=directsound" still works; FWIW, this bug is NOT present under WinXP, because that OS does NOT have WASAPI; and is NOT present on FFplay builds compiled with SDL2 <= 2.0.5 (quite old by now) ...
  13. VistaLover
    Even when one uses ffmpeg ONLY for mux/remux-ing purposes, there are cases where that very old version won't be up for the task; for just "h264+aac" placed inside the MP4 container, you can be fine (and even use older major FFmpeg versions, if you so wish); but, e.g., the MP4 container has, in recent years, been "enhanced", even without strictly sticking to specs, so that now it's possible to put vp9/hevc (aka h265) /av1 video streams inside the MP4 container; old ffmpeg versions will error out in such scenarios; and these may come up, especially when used with yt-dlp, on a multitude of supported services... Besides [re]muxing, ffmpeg remains the defacto downloader in yt-dlp when LIVE HLS (.m3u8) streams are being recorded, because the native yt-dlp downloader doesn't support live streams; for reasons not known to me, many such streams are served over HTTPS (some even use TLS v1.3), so ffmpeg has to be compiled with a recent version of a crypto library (OpenSSL, GnuTLS, etc.) - old versions often, and from my testing in the past, may fail to establish secure connections to the stream server... Also, over the years, streaming protocols like MPEG-DASH and HLS have evolved; e.g. while HLS initially had only MPEG-TS fragments, now it's possible to have fragmented MP4 (fMP4) served over HLS; old FFmpeg builds DON'T support these newer streaming implementations... If I was to be asked, I'd gladly grab an updated FFmpeg build (compatible with my OS of usage) than just stick to old code... This may have indeed been the case initially, but things have evolved over time ; and even the person who started this thread is now running the server variant of Win7; so, don't "pull" that "WinXP" card; perhaps it's time the admins moved this thread to a more appropriate place encompassing the rest of the "legacy" OSes, but as things stand now: 1. This thread is no longer exclusive to youtube-dl (which currently shows little, if any, development), as it now includes yt-dlp, too (with frequent, active, development) 2. As a result, this thread is also monitored by members on Vista/Win7, which official yt-dlp no longer supports... 3. The FFmpeg builds discussed/posted here-in may be used by Vista and/or Win7 users, and since this thread has now become (quasi) the only source of updated FFmpeg builds in MSFN, users may and can use those builds outside of a youtube-dl/yt-dlp context... I'm sorry if you don't like my opinion (and I have no intention to offend), but in (the number of) your recent posts you seem to present things as viewed ONLY from your own side, like "your way" is the only correct one for doing things - I'm happy it works for you as you wish, but other options/opinions do exist...
  14. VistaLover
    @AstroSkipper Perhaps it's now proper time to update https://github.com/martok/palefill/issues/109 ; after all, that "issue" wasn't caused by a fault of your compatriot (martok) ; just sayin', of course...
  15. VistaLover
    Sadly, what this has now caused is visual "deficiencies" (I'd call them "bugs" myself, but perhaps that's too "strong" a word for everybody else ) in the tab bar of every browser visiting "o.rthost.win", e.g. : 1. Pinned "o.rthost.win" tabs have now absolutely no favicon at all (whereas before the browser would compensate with a "generic" tab favicon) 2. Non-pinned "o.rthost.win" tabs have now their title shifted to the right, with an invisible favicon preceding it. 3. In St52 with CTR installed, I have it configured to always show the favicon in the urlbar; now there's an empty space (padding) before the actual address... One would normally open Web/Browser Console ONLY when troubleshooting (it's normally invisible to the user), but one can't really avoid the tab and/or the URL bar ; call it an OCD, but I personally find those "dummy favicon" GUI effects quite annoying (more so than "red lines" inside the Console(s)) ... @roytam1, could you actually upload a non-dummy favicon.ico? Or is that out of the question? (I'd also be OK with no favicon at all, after all there still exist sites with no favicons, e.g. https://forum.librivox.org/index.php , but then I do realise it'd be difficult to please everyone here at MSFN )
  16. VistaLover
    I have now updated NM28 (32-bit) SSE2 from palemoon-28.10.7a1.win32-git-20260418-d849524bd-uxp-d4c4c1f6ec-xpmod to palemoon-28.10.7a1.win32-git-20260502-d849524bd-uxp-9161cd3bdb-xpmod and can confirm that extensions with strictCompatibility=true have become again "compatible" : On a different issue, I have also tested multiple reloads of https://github.com/martok/palefill/releases/ and that latest NM28 build (with buildID=20260430023812) no longer hangs (like the previous week's build) on my Core2 Duo - but I haven't exhausted its use on multiple "heavy" GitHub pages; so, overall, a nice build indeed!
  17. VistaLover
    ... What I found more effective in my case was to (/also) block the "background" effects script itself: ||midnightscene.cc/build/assets/effects-BFJ8oBLg.js$script,important With just midnightscene.cc##canvas the page did display correctly, but the tab continued to consume an elevated amount of CPU here...
  18. VistaLover
    ... A similar question was asked on Mar 17th (some pages back ) by another MSFN member, and, again, Dave-H gave, pretty much, the same assessment, in a comment right beneath it ...
  19. VistaLover
    Thanks for identifying this ; so, a backport from "dactyloidae" ; well, as we all know, NM28 doesn't support WE at all, so, IMHO, it should've been excluded from this change, though I realise that the change is platform-wide, not app-specific... In any case, that commit (that upstream won't ever merge, as they don't support WE at all) was probably NOT accurately authored, because it disables the standard installation of a category (with strictCompatibility=true) of non-WE (i.e. XUL/legacy) addons that the platform itself (UXP) should support natively/out-of-the-box; in addition, have you actually bestowed upon Serpent 52 WE-support on par with fx-128? I am but a casual UXP user by now , but this looks like a true regression to me ... What are your feelings about this? Are you inclined to fix or revert that commit? Or should one manually modify the XPIs of ALL addons with strictCompatibility=true to have them installed/re-enabled in UXP apps after the 20260418 updates? Thanks for your precious time!
  20. VistaLover
    ... Not reverted per se in the end , but modified to cater for old single or double core CPUs : https://repo.palemoon.org/MoonchildProductions/UXP/issues/3066 https://repo.palemoon.org/MoonchildProductions/UXP/commit/3259bdc1c14deea4c4ec3133901b783ea37d5c09
  21. VistaLover
    This is the exact workaround suggested in https://github.com/martok/palefill/issues/109 in the case of PaleFill-1.30.xpi NOT installing by default in latest UXP browsers like NM28/St52... I have conducted a small investigation and it appears that this started happening with last week's UXP releases; with "palemoon-28.10.7a1.win32-git-20260411-d849524bd-uxp-c8f7030b13-xpmod", latest palefill can be normally installed from GitHub in NM28; but, starting with "palemoon-28.10.7a1.win32-git-20260418-d849524bd-uxp-d4c4c1f6ec-xpmod" the extension won't directly install, because the browser thinks the XPI is incompatible: So, we have a "regression" window, "c8f7030b13...d4c4c1f6ec"; is this new behaviour deliberate or a UXP bug? Do you think you can identify which UXP change made extensions requiring "strictCompatibility" incompatible with UXP builds >= 20260418 ? Thanks in advance for any insight; and, as ever, thanks for all those efforts of yours ...
  22. VistaLover
    If it's anything to go by, my own CPU on my Vista SP2 x86 laptop is a Core2 Duo from late 2007 (Intel Core2 Duo CPU T5250 @1.50GHz, "Merom") ; this can go up to the SSSE3/EM64T instructions set...
  23. VistaLover
    Well, guess what? I downgraded to the build mentioned by @johk, which for me is 28.10.7a1 (32-bit) (2026-04-10) (SSE2) and my "problem" page is now rock-solid, can be reloaded ten consecutive times without hanging the browser: This build is definitely a keeper for me, too...
  24. VistaLover
    Happens easily here, with or without uBO-legacy enabled: That GH releases page will successfully load once (or even twice), then when you attempt a tab reload, will hang the whole browser...
  25. VistaLover
    Many thanks for this ; it worked as described; still, this is a mitigation/a workaround, whereas the underlying UXP cause that now triggers the "incompatible" message remains unknown ... I see no reason for one to swear , is there? https://www.google.com/search?channel=entpr&q=TTBOMK
×
×
  • Create New...