Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,454

  • Joined

  • Last visited

  • Days Won

    104

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. 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...
  2. 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...
  3. 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 )
  4. 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!
  5. 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...
  6. 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 ...
  7. 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!
  8. 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
  9. 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 ...
  10. 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...
  11. 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...
  12. 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...
  13. 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
  14. VistaLover
    What are those? TTBOMK, GitHub itself still doesn't offer this functionality natively (i.e. PMs/DMs between GitHub members) ; https://github.com/orgs/community/discussions/15580 https://github.com/orgs/community/discussions/153547 Please elaborate... Regards.
  15. VistaLover
    NM28 v28.10.7a1 (32-bit) (2026-04-24) (SSE2), under Vista SP2 x86; I, too, find that the browser is hang/crash-prone on several GitHub pages, e.g. when I tried to reload a few times: https://github.com/martok/palefill/releases (it's one of pinned tabs in my NM28 session), it resulted reliably in a browser hang ("not responding"), that forced me to exit the browser ; upon a relaunch, I'm presented with a session restore window... Since I mentioned palefill, can a frequent NM28 user who has, sort of, followed its recent development enlighten me when/why PaleFill became incompatible with NM28? Its install.rdf file still reads: <!-- Pale Moon --> <em:targetApplication> <Description> <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id> <em:minVersion>28.10.0</em:minVersion> <em:maxVersion>35.*</em:maxVersion> </Description> </em:targetApplication> Disclaimer: I haven't been regularly using NM28 for a long while, but I do follow this thread ; for GitHub, which I use a lot, r3dfox[esr]-140 is the browser of choice here ...
  16. VistaLover
    Run Chrome browser without CORS https://stackoverflow.com/questions/3102819/disable-same-origin-policy-in-chrome
  17. VistaLover
    https://askubuntu.com/questions/404737/horizontal-scrolling-in-firefox-to-shiftmouse-scroll-instead-of-back-forward/404830#404830
  18. VistaLover
    According to MDL Forums and @abbodi1406, the LAST XP-compatible version should be 14.28.29213.0 : https://forums.mydigitallife.net/threads/repack-visual-c-redistributable-runtimes-2020-11-10.76588/page-27#post-1630817 https://github.com/abbodi1406/vcredist#windows-xp-notice https://github.com/abbodi1406/vcredist/releases/tag/v0.35.0
  19. VistaLover
    ...
  20. VistaLover
    ... Previously known as "ownedbywuigi", so that probably means https://repo.dactyloidae.xyz/Dactyloidae/UXP is a continuation of recently archived https://github.com/OwnedByWuigi/UXP/ PS: Since they've only released 64-bit binaries, I can't test here whether "Dactyloidae" even supports WinXP SP3/Vista SP2 32-bit ...
  21. VistaLover
    ... Is that about PR#3024 having been merged in 5f03b88 ? Will your decision be viable in the long run? So long I understand, you compile your UXP builds on a Win7 SP1 x64 build machine, don't you? There exist CPython-3 forks that have restored support for WinVista+ (so Win7, too), e.g. https://github.com/adang1345/PythonVista , will using such a py3 version during compilation render your browser builds not compatible with XPSP3/VistaSP2 ? If the need arises, I've also come across some py3 builds (> py3.4) that are XPSP3+ compatible, like: https://github.com/R-YaTian/CPython3.6.15WinXP/releases/tag/3.6.15 https://github.com/R-YaTian/CPython3.7.17WinXP/releases/tag/3.7.17_final https://github.com/R-YaTian/CPython3.8.20WinXP/releases/tag/v3.8.20_final
  22. VistaLover
    There doesn't exist a "portable" version per se; I'll link you to a similar question you asked back in November and I'll defer you to the answers you were given at the time (among them, mine) ...
  23. VistaLover
    Drop support for Android and remove Fennec ...
  24. VistaLover
    https://repo.palemoon.org/MoonchildProductions/UXP/issues/2862 ... and you can see there who to thank ...
  25. VistaLover
    ... Hence my previous comment you quoted : ... and I was strictly referring to "Moonchild Productions", are you officially part of that team now? Joking here , of course, but my comment was made on Feb 22nd, your fix landed on the official UXP repo on Mar 10th (and has yet to land on a roytam1-compiled binary), so yes, I wouldn't have survived had I held my breath... Jokes aside, my contribution was just to identify the missing JS feature; the report was made here by a UXP-fork user (on an unsupported OS), so the proper way to tackle that would've been: 1. Get access to a machine with an official UXP sanctioned OS 2. Get hold of official UXP-based browser binary/binaries 3. Reproduce the "bug" (rather the platform's deficiency) there 4. Register an account in the official PM forum 5. Report the problem in their WebCompat subforum (few fork users on XP/Vista can/are willing to go through the above ...) ... and then hope one member of the under-staffed MCP team takes it upon themselves to attempt a "fix"; given that the problem, as reported, affected a Polish government web site (relevant probably only to Polish citizens), MCP staff would have little incentive to spend time on fixing that, when other major/more popular sites are broken... So yes, over the years, I've become somewhat pessimistic ... Thanks again for implementing "object.GroupBy" . Regards.
×
×
  • Create New...