Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,245

  • Joined

  • Last visited

  • Days Won

    93

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    Thanks for your genuine concern ; I live in Northern Greece, in a region that was spared by that enormous physical disaster, whose magnitude was never before seen in European territories (but I do remember the floods in Germany a year or more (?) ago); Thessaly (and, especially, Magnesia), the most fertile Greek region, has suffered the most acute blow of Daniel, but the mourning sentiment is shared by the whole Greek nation (the floods only accentuated the sense of sorrow already caused by the August wildfires, which practically completely charred the last virgin forests of Dadia, in the Evros region, close to the Turkish borders... The infrastructure in Thessaly will take from 3-5 years to be restored, the estimated cost from the wildfires+floods is in the €2bn region ... Comforting to know , since, according to the media here, Saola was pretty intense ...
  2. VistaLover
    ... Again, cautionary words from "upstream" : https://forum.palemoon.org/viewtopic.php?p=242821#p242821 ... So, as I've stated multiple times in the past myself, "use e10s at your own risk" (I'm not, if you care to ask ) ...
  3. VistaLover
    ... Well. the Protonmail can't-log-in bug has now hit "upstream", with the release of PM 32.4.0 : https://forum.palemoon.org/viewtopic.php?f=3&t=30256 As is common in such cases , Moonchild was quick to put the blame on Protonmail rather than on his own browser ... It is also suggested there that @Mehmed's solution posted here isn't really foolproof, because the bodies of older e-mails, encrypted with the old RSA (2048) 4096-bit key, can't be decrypted with the newly created ECC Curve25519 key and, as a consequence, those older e-mails can't be read anymore by their original recipient ...
  4. VistaLover
    ... According to my tests (and records of them kept ), the FB related PR#7890 was already present in your py3.8 : [debug] yt-dlp version nightly@2023.09.02 [2301b5c1b] (win_x86_exe) previous build; while the "nightly@2023.08.31 [7237c8dca]" one did not include it ... FWIW, this PR has now been officially merged into yt-dlp master branch: https://github.com/yt-dlp/yt-dlp/commit/d3d81cc98f554d0adb87d24bfd6fabaaa803944d Kindest regards ...
  5. VistaLover
    Warmest greetings ; when you wrote that, did you actually mean just the OF homepage? As I have already demonstrated in a previous post in this thread , individual OF posts like httpS://onlyfans.com/693430760/onlyfans have trouble loading fully in browsers via a ProxHTTPSProxy MITM connection, because the websockets secure protocol (wss://*) is being used and the secure proxy doesn't support it ; @cmalex has acknowledged that and confessed his inability to "fix" it: Again, "we" need a very experienced/skillful Python coder to edit the original proxy script in order for that support to be added... I also tried whitelisting the wss protocol in the proxy's config.ini: [BYPASS URL] http://* +wss://* but no change was observed: (St52 is the browser used...) ... I'm posting this right now in St52 via referenced ProxyMII version (its Python modified to be compatible with Vista SP2 ) and I'm not experiencing "considerable" slowdown myself , on any site; just the expected 1-2s for the "proxy" to populate its window; nothing more... Best regards ...
  6. VistaLover
    Actually, the Tycho platform on which NM27 was originally based on (modified MozillaESR 38) is dead, buried and exhumed; what is being developed is ArcticFox https://github.com/rmottola/Arctic-Fox the new "upstream" for NM27 (which also gets backports from other sources, e.g. UXP ) ... The current application platform supporting NM27 has significantly diverged from Tycho; I'm not following closely AF's development, but if the latest release's version (42.1) is anything to go by , I'd say AF is somewhere in the mid-40's Firefox versions, compat-wise ; this is still too low to address fully the beast the web has now become (and if you're a regular here , you'd have noticed already how even the UXP-based browsers struggle with it ) ... Answered above ; if you can, use another browser for bandcamp and other such, media rich/script rich, services ; long gone is the time , especially on our "legacy" H/W and OSes, when only one browser application would "fit all" ...
  7. VistaLover
    ... Plays fine here (media.av1.enabled;true) : ... And it would indeed be nice if the UXP-based browsers were able to play HEVC-encoded video streams (I currently have to use 360EEv13 for these ); @roytam1, what do you think?
  8. VistaLover
    According to records I kept, the last time those LAV dlls were updated was on 25/09/2021 - the underlying FFmpeg code was v3.4.9-based : https://o.rthost.win/palemoon/lav-dll-lite-3.4.9.7z https://o.rthost.win/palemoon/lav-dll-lite-noasm-3.4.9.7z https://o.rthost.win/palemoon/lav-dll-lite-ia32-3.4.9.7z At around the same time, the ffvpx lib was also "updated" to the same FFmpeg version: https://github.com/roytam1/UXP/commit/9ab5fe7274d577527b6afb245805d9f512e91db9 so, as said by Roy, "they're almost the same thing" ; unless people here are still using the even older LAV compiles, based on FFmpeg-v3.1.1 ... https://o.rthost.win/palemoon/lav.7z https://o.rthost.win/palemoon/lav-dll-lite-mmx.7z https://o.rthost.win/palemoon/lav-dll-lite-noasm.7z FWIW, FFmpeg-n6.1 is about to be released; because the vanilla FFmpeg code does not support XP any longer (well, since v4.0+), the Roytam1 UXP browsers have to stay at above (3.4.9) outdated FFmpeg version ; I would have hoped for a more recent FFmpeg version when the browsers are launched on Vista SP2+, but it appears this is technically difficult to achieve ... "Upstream" don't suffer from such limitations, because they target Win7+, but, at the same time, they don't rely on ffvpx for those patented decoders XP lacks by default ...
  9. VistaLover
    Pray tell, why? The UXP-based browsers (and St55), under XP SP3, use by default as source for patented decoders (h264/aac) the patched, built-in, ffvpx library: media.ffvpx.enabled;true What problems are you encountering with that implementation? In any case, what you want isn't possible right now; could be made possible via authoring new code, e.g. for the browser to load those LAV DLLs when ffvpx is disabled under XP; personally, if such an option were to materialise, I'd want a fully separate pref inside about:config that would completely disable the loading of those DLLs ... And, in case you were not aware already, you have another option (under XP) for patented decoders, if you don't "like" the ffvpx solution: Install the Adobe Primetime CDM, enable its own patented decoders (both for video/audio) and disable the ffvpx ones; we have a dedicated thread in MSFN (originally targeting FxESR 52 under XP, but the general idea is the same); since it's a solution via a CDM, only St52/55 can be used, NOT NM28, which, by design, lacks any EME/DRM support ... Regards.
  10. VistaLover
    @DanR20 Can you observe similar audio breakage in the latest NM27 build? This makes use of the same LAV DLLs for decoding under XP SP3 and has the same UXP audio-backend changes ported to it... https://github.com/roytam1/palemoon27/commit/ff0284d9ebbbbd7106c6b779459787f07ffaef29 https://github.com/roytam1/palemoon27/commit/da95aa0ec28253b2620e868a11d67136da873b0f
  11. VistaLover
    @DanR20 Several audio-backend changes should've landed this weekend on UXP and those were indeed "ported" to the mozilla45ESR repo and resultant build(s): ported from custom branch of UXP: speex-resampler: update to git head ported from custom branch of UXP - add configure option '--enable-int-audio-sample' for speed and audio driver compatibility, and fixups in exports and webrtc. (ef5e4f06) - cubeb: disable wasapi backend when '--enable-int-audio-sample' is specified, since it can handle float32 sample only in our current cubeb library. (0f1c046a) Somewhere in there lies the cause for your observed audio breakage ... Read also previous notice from Roy: https://msfn.org/board/topic/184051-my-browser-builds-part-4/?do=findComment&comment=1251055 ... When testing on Win7 (actually, on Vista SP2+ ) for video and/or audio decoding issues, you should first toggle "media.wmf.enabled;true" to false, because when on > XP, the browser will use by default the patented decoders (h264+aac) provided by the OS (via the Media Foundation Framework) and NOT the decoders provided by the external LAV DLLs (the only case under XP, which lacks WMF) ...
  12. VistaLover
    ... FWIW, that would be v1.1.4 (file version 1.1.4.2) from 2017: Direct link to the updated binary is: https://www.maxoutput.com/updates/authenticator/Authenticator.zbin The "*.zbin" archive can be manually extracted (to the "*.exe") with a tool like UniExtract2 (both 7-zip/WinRar were unable to ) ... 6/70 is certainly a better score than the 36/70 the older version 1.1.2 generates; however, my own AV is one of the 6 vendors that flag this, so I'm not decided myself 100% ... That being said, I sense the thread has been slightly off-tracked already; more suitable in software-for-XP+ and/or AV-specific subforums probably ...
  13. VistaLover
    ... I re-analysed the file (previous score was from 8 months ago ) and now the new score is even "bigger" : "36/70 security vendors and no sandboxes flagged this file as malicious" ... I guess most AV suites treat this as a KeyGen of sort ; the author himself stated in its website: FWIW, in the latest score, the Google engine simply timed-out ...
  14. VistaLover
    https://www.maxoutput.com/authenticator/MOSAuthenticator_off.zip WFM : Warning: Most AV suites (including mine ) outright BLOCK this program ; I had to whitelist both its download page (for the download to even begin), as well as the binary (Authenticator.exe) itself; therefore, USE AT YOUR OWN RISK ... Regards.
  15. VistaLover
    ... Probably because numeronyms were not "en vogue" at the time that Mozilla article was written (ca. the time Fx-1.0.6 was released, 2005-07-18; I wasn't even on line back then ) ...
  16. VistaLover
    ... Well, I'm still on St52 (32-bit) buildID=20230731064657 and that's indeed its chase.com SSUAO... Next week's St52 release, with buildID=20230810152826, had the Fx version inside that SSUAO downgrade ( ) to 102.0; this is still true for latest St52 (32-bit), buildID=20230818021145 ... The related commits I researched appear a bit "off" : Official Basilisk: https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/633ad774201bdb53fe4fa2424da851af77f1bfc8 (112.0 => 102.0, like in "our" St52) Roy's custom UXP branch: [Basilisk] [SSUAO] Update chase.com override https://github.com/roytam1/UXP/commit/85a5c5821499012f92331b97d5ac2b40b5653794 (79.0 => 102.0) ; but where did v79.0 come from? [Pale-Moon] [SSUAO] Update Chase override https://github.com/roytam1/UXP/commit/4bbb81d78ee2f0c6342955cb0b2392a684721653 (112.0 => 102.0) Trying to understand why the "downgrade" was even implemented, I arrived at below official PM Forum thread: https://forum.palemoon.org/viewtopic.php?f=70&t=29704 That's an interesting read (though nerve-testing with regard to the chase.com UA-sniffin' practices ); @Mathwiz found out that now an upgrade to Fx-113.0+ versions is needed (to make the nag banner go away), but does logging in on https://secure.chase.com work as expected with that "upgrade" in place?
  17. VistaLover
    Is that on your "loved" St55 ? Because St52 (2023-07-31) (32-bit) has below SSUAO: general.useragent.override.chase.com;Mozilla/5.0 (%OS_SLICE% rv:112.0) Gecko/20100101 Firefox/112.0 But , as you wrote in your edit , that's still NOT enough to satisfy chase.com when loading https://secure.chase.com/ I set the Fx version to 115.0, which is the current ESR branch, and that makes their "notice" go away - still, as you say, if "they" actually move on to needing a Fx-113.0+ JS/CSS feature for "their" pages to work, then all bets are off for UXP users ... Kinda OT, but since I see it all the time here by various members , https://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-us/firefox/releases/1.0.6 Best greetings
  18. VistaLover
    ... No, it's NOT (compatible with any CPython version < 3.7); you're just "cheating" , by running the "source" with a "community" recompiled/produced (see my previous reply to @Mark-XP here) CPython version 3.9 : which doesn't officially (as in by the PSF) support Windows < 8.1 (BTW, Python code doesn't target specific OS versions, only specific Python versions) ... You added "binary" yourself, there ; I was referring to the yt-dlp source code, which should also cover all binaries compiled from it! As I wrote already, the PSF EoL'ed Windows XP SP3 with CPython 2.7.18 and 3.4.10, none of which is currently supported by yt-dlp (source) code ; as I also wrote previously, the youtube-dl (source) code does still support both aforementioned CPython versions (and, thus, XP SP3); is now everything crystal clear? I hope so ... Warmest (as in being under yet another heatwave here) greetings from Greece !
  19. VistaLover
    ... Do note, though , that this specific binary size pertains to native compilation under Linux: Cross-compilation on Linux targeting WinXP will result in quite larger binaries, compared to the ones produced for native Linux usage... Even larger file sizes are being produced under native Windows FFmpeg compilation ... Regards
  20. VistaLover
    Hi again ; I did not want to give very detailed explanations on this, because..., well, some MSFN members are "allergic" to long posts of mine ... But indulge yourself: My NM28 tests were done on the 32-bit compile of the default (SSE2+) latest build offered by roytam1; its default UA string (on my system) is: Mozilla/5.0 (Windows NT 6.0; rv:4.8) Goanna/20230731 PaleMoon/28.10.7a1 Without modifying anything in about:config, "userstyles.org" starts to load, but then barfs with a Checking indeed the Web Console, I see the "block" has to do with a Google () related URL, https://accounts.google.com/gsi/client By creating the below SSUAO for "google.com", general.useragent.override.google.com;Mozilla/5.0 (%OS_SLICE% rv:65.0) Gecko/20100101 Firefox/65.0 that "client-side exception" is being mitigated and, consequently, the page does now load! Incidentally, that "google.com" SSUAO will allow you now to be served the most recent incarnation of the https://www.google.com/ search engine result pages, instead of a dumped-down version "legacy" browsers are being served (Fx < 65.0) . My primary UXP browser is St52; this one comes with a native (built-in) SSUAO for google.com: general.useragent.override.google.com;Mozilla/5.0 (%OS_SLICE% rv:71.0) Gecko/20100101 Firefox/71.0 Basilisk/52.9.0 This one is enough to allow the loading of a "basic" "userstyles.org" homepage, but pages for individual userstyles end up as blank ; I had to impersonate Chrome () on Serpent 52 (but NOT on NM28) for the "site" to work properly... general.useragent.override.userstyles.org;Chrome/86.0.4240.198 (in fact, just the word "Chrome" should be enough ...) Kind regards .
  21. VistaLover
    ... Looks like you have a lot to catch up with ... The official yt-dlp has long ago abandoned support for CPython 3.4 and, thus, the Windows XP OS... My personal records/archives indicate that yt-dlp v2021.06.09 is the last official binary that can launch under XP: [debug] Command-line config: ['-v'] WARNING: Support for Python version 3.4 have been deprecated and will break in future versions of yt-dlp! Update to Python 3.6 or above [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] yt-dlp version 2021.06.09 (exe) [debug] Python version 3.4.4 (CPython 32bit) - Windows-Vista-6.0.6003-SP2 [debug] exe versions: none [debug] Proxy map: {} Usage: yt-dlp_x86 [OPTIONS] URL [URL...] yt-dlp_x86: error: You must provide at least one URL. Type yt-dlp --help to see a list of all options. Up to current times, the 32-bit official binary, yt-dlp_x86.exe, is being compiled with CPython 3.7, which requires Vista SP2 32-bit and higher ... The yt-dlp.exe official binary you mentioned is, in fact, 64-bit, compiled with CPython 3.8 and requires Windows 7 SP1 x64 and higher ; additionally, the yt-dlp devs like/want to use the "latest and greatest" ( ) Python version (not the case, though, with the current youtube-dl maintainer ) and CPython 3.7/3.8 versions (3.7 EoL'ed by the PSF by now) might/will become unsupported in the near future ... The yt-dlp binaries offered here in this thread have been compiled with "community" produced Python versions (patched - 3.7 - or recompiled from modified source - 3.8, 3.9) that have restored WinXP (and Vista , in the case of 3.8/3.9) support ... Best regards .
  22. VistaLover
    ... As your "initial" doubting has since been generously upvoted/liked by the known possee , let me again draw your closer attention to my original post here and its first embedded image (which I hope is visible to you ), where it's clearly seen I was using NM28 v28.10.7a1 (32-bit) (2023-08-10), which, to the best of my knowledge, is "the latest release" ... Kindest regards.
  23. VistaLover
    ... The userstyles.org website and their "own" extension, Stylish, https://chrome.google.com/webstore/detail/stylish-custom-themes-for/fjnbnpbmkenffdnngjfgmeleoegfcffe ONLY support Google Chrome and MSEdge (not even other Chromium forks or Mozilla Firefox*) : This has escalated beyond a "joke" now ... (*): Stylish for Firefox available on AMO is from July 2018, I bet it doesn't work with the "new" userstyles.org site .
  24. VistaLover
    The new incarnation of "userstyles.org" has also broken an old and widely known "hack" inside the "legacy" browser communities; say, for instance, you wanted to load a userstyle found on the URI: https://userstyles.org/styles/140099/discord-dark-maroon Even if your "legacy" browser wasn't able to properly render that page, the CSS code itself was to be found easily via the URI below: https://userstyles.org/styles/140099/discord-dark-maroon.css It could then be "installed" to your Userstyle Manager of choice through the "install CSS from URI" route: But now, sadly, that "*.css" URI redirects back to the original URI , without allowing access to the actual CSS code ... Speaking of that new (and most evil) "userstyles.org" redesign , it's full of CSS animations (the subject of a recent discussion here), thus a mere visit on the homepage is enough to "fry" both cores of my CPU (FFS , even the Stylish logo itself (top left) is being auto-animated! ) ... ... And I left this for last: Just an indisputable proof of how much Chromium-centric the web has become , making individual userstyle pages display normally under St52 is just a "Chrome" UA away: general.useragent.override.userstyles.org;Chrome Then:
  25. VistaLover
    Yes, the "new" owners of the Stylish site are keen to promote their own Chrome (spyware?) extension, and that used to be the case before, too; Stylem hasn't been developed for more than a year: https://github.com/Lootyhoof/stylem/commits/master but it did work with previous incarnations of "userstyles.org": Fix installing from userstyles.org It would appear the new site "overhaul" (read: downgrade ) broke that Stylem functionality ... Users of official Pale Moon may want to report this recent breakage on Stylem's issue tracker, https://github.com/Lootyhoof/stylem/issues or its PM Forum support thread: https://forum.palemoon.org/viewtopic.php?f=46&t=19443 Hopefully then, its author might come up with a fix (if you do file a report, you'd also have to mention the SSUAO for google that makes loading of "userstyles.org" possible under PM ) ...
×
×
  • Create New...