Jump to content

VistaLover

Member
  • Posts

    2,261
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. ... But, did you first try the DRM test page I referenced already? If not successful in getting the video to play, what exact error was produced, if any? Have you tried to inspect the Widevine CDM dll shipped with Google Chrome (x64) with Dependency Walker x64 under Vista SP2 x64+ExtKernel? ... That's a telltale sign of Widevine CDM either 1. Being completely broken under your OS+browser combination 2. Its web requests to the Spotify Widevine licence server not being authorised/approved, due to a variety of reasons [blacklisted a) version of the CDM itself, b) browser version the CDM is installed in c) device/hardware type, which includes - but is not limited to - OS the browser+CDM are installed] ... Please, which exact version of Google Chrome x64 was that and which exact version of the WV CDM? TL;DR: Informing us the Spotify web player doesn't (absolutely) work is one piece of info (no doubt useful to those willing to try it in the first place ), but doesn't offer any clue to the more inquisitive among us as to WHY it doesn't work ... FWIW, I'm on Vista SP2 32-bit, so can't perform those tests myself...
  2. ... 99.9% of Spotify audio(+video) content is behind full blown DRM and requires the most-up-to-date version of the Widevine CDM (v4.10.2652.0); Widevine CDM (itself basically a DLL file) has abandoned Vista SP2 support at least 3 years ago, and will probably move out of supporting Win7 before the end of the year (WV is owned by Google and they have stopped supporting Win7 in Chrome, of which WV is a component, early in 2023) ... @Scarf32 should probably first test if his browser of choice under Vista's Extended Kernel does have a working EME/DRM implementation (via Widevine) at below test page: https://bitmovin.com/demos/drm The CDM sends hardware/platform/OS details to the configured licence servers, in order to receive a response with the content decryption keys; because all that takes place inside a so called black-box (the OS and the browser have no access to it at all), it's hard to tell beforehand if the Spotify WV lic servers will whitelist decryption key requests originating from a Vista+ExtKernel "system"; assuming, of course, that the ExtKernel itself enables the "correct functioning" of the Widevine CDM to begin with ...
  3. ... Actually, it uses Web Assembly (aka wasm) to do it : https://github.com/zamfofex/jxl-crx#readme ... Disgust echoed in the "archive.org" reviews/comments: ... And one thing mentioned in that quote above that seems to be the new "vogue" among app authors is the deprecation of 32-bit binaries (latest Paint.NET runs exclusively on Win10/11 64-bit), a development I face all the more lately when searching for Windows binaries (of various software) compatible with my x86 OS... I mainly blame MS and their latest OS, available solely as 64-bit ...
  4. Yep, St52 does have that, too: As one can see, there's duplication inside the "value" column, but only "image.http.accept" mentions webp ...
  5. As I wrote in my previous post, MS serve IE a somewhat different version of their Bing Search (home)page, compared to Fx-based browsers: IE9: NM28: So, they're not using UA-sniffing just to determine what image format to serve, rather which page flavour to serve ; it just so happens (and, as you said, this is no coincidence ) that the flavour targeting IE is being served JPEG instead of WebP... Actually, that was the first thing I tried before I ended up using a SSUAO "trick" for Bing Search homepage, and I can tell you it just doesn't work there ... FWIW, it doesn't even work in St52 if: a. You disable the native WebP decoder, by toggling "image.webp.enabled" b. Modify "image.http.accept" in the way you suggested... Best regards ...
  6. ... And quite recently, Microsoft themselves adopted Google's webp image format on their "own" webpages/services ... I have https://www.bing.com/ as one of my pinned tabs, and on that the background image changed format from ".jpg" (classic JPEG compression) to ".webp"; UXP-based browsers have no issue with webp, fortunately, but the old Firefox ESR 52.9.1 doesn't support the format: For the time being, MS still serve JPEG to their deprecated IE browsers, so changing the UA to, e.g., an IE9-based one will get the Bing background image back (on a slightly different GUI, tailored for IE): general.useragent.override.bing.com;Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0) NB: FxESR 52 doesn't support SSUAO natively, only via extension(s), however I had restored SSUAO support in it via a method made public years ago (search the forums here, if interested ) ...
  7. That's most excellent news! ; If I may kindly ask , on which version of Microsoft Visual Studio? Because earlier I had speculated you had been using up-to-now either 2015 or 2017 ...
  8. ... Unless things have changed from 2019 : https://msfn.org/board/topic/177125-my-browser-builds-part-1/?do=findComment&comment=1169577 [ https://msfn.org/board/topic/177125-my-browser-builds-part-1/?do=findComment&comment=1170787 ] The OS is definitely Win7 SP1 x64, with ample RAM... As for MS Visual Studio, either 2015 or 2017, nothing newer ... I believe VS2017, up-to-a-version (?), would've allowed to install the v141_xp toolset (enables compilation of apps that can run on XP+; the default for VS2017 is NT 6.0, I think ) ... https://stackoverflow.com/questions/49516896/how-to-install-build-tools-for-v141-xp-for-vc-2017
  9. @j7n : It was dom.forms.button.standards_compliant Toggle that to false and then restart Serpent 52 (this is important); you should then be able to invoke the image-related CM entries I talked about ; NB: Use of an adblocker is advised on Discogs; when I was testing in Safe Mode, I noticed increased CPU consumption ...
  10. ... Mine's 1280x800, so bigger by a small margin (2008 era Toshiba laptop) ... Mine looks different because I'm using a third-party complete theme (Photonic, modified to display correctly on Vista; the original targets Win7+); I'm also using an extension, Menu Icons Plus 3.2.1-signed.1-signed, which itself further alters the appearance of the context menu; complete theme + extension DO NOT interfere with the actual correct functioning of the browser's Context Menu, though... ... But sites often make sure "we don't always get what we want" ... Please, try with a clean Serpent 52 profile ; in some minutes, I'll update this post with screengrabs from a fresh St52 profile and its behaviour on the discogs URL you linked to previously... Later additions: On a fresh St52 profile, I have no issue with middle-clicking the small image on the top-left and loading: https://www.discogs.com/release/2872133-London-Starlight-Orchestra-Once-Upon-A-Time-In-The-West/image/SW1hZ2U6NTE2NDE5OQ== However, when I try to invoke the context menu by placing my cursor on top of the "bigger" image, I now get what you described: I then switched to my "dirty" St52 profile, but this time I loaded it in "Safe Mode" (to get add-ons out of the way); first difference I noticed is that my cursor, when placed on top of the "bigger" image, now turns into a small magnifying glass with the "+" sign, something that doesn't happen in the fresh profile; right-clicking produces a Context-Menu inside which image-related options are available: So, I have something(s) modified inside my about:config settings that restores the image-related context-menu entries; but, which something(s) ???
  11. In St52, if in site settings I specify: then, upon visiting the URL you referenced, https://web.lloydsdirect.co.uk/sign-up/create-account, my IndexedDB storage isn't populated with data from "lloydsdirect.co.uk"; however, the same is true for cookies set from that hostname, which isn't useful on a log-in page, obviously ; as you said, site data (indexedDB) and cookies are interlinked under the "Cookies" moniker... Have you considered the "Allow for Session" setting? FWIW, you'd be auto signed out once you restart your browser session... Edit: I tried myself the "Allow for Session" setting; unfortunately, on page load I do get a "https+++web.lloydsdirect.co.uk" directory created inside my storage folder, however that directory isn't wiped out once I restart Serpent 52 ...
  12. How small a screen are you talking about here? In any case, "hiding" artwork behind iframes is a known technique the sites employ... On St52, I middle-clicked on the Clint Eastwood "thumbnail" and in an adjacent tab it loaded: https://www.discogs.com/release/2872133-London-Starlight-Orchestra-Once-Upon-A-Time-In-The-West/image/SW1hZ2U6NTE2NDE5OQ== Carefully placing my cursor near one of the four image corners, I find the "context menu" is enabled, through which I can either copy the image URI, https://i.discogs.com/u7OohGushz9n7OLJKxejCKnTplWEFK2ZCqgRQgYZ3D0/rs:fit/g:sm/q:90/h:600/w:600/czM6Ly9kaXNjb2dz/LWRhdGFiYXNlLWlt/YWdlcy9SLTI4NzIx/MzMtMTMwNDk4MTgz/NS5qcGVn.jpeg or directly save the image on disk:
  13. ... there's always the adjective Hellenic , which is actually the preferred one (i.e. how "foreigners" should refer to everything Greek) among "Greeks" of today... (OT, I know, but I'm not the one who first committed that crime here .. )
  14. ... Well. "I" took that to mean he's offering to facilitate any infrastructure migration of the Roytam1 projects, should the existing infrastructure (GitHub repositories, binaries hosting server, etc.) becomes blocked by the HK regime; not as contributing actual code to those projects; but, of course, I'm not basilisk-dev ... ... And if I may say so myself, quite several of the last posts here seem to revolve around Mypal68; well, we do have a dedicated thread for it (possibly more than one), don't we?
  15. ... In addition to the above, basilisk-dev has no plans at all (and this has been specifically communicated here ) to invest development efforts on a browser that would run on anything below Win7 SP1 (current minOS requirements of official Basilisk) ... Best regards
  16. @AstroSkipper (all links produced via a Forum Search, BTW ) : Two ways to tackle this: 1. In "about:config", toggle "dom.abortController.enabled" to false, restart Serpent 52 and then installing the userscript from that GH page will work (just tested it now ); but the abort API is still needed by GitHub to properly function, so, after installing the userscript, reset the pref and, again, restart St52... 2. "Patch" the actual extension in below fashion: "./background/index.js" (a minified JS file): -!(!e.AbortSignal||!browser.windows) +(!!e.AbortSignal&&!browser.windows) Again, VM-2.14.0 works as expected in actual FxESR 52.9.x (it doesn't have itself the abort API), the breakage in St52 is due to MCP's (imperfect) abort API implementation inside UXP (FTR, VM's devs are almost oblivious to St52's existence ...).
  17. Noted, and I trust your knowledge/expertise ... Thanks again !
  18. If members here running St52 and/or NM28 wish to be served the "current" iteration of Google Search (the one targeting latest browsers), a SSUAO is necessary; in latest NM28 with its default UA: OTOH, with: general.useragent.override.google.com;Mozilla/5.0 (%OS_SLICE% rv:55.0) Gecko/20100101 Firefox/55.0 Fine-tuning the appearance of GS is possible via its settings (cogwheel button) ; as seen, I've opted for its dark theme ; caveat: the modern GUI is more resource-hungry ...
  19. ... Those (few ) of you that like to occasionally browse the Official PM Forums for info/troubleshooting related to UXP-based browsers discussed here (encompassing St52, NM28 and a few others), "their" breakage seems to persist; latest news from MC himself (via the temp Discord server): So, Wednesday (today) won't be "restoration day" ...
  20. For starters, Roy's blog, https://rtfreesoft.blogspot.com/search/label/browser would be the first to become inaccessible from within HK, since "blogger" is a Google-provided service ... Although a pessimist by nature, I still hope/wish that things won't reach any extreme levels... If GitHub and MSFN remain accessible from within HK, then, perhaps, a move to an overseas server hosting the binaries would be all that's needed; determined people in mainland China have come up with inventive solutions able to penetrate through the GFW, however these "solutions" might be against local laws; i.e., I'm not suggesting myself Roy should break HK legislation, if/when enforced...
  21. Many thanks for your code! ; I adapted it for Violentmonkey installed in St52 (can also be used in St55, I guess ), here's how the "==UserScript==" header looks there: // ==UserScript== // @name Fix <link rel="preload" ...> in MS Support site // @version 0.1 // @author UCyborg // @namespace UCyborg // @description Fixes CSS rendering on "support.microsoft.com", on UXP-based browsers // @homepageURL https://msfn.org/board/topic/184051-my-browser-builds-part-4/?do=findComment&comment=1246726 // @icon https://support.microsoft.com/favicon-32x32.png // @include https://support.microsoft.com/* // @run-at document-start // @grant none // ==/UserScript== Here it is enabled inside VM itself: ... Microsoft are currently focusing solely on their offspring browser (ChrEdge) they conceived after fornicating with their former opponent, Google ; one (perhaps more ?) MS coder authored code that was tested to work on ChrEdge (perhaps also tested in latest Fx), with no care in the world for "legacy" browser engines ; but it was Google that started this in the first place: ... Should be back up on Wednesday (fingers crossed):
  22. Thanks ; works as advertised in my 32-bit OS: [debug] Command-line config: ['--ffmpeg-location', '..\\FFmpeg', '--downloader-args', 'ffmpeg:-v 8 -stats', '-v'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out cp1253 (No VT), error cp1253 (No VT), screen cp1253 (No VT) [debug] yt-dlp version nightly@2023.06.13 [cab94a0cd] (win_x86_exe) [debug] Python 3.9.13 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev ) [debug] exe versions: ffmpeg n6.1-dev-1149-N-111033-gf11515c (setts), ffprobe n6.1-dev-1149-N-111033-gf11515c, phantomjs 2.1.1, rtmpdump 2.4 [debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.05.07, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3 [debug] Proxy map: {} [debug] Loaded 1843 extractors 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.
  23. ... Well, this thread contains mixed content about both youtube-dl (in the topic's title ) and yt-dlp, and is primarily a WinXP one (), so the info I post below might be considered as only remotely relevant, especially since nicolaasjan already provides py3.8-based XP[+Vista]-compatible yt-dlp (32-bit) compiles, still ... June 5[6]th saw the release of Python 3.7.17 by the PSF, a source-only security bugfix release: https://www.python.org/downloads/release/python-3717/ https://docs.python.org/release/3.7.17/whatsnew/changelog.html#changelog Windows binaries (Vista SP2+, x86 & x64) are being provided by a third party and can be found here ; Python 3.7, according to PSF's official lifecycle policy, will receive security fixes i.e. current month () ; https://www.python.org/downloads/ specifies the py3.7 EoL date as 2023-06-27, in ca. 2-weeks time ; we may see one final py3.7 update in the form of v3.7.18 towards the end of this month, but I personally doubt that, as 3.7.17 has been released just a week ago ... I guess the ball is now on yt-dlp's court, to start considering removing support for py3.7, eventually... py3.7 is currently being used to compile the yt-dlp_x86.exe builds for Vista SP2 (both 32 & 64-bit) and for the 32-bit minorities on Win7 SP1, Win8, Win8.1 and Win10 (Win11 doesn't come in a 32-bit flavour); py3.8 is currently being used to compile yt-dlp.exe (64-bit) for Win7 SP1+ x64 users (the masses, I guess ...); many devs inside the yt-dlp team have expressed in the past their desire to forego completely py3.7 and py3.8 support at the same time, switching directly to py3.9+ (or, perhaps, py3.10+), especially since Win7 usage is dwindling over the last months (not least because evil Google dropped support for the OS); that leaves the question pending over the fate of the yt-dlp_x86.exe binary itself, as the trend now among app authors is to switch exclusively to 64-bit ; I'll sure be keeping an eye over at the yt-dlp repo for any related (ill-)developments ...
×
×
  • Create New...