My Browser Builds (Part 5)

[NotHereToPlayGames]

If you ***REALLY*** want your video playback looked into, it's kind of ON YOU to do some LEGWORK in NARROWING IT DOWN.

*Shoot the messenger* all you want.  But that really is the reality of the situation.

We (you!) need to tell roytam "playback WORKS in this month-day-year release, but it is BROKEN one week later with the month-day+7-year release".

[Goodwin]

21 hours ago, NotHereToPlayGames said:

video playback

I'm not a developer. If roytam1 is a professional, he should look for the causes of the bug and the browser version himself, not send users who do not understand many technical issues to do it.
It would be very funny if when reporting a bug in firefox, mozilla would say "you look for the problem yourself, we don't know anything".

[NotHereToPlayGames]

<del, nwi>

Edited Friday at 02:59 AM by NotHereToPlayGames

[NotHereToPlayGames]

<del, nwi>

Edited Friday at 02:59 AM by NotHereToPlayGames

[roytam1]

11 hours ago, Goodwin said:

I'm not a developer. If roytam1 is a professional, he should look for the causes of the bug and the browser version himself, not send users who do not understand many technical issues to do it.
It would be very funny if when reporting a bug in firefox, mozilla would say "you look for the problem yourself, we don't know anything".

Those builds are originally for my private use and they are released because of my goodwill that I think they may help others.

This bug doesn't affect me and so I don't have big intention on hunting and fixing it.

If you want this to be fixed you at least need to find when the problem started to occur.

and last but not least, stop gaslighting.

Edited Friday at 06:53 AM by roytam1

[Nicholas McAnespy]

@Goodwin @roytam1 I'm not a professional, I just compile Mozilla based browsers for my personal use and hope for the best. For instance, I'm trying to compile Firefox 13+ with Windows 2000 compatibility. One thing that sometimes (but not always) causes runtime execution failure is clicking on tools -> options -> applications which can cause an error in MSVCR71.DLL. Also, after reverting the commit that broke Windows 2000 compatibility, I had a minor problem that is caused by opening a new tab, and the message displayed on the new tab page was relating to an invalid address. That annoyance was caused by the commit for Mozilla bug 728429, which mandated ASLR on Windows. In order to find that, I had to cherry-pick a range of commits between the one that broke Windows 2000 compatibility, and the one mandating ASLR, then compile the source code a few times to narrow down my search. The point is, if a problem does not exist in one of roytam1's browser builds, then exists on a later browser version, the right thing to do is find out what the last good version, and the first bad version is, then it would be easier to find when the problem started, and what commit caused it. Also, it is possible a bug might not affect everybody.

[Goodwin]

10 hours ago, roytam1 said:

Those builds are originally for my private use

 I appreciate your work, so no offense.

I downloaded your first version basilisk52-g4.1.win32-git-20180224-dc7ceccf8-xpmod it already has this defect.
And to check it is enough even just to throw mp4 file on browser tab and change playback speed in player.

While checking noticed that for example in basilisk52-g4.1.win32-git-20180224-dc7cececcf8 CPU load during normal playback is lower than for example basilisk52-g4.6.win32-git-20200725-4d76d4e-uxp-1e0bb1d35-xpmod. The difference is very small, 2-5%.

In general I realized that you do not want to fix or can not, too bad.

[Leokids123]

9 hours ago, Nicholas McAnespy said:

@Goodwin @roytam1 I'm not a professional, I just compile Mozilla based browsers for my personal use and hope for the best. For instance, I'm trying to compile Firefox 13+ with Windows 2000 compatibility. One thing that sometimes (but not always) causes runtime execution failure is clicking on tools -> options -> applications which can cause an error in MSVCR71.DLL. Also, after reverting the commit that broke Windows 2000 compatibility, I had a minor problem that is caused by opening a new tab, and the message displayed on the new tab page was relating to an invalid address. That annoyance was caused by the commit for Mozilla bug 728429, which mandated ASLR on Windows. In order to find that, I had to cherry-pick a range of commits between the one that broke Windows 2000 compatibility, and the one mandating ASLR, then compile the source code a few times to narrow down my search. The point is, if a problem does not exist in one of roytam1's browser builds, then exists on a later browser version, the right thing to do is find out what the last good version, and the first bad version is, then it would be easier to find when the problem started, and what commit caused it. Also, it is possible a bug might not affect everybody.

No offense but where's the Retrozilla 2.3 changes for Crescent-Vine,and also,where's the pull request you said you would merge?

[roytam1]

5 hours ago, Goodwin said:

 I appreciate your work, so no offense.

I downloaded your first version basilisk52-g4.1.win32-git-20180224-dc7ceccf8-xpmod it already has this defect.
And to check it is enough even just to throw mp4 file on browser tab and change playback speed in player.

While checking noticed that for example in basilisk52-g4.1.win32-git-20180224-dc7cececcf8 CPU load during normal playback is lower than for example basilisk52-g4.6.win32-git-20200725-4d76d4e-uxp-1e0bb1d35-xpmod. The difference is very small, 2-5%.

In general I realized that you do not want to fix or can not, too bad.

if it happens in beginning then there is no clue how to fix it.

[roytam1]

New build of Serpent/UXP for XP!

Test binary:
Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20251206-3219d2d-uxp-e4afc5655b-xpmod.7z
Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20251206-3219d2d-uxp-e4afc5655b-xpmod.7z

source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom

IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20251206-3219d2d-uxp-e4afc5655b-xpmod-ia32.7z

source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32

NM28XP build:
Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20251206-d849524bd-uxp-e4afc5655b-xpmod.7z
Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20251206-d849524bd-uxp-e4afc5655b-xpmod-ia32.7z
Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20251206-d849524bd-uxp-e4afc5655b-xpmod-sse.7z
Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20251206-d849524bd-uxp-e4afc5655b-xpmod.7z
Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20251206-d849524bd-uxp-e4afc5655b-w7plus-avx2.7z

Official UXP changes picked since my last build:
- Issue #2489 - fix `color-mix` implementation. (103bd151c8)
- Issue #2847 - Update tests and toolkit CSS to account for `windows-win11` (becf65d05a)
- Issue #2869 - Make Purple Buffer additions check if cell is tenured. (34d1d5a650)

No official Pale-Moon changes picked since my last build.

No official Basilisk changes picked since my last build.

My changes picked since my last build:
- layout: restore xp theme names in test (c80b9fc1ea)
- ffvpx: update ffmpeg to 3.4.14 ( https://github.com/FFmpeg/FFmpeg/commit/9983d098ff0ee54bc3b77676dd885883bfbe4ffb ) (83cd56dfbb)
- nss: update certdata and bump ckbi version to 2.82 (d8a03301d4)
- dns: update effective_tld_names.dat from https://publicsuffix.org/list/public_suffix_list.dat (e27800bb2a)
- icu: update timezone data (cb88bccc0a)
- security: update EV root data (c417312184)
- icu: import backport of ICU-20558 (Fix regression in DateTimePatternGenerator) (dc67193fba)
- icu: if langTag is empty, point it to root.txt as well (9e8e5fbd83)
- icu-data: regenerate with icu_sources_data.py (e4afc5655b)

Update Notice:
- You may delete file named icudt*.dat inside program folder when updating from old releases.

* Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

[roytam1]

New build of BOC/UXP for XP!

Test binary:
MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20251206-40a79c75-uxp-e4afc5655b-xpmod.7z
BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20251206-40a79c75-uxp-e4afc5655b-xpmod.7z

source repo (excluding UXP): https://github.com/roytam1/boc-uxp/tree/custom

* Notice: the profile prefix (i.e. parent folder names) are also changed since 2020-08-15 build, you may rename their names before using new binaries when updating from builds before 2020-08-15.

--

New build of HBL-UXP for XP!

Test binary:
IceDove-UXP(mail) https://o.rthost.win/hbl-uxp/icedove.win32-20251206-id-656ea98-uxp-e4afc5655b-xpmod.7z
IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20251206-id-656ea98-ia-c642e3c-uxp-e4afc5655b-xpmod.7z

source repo (excluding UXP):
https://github.com/roytam1/icedove-uxp/tree/winbuild
https://github.com/roytam1/iceape-uxp/tree/winbuild

[roytam1]

New build of post-deprecated Serpent/moebius for XP!
* Notice: This repo will not be built on regular schedule, and changes are experimental as usual.
** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions.

Test binary:
Win32 https://o.rthost.win/basilisk/basilisk55-win32-git-20251206-23f410065-xpmod.7z
Win64 https://o.rthost.win/basilisk/basilisk55-win64-git-20251206-23f410065-xpmod.7z

repo: https://github.com/roytam1/basilisk55

Repo changes:
- import from UXP: Issue #2489 - fix `color-mix` implementation. (103bd151) (1791c6a30)
- import from UXP: Issue #2847 - Update tests and toolkit CSS to account for `windows-win11` (becf65d0) (bb4464dfb)
- import from UXP: Issue #2869 - Make Purple Buffer additions check if cell is tenured. (34d1d5a6) (be165adf3)
- ffvpx: update ffmpeg to 3.4.14 ( https://github.com/FFmpeg/FFmpeg/commit/9983d098ff0ee54bc3b77676dd885883bfbe4ffb ) (c182ca3c9)
- nss: update certdata and bump ckbi version to 2.82 (db7a51891)
- update timezone tld and ev root data (58e09f3c7)
- icu-data: regenerate with icu_sources_data.py (868997718)
- icu: import backport of ICU-20558 (Fix regression in DateTimePatternGenerator) (72c196bdb)
- icu: if langTag is empty, point it to root.txt as well (23f410065)

[Goodwin]

On 12/6/2025 at 2:51 AM, roytam1 said:

no clue how to fix it

Maybe the problem is in the splitter. You have updated ffmpeg 3.4.14, the new version of ffmpeg will not necessarily work better than the old one. You might want to try older versions of ffmpeg from 2009. They may work even faster. Because the new ffmpeg is very much oriented to 64 bit and windows 10. The ffmpeg developers are sponsored by donations from google and microsoft related entities.

Also, if possible, I recommend you look up the answer in Centaury's code https://github.com/Feodor2/Centaury/releases

Edited 53 minutes ago by Goodwin

[NotHereToPlayGames]

I really think it is time for you to stop festering roytam over your YouTube playback issues.

Roytam has replied and you keep festering, festering, festering.

@Dave-H - can you please add this to your "watch list"?