Leaderboard

Adobe Flash Player has been updated to 32.0.0.303 today. Direct links to official distribution packages version 32.0.0.303 with SHA-1 signatures (should work with Windows XP SP3/Windows XP x64 SP2) Internet Explorer ActiveX: http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.303/install_flash_player_ax.exe Mozilla Firefox NPAPI (also for Opera Presto/Google Chrome 44 and earlier): http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.303/install_flash_player.exe Google Chrome 45 through 49 PPAPI: http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.303/install_flash_player_ppapi.exe

Most unfortunately, I can reproduce ; and it isn't only the Adobe Primetime CDM affected, as reported by @dencorso, but also the Widevine CDM too, which is installed and visible under Vista+; Widevine CDM v1.4.9.1088 is currently broken since August 13th 2019, due to Google changes - effort is underway by MCP to restore Widevine support in official Basilisk ( see here ), which is currently hitting a deadend, but any success won't benefit Vista users of Serpent, as updated Widevine DLLs don't run on Vista and require Win7+; still, having a working implementation of WV on Serpent would certainly benefit St users on Win7+ I normally don't have Adobe Primetime CDM (APCDM) installed in my Serpent 52 profile, but to humour @dencorso I did correctly install it (v17) and made sure I disabled the other h264/aac decoders: media.wmf.enabled;false (Vista's native WMF decoder) media.ffvpx.enabled;false (Serpent's bundled FFmpeg decoder) while I made sure media.gmp.decoder.enabled;true (APCDM's decoder) Widevine CDM (WVCDM) v1.4.9.1088 is also correctly installed. Extended testing reveals that: A. 2019-11-15 Serpent win32 build is the last good build where: 1. WVCDM appears installed in both "about:addons => Plugins" and about:plugins : 2. APCDM's decoder properly works for MP4 HTML5 video; e.g., first test clip on https://tekeye.uk/html/html5-video-test-page (1: HTML5 MPEG Video Test) B. By simply updating to the next Serpent 52 build, 2019-11-22, one discovers that it's the first bad one, since: 1. WVCDM magically vanishes from both "about:addons => Plugins" and about:plugins : 2. APCDM, while still present in both "about:addons => Plugins" and about:plugins, simply quits functioning as a h264/aac decoder (as reported by dencorso): @Mathwiz : Could you be so kind as to confirm my tests, preferably on Win7 where Widevine CDM is visible (thanks in advance ) ? ====================================== Now, examining more closely related code, MCP did remove APCDM support in official Basilisk in UXP #1259 ; the bulk of the patches would have landed in the 2019-11-15 build, as per but you did revert those (more accurately, did not apply at all in your custom branch), as per ... furthermore, the reversion has been successful, as the 2019-11-15 build is, according to my analysis above, the LAST GOOD one The MCP devs did not revisit issue #1259, except for https://github.com/MoonchildProductions/UXP/pull/1293 (Adjust Widewine strings after removing Adobe Primetime support) and thus https://github.com/MoonchildProductions/UXP/commit/36c81a9 This would have normally landed in the 2019-11-22 build of Serpent 52: while you did not technically revert that, you added your own version with a slightly modified code: https://github.com/roytam1/UXP/commit/e50e93c Since I'm not a code wizard by any stretch of the imagination, I can't be certain that the culprit for the issues reported here lies within that commit of yours... What is absolutely certain is the offending changeset(s) lives inside the changelog (in your custom UXP branch) between Serpent build 2019-11-15 and build 2019-11-22 ; please, at your discretion, investigate further ... Because, while you took the extra effort to keep APCDM support inside Serpent 52 alive (against MCP's agenda), not only did we end up with a crippled APCDM installation, but also Widevine took an unexpected hit and did a disappearing act... Thanks for your time reading this long report, hopefully you'll get it sorted out! Many thanks, as ever, for providing your forks to the community! Best regards

tested with success: SumatraPDF 3.2.11582 gpu-z 2.28 3dyd 1.17.2. The videos only play audio with old media players like MPC-HC 1.7.13. With current potplayer and gomplayer playing is good Minitool Partition wizard 11.6 free Roboget 0.5 http://www.desksoft.com/Products.htm Winntsetup 4.0.1

But if it only happens several weeks apart, most probably on wednesdays and fridays only, and if there is a full moon when you close Chrome, and only if you do so at the exact moment when the time hundreth seconds are odd, then it is a meta-para-pseudo connection , it has to do and it has nothing to do with the patch at the same time, hence should be classified primarily under the "voodoo" tag. jaclaz

Edited first post, it should now be clear. - Supports all Intel USB 3.1 XHCI controllers (7, 8, 9, 100, 200 and 300 series, maybe even HEDT chipsets).

Same here; IMHO, I don't think that would be cause for any breakage... I checked AniView specifically: Update checks are made via the CodeDead.UpdateManager.dll file; in https://github.com/CodeDead/AniView/commit/2e9cb99 it appears it is accessing the following URI: https://codedead.com/Software/AniView/update.xml That one correctly loads in Serpent 52.9.0 through TLS v1.2: <Update> <MajorVersion>1</MajorVersion> <MinorVersion>5</MinorVersion> <BuildVersion>3</BuildVersion> <RevisionVersion>0</RevisionVersion> <UpdateUrl>https://codedead.com/Software/AniView/AV_setup.exe</UpdateUrl> <InfoUrl>https://codedead.com/?p=2217</InfoUrl> <UpdateInfo> Version 1.5.3 is now available! Please click the download button to download this version. </UpdateInfo> </Update> ... but DOESN'T LOAD in IE9 (TLS v1.2 enabled) https://www.ssllabs.com/ssltest/analyze.html?d=codedead.com&s=185.94.230.248&latest shows that the server is configured to ONLY connect through TLS v1.2 with only 4 cipher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128 ... NONE of which are supported in IE9 "CodeDead.UpdateManager.dll" loads system network+crypto resources to access that URI (dependency walker reveals it loads, among many others, crypt32.dll, wininet.dll, secure32.dll, cryptui.dll, ieui.dll, ncrypt.dll, bcrypt.dll), so it appears it can't establish the secure connection that way and aborts... As per my analysis above. at least AniView.exe+CodeDead.UpdateManager.dll require just TLS v1.2; as for more testing, I'd be curious to know whether its "Update Check" feature works OK with .NET FW 4.8 on Win7+; if not, the developer should be made aware... Best regards

Because of then Ven/Dev. If you google a bit, you will find lists like these: http://www.doc.ic.ac.uk/~svb/CS/Lab/Minix 3.1.0/drivers/libpci/pci_table.c Search in this list for 3059 only.

no. https://en.wikipedia.org/wiki/Predication_(computer_architecture)#History

@dencorso Done! Was about to post this on Win-Raid, but I believe this forum has more Vista diehards!