Leaderboard

(Sorry, didn't have time to respond to this before.) I agree with your general point, but I'm not sure how much Google is to blame in this particular case. The thing is, programmers often tend to be pretty lazy when having to do maintenance tasks, because these aren't seen as "cool" and "innovative"... And this bug is a bit of a special case, because it takes almost 30 min to run a single test case, whether you're trying to track down where the regression originated, or trying to fix it. Let me give you a rough rundown of the process I went through with this (let's skip this long story for them normal people ; and this isn't about me looking for extra credit, honest! ) OK, so now consider that during virtually every step of this, you have to run a whole lot of 30 min (or longer) tests to make sure of your guesses or fixes. I am, of course, a great guy and all , but even with my highly vested hobbyist interest in solving this issue it took me several months to get through this all. Obviously not months of straight work on this alone, and obviously I didn't just sit around gaping at the screen every time I ran a test, but started the test and then did something else while it ran, but the whole thing still took time. Now, imagine I was an elite coder working at Mozilla , and generally supposed to work on some other stuff besides this. And, let's say you were my manager. Are you sure you'd let me spend all this time on this one, apparently (but really not) intermittent issue that seems to be affecting only a few people (really affecting all, but 99.99% of those people wouldn't put 2 and 2 together and notice the very specific interval and would instead write these freezes off as internet issues or whatever else) on a "legacy" OS that doesn't have that long to live anyway (or so you think, not knowing about POSReady, and MSFN )? And would I, an elite Mozilla engineer , want you to make me spend my precious time on something like this? I mean, even without the whole Windows driver dive and leak hunting thing they obviously wouldn't get into (the leak hadn't happened yet, either), it's a lot of work that isn't "cool", nor "innovative"! This is not to say that I excuse the fact that they don't even run tests for longer playback, etc., etc. We all know Mozilla has lots of problems with their attitude and policies, and there are many things they aren't doing that they should be doing (and vice versa). I definitely do blame them for letting this fall through the cracks and not doing more to fix this. But as far as Google goes, since they probably weren't using cubeb, maybe they themselves never ran into this bug (at least its more obvious, 2x:xx version), and since this isn't an issue specific to Youtube, I think I wouldn't blame them too much for this one. But there is Microsoft, who introduced this bug in the first place with that pretty dumb coding error...

LGTM will commit it in short period. EDIT: committed in goanna3 and 4 repo, other repos will be followed later. https://github.com/roytam1/UXP/commit/85149582f1000cd801350ebaa73151872c521d4f https://github.com/roytam1/palemoon27/commit/2d96070f5334a82b3cb3133c822b8ae5a372c411 https://github.com/roytam1/mozilla45esr/commit/bf2771bde24a18e3ab13ead251befca1ac630d7b https://github.com/roytam1/basilisk55/commit/6fd60b08fe3f33fc0c7245427a25251dd6008690 https://github.com/roytam1/palemoon26/commit/a66d2e44121f0684044f86abed116dc1d686d17f

Cool, thanks! And you even gave (ample!) proper credit and everything, quite unlike the "thieving hacker" image certain folks at MCP like to project of you, lol!

Let's see here... Looks like my latest Centaury build uses roughly 6.2 GB altogether, 1.4 GB for the source and 4.8 GB for the "object directory" with build results. This is a release build, debug would be somewhat larger - so let's say 7-8 GB in total. MozillaBuild is roughly 0.8 GB. The full DirectX SDK is 1.2 GB installed (although you really only need a few MB from it). For Windows 10 EWDK based builds (like @feodor2 does them) the EWDK .iso (that you can mount as-is) is 6-9 GB depending on version (getting bigger), but you don't have to install VS and the Windows SDK, so you can still save quite a bit that way. It was pretty funny to see Moonchild arrogantly lecture feodor2 that he didn't "understand how software in general works" because feodor2 didn't want to install all the extra bloat that comes with VS, whereas Mozilla have been using stripped down tools packages since well before Firefox 52.0 that UXP is based on (see the history of their toolchain packaging script). (OK, so they do the install once, but then package the components they actually need and use that package for subsequent builds.) If you did that (installed, repackaged, uninstalled) with the current official MCP requirements for Pale Moon/Basilisk, you'd end up with only 1.3 GB for all the required VS and SDK stuff, huge space savings! You're very welcome Since I don't plan on distributing my own builds publicly, I guess you'll have to wait until @roytam1 and/or @feodor2 merge this into their builds, so quite possibly only until this week-end for Serpent (although they'll likely want to spend a bit more time testing this on their own). You'd need to rebuild the whole application, replacing media/libcubeb/src/cubeb_winmm.c in the source code. Unfortunately this is not something that can be applied "on-the-fly".

Actually YouTube offers several format options for 720p. Format 22 is a single file. E.g. for this video (found formats with yt-dlp, using the following command): yt-dlp -F https://www.youtube.com/watch?v=I79CQUTO5II 22 mp4 1280x720 30 | 852k https | avc1.64001F 852k mp4a.40.2 0k 44100Hz 720p 136 mp4 1280x720 30 | 89.77MiB 723k https | avc1.4d401f 723k 720p (throttled), mp4_dash 247 webm 1280x720 30 | 88.94MiB 716k https | vp9 716k 720p (throttled), webm_dash 398 mp4 1280x720 60 | 108.10MiB 871k https | av01.0.08M.08 871k 720p60, mp4_dash 480p however has only Dash: 397 mp4 854x480 30 | 42.61MiB 343k https | av01.0.04M.08 343k 480p, mp4_dash 135 mp4 854x480 30 | 29.41MiB 236k https | avc1.4d401f 236k 480p, mp4_dash 244 webm 854x480 30 | 32.46MiB 261k https | vp9 261k 480p, webm_dash But note "throttled" in the above output. Maybe that can be the culprit? cc @we3fan

I guess this is my cue to stop procrastinating and finally post the fix I made for this I've had a few people test it for 4 months now on all kinds of sites on both XP x86 and x64, and the jury says this indeed fixes the 2x:xx video stoppage issue and doesn't seem to introduce any new problems. I honestly didn't intend for the testing period to be quite this long, but summer heat can have a detrimental effect on one's brain and thus plans. Since my own browser builds are based on Centaury, but I still consider myself a (lurking) MSFN patriot and this is the home of @roytam1's Serpent, I'm just going to post the fixed media/libcubeb/src/cubeb_winmm.c on Pastebin to avoid playing favorites (and signing up on Github ) I'm not sure how often @feodor2 visits here these days, so maybe someone on Github could mention this in https://github.com/Feodor2/Mypal/issues/1 if he doesn't pick this up soon enough. What has been tested: MP4/VP9/VP8 (and plain audio MP3/etc) streaming/local chunked/single-file sped-up/slowed-down 27+ hrs long playback (see the technical details for why) Youtube/Twitter/Facebook/Instagram/TV station streams/etc/etc (nor did we forget p0rn/pirate sites, which of course are no different from a technical POV... ). Among other things, a 75-year old lady watched the entirety of Prince Philip's funeral with this fix in effect and had no complaints. What has NOT been tested: Pale Moon-based builds (as opposed to Basilisk), because I don't use NM or Mypal. Since this is a UXP platform level fix, the front-end should have no effect. I obviously don't have access to every sound card out there, but since the MS driver causing these problems should be common in all configurations, I'd expect the fix to work with pretty much every card. new-fangled formats like AV1 (I'd expect them work, though). DRM-ed streams, since no Widevine on XP (but again, this should work with those as well if DRM itself worked). @roytam1, @feodor2 I didn't create a preference for turning this fix off, because it turned out the normal pref system is no longer compatible with C code, and once it became evident enough that the fix was pretty solid, I didn't feel like hacking something together to make preffing work for a library-level change like this. You're welcome to pref it, of course, but based on the length of testing with no issues discovered, I dare claim it's safe to include without a pref. Here's a general overview of why this problem was happening (you may be surprised ): And, some more technical specifics, incl. about where the 2x:xx times come from (this is also included as a comment in the source code): EDIT: Writing this up amply reminded me how much I LOVE making long posts using this board's post editor... BBCode FTW!

I suppose this is related issue and if I understand and see correctly, you get the same behavior as in older versions if you check Unrestricted CSS in extension settings under General->Default (and Untrusted if you've added sites under that preset), effectively turning the new CSS related feature off. https://github.com/hackademix/noscript/issues/195

512 MB, is still ok, with more you need to patch io.sys to enable Windows 98 safe mode boot. 1) Which parameters are you using and which error you are getting, when EMS tried to activate? EMS need i thing 32 KB free continual block of memory and it could get tricky. EMS is able to max 32MB what is enough for all original Dos games. 2) It really depends on system and its Bios design.. mainly videocard rom is glutton.. network card rom and capture cards can eat conventional memory too. To check what is eating memory and how big and ROMs use Checkit program (Memory map option).. and Navratil System info - Video for Videomemory size.. and next is Mem /d .. and Mem with other parameter which im not know from top of my head. Good is have videocard which is easting only 32 KB, with more its more complicated. I have thread about romsize with some reports, even card manufactor sometimes make difference: https://www.vogons.org/viewtopic.php?f=63&t=61451 3) With such amount of information i cant help you, which mainboard you have and which sound card.. Otherwise make some new thread for you problems.. I asked here for Dos section for years and i even offered big donate for it.. so you have to place is somewhere in offtopic section or so.

Just to answer - I experience a ~16s freeze but I don't want to lower quality because of that, so 4GB of RAM doesn't help really. As @mixit said it's an audio bug in the library... I have 4GB of RAM and a GTX 980 video card with SBAudigy2 and this should be enough for all my audio and video needs up to 1080p60fps (though I use 1680x1050 screen) and it works and now this fix - wow - something to look for in the next Serpent build. Mighty fine. Hallelujah!!! Now this is resolved! I'm very thankful for your time in fixing and testing and providing a fix, @mixit, for our favorite browser and of course @roytam1 for implementing it in all XP browsers! WOOHOO! SuperSweet! Shaderlicious and such.

... Continued here, as being OT for this thread...

... Picking up from a "relevant" WinXP thread/post The first (v13.0.1) of the v13 series is also the last built on .NET FW 4.6.2, so with 4.6/4.6.1 installed on Vista SP2, I expect this specific (portable) version of ShareX to have the best compatibility with such an "installation scenario" (i.e. Vista SP2+.NF461) ; as noted previously, you'll have to modify the ShareX.exe.config file (adjacent to ShareX.exe) for the app to even launch: v13.0.1 sports a new dark theme (over previous v12.4.1) and generally, in my limited testing, works as expected (including update checks); one thing that doesn't work is the ffmpeg.exe binary auto-download (you should get a confirmation dialogue when selecting "Tools -> Video thumbnailer"), because versions before 13.2.1 were hardcoded to fetch from the now defunct Zeranoe builds repo (see attachment) ... In any case, that Zeranoe ffmpeg build was not Vista-compatible ; to rectify these issues, download manually a Vista-compatible ffmpeg.exe binary and place inside the following directory: "PortableRootDir\ShareX\Tools\" On launch, the app should pick up the existence of the binary and an entry should be created inside file "PortableRootDir\ShareX\Tools\ApplicationConfig.json", in my case, it's "FFmpegOptions": { "OverrideCLIPath": false, "CLIPath": "G:\\PortableApps\\ShareXPortable\\ShareX-13.0.1-portable\\ShareX\\Tools\\ffmpeg.exe", Because I was feeling adventurous , I decided to also test the latest ShareX version, i.e. v13.5.0; as @Vistapocalypse correctly pointed out here, this is built on .NET FW 4.7.2 (not 4.6.2), so I was quite curious to explore the possibility of it running on already installed 4.6.1 ; after, again, modifying ShareX.exe.config file (4.7.2 -> 4.6.1), I was surprised but pleased to discover the app did launch : Update checks do still work (the app reports it's up-to-date), as most other aspects of the program, but I must admit I haven't tested extensively... In contrast to 13.0.1, ffmpeg.exe auto-download works (it is now fetched, as a zip file, from a dedicated ShareX GitHub repository), but installation fails under my setup , because the extraction of the ffmpeg.zip file is delegated to functions only found on .NET FW 4.7.2+; the downloaded (zipped) binary is a saved copy of a ffmpeg-4.3.1-win32-gpl Zeranoe build, not launching under Vista (because of libx265 NUMA code), so it wouldn't accommodate even if extraction succeeded ; the "manual" installation route has to be followed here, too... What was the initial reason the devs dropped official Vista (and XP) support? Well, "they" had stated that on Vista update checks wouldn't be possible... So glad the Vista community proves them wrong!

Thanks for the detailed answer, @mixit I already have VS 2019 and DirectX SDK installed, part of the reason i'm left with less than 40GB space on the C: drive, lol. Hopefully using another drive won't mess things if/when i try building something bigger (like a browser) sometime in the far future. Still no clue what i'm doing in that damn IDE, especially when a project won't build as is, but needs some fixing first. A simple "make config / make install" or the Arduino IDE come a lot more easier. P.S. there is HttpDisk, which allows mounting iso and disk images over the internet, no need to download several GBs to extract only a few files.

WinClient5270 listed ShareX Portable support for Vista as ONGoing, but noted that it Requires installation of Microsoft .NET Framework 4.6.2, which requires special procedures to install on Vista (unlike 4.6.1). In fact https://getsharex.com/changelog/ states that the .NET requirement was upgraded to 4.6.2 beginning with version 12.1.0 in March 2018, so you are fortunate if 12.4.1 functions well with .NET 4.6.1. The changelog also says the .NET requirement was again upgraded about a year ago to 4.7.2 beginning with version 13.2.0, which might also be doable on Vista.

... This isn't actually true , and it has been covered already in the Vista subforums (but am now lazy to track down that post...) . Unlike WinXP SP3 x86, for which the last supported .NET FW version is 4.0.3, Vista SP2 x86 can natively (though unofficially...) support up to .NET FW 4.6.1 (official support stops at v4.6.0) ; below is a screengrab from my Vista SP2 32-bit laptop, running happily ShareX 12.4.1 portable: The trick is to modify L4 of the ShareX.exe.config file so as to read: <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" /> (.NET FW 4.6.1 has to be installed, of course... ) ; and if you are to use ShareX functions requiring FFmpeg, then you have to swap the provided ffmpeg.exe binary (requires Win7+) with a Vista-compatible one ; FWIW, as can be seen, Update Check works as expected ! BTW, I haven't tested any of the ShareX v13 series yet...

CM_Get_DevNode_PropertyW is natively supported on Vista. What version of CfgMgr32.dll is installed?

... Freedom of expression? My... behind! (pardon my French ... Pun intended, as OPer is from France ). Loading the linked URI in latest Serpent 52.9.0 32-bit, I'm seeing the following: ShadowRoot is part of Google Chrome's WebComponents framework... Shaka Player is a Google-owned web player framework, in the posted screengrab it's looking for EME (Encrypted Media Extensions), i.e. DRM support (aka WidevineCDM, another Google "asset" ) in the browser... Finally, apart from the CORS issue spotted by @roytam1 , the site produces two more errors: To sum up, this is yet another site coded in a way to cater exclusively to latest Chrome and variants ; I wouldn't call this "freedom", would you? (at least where user freedom to choose a browser is concerned... ); in the same vein, citing that 360EE and (Chr)Edge can handle the site/web player fine is a redundant thing to say; the web of 2021 revolves solely around Chrome, period...