Release T4b

[pannal]

p3i T4b

Important

Files updated. The first build did not include the latest changes. Make sure you're running T4b_20260704001258.

T4b is a small follow-up/hotfix release on top of T4a. It fixes a rare DTS case that could mute audio and adds a brightness boost for VS10's DV/HDR10→SDR conversion that actually works, plus a couple of smaller things. The work is mostly in Kodi and the kernel, with a bundled-skin bump and a German-translation resync alongside; coming from T4a, it's a low-risk update.

The headline changes:

• Fixed a rare case where DTS with dialnorm played silence on strict AVRs and soundbars (the T4a dialnorm defeat wrote a bad CRC).
• New "Boost VS10 SDR output brightness" control: DV and HDR10 converted to SDR no longer have to look dim, with an Auto mode that lifts as far as possible without clipping.
• New opt-in sub-setting to apply the green-flash hold to Dolby Vision only, so other content restarts without the brief blank.
• Smaller: bitmap-subtitle zoom down to 10%, and a full German (de_de) translation resync.

---

Highlights

1. Fixed a rare DTS-with-dialnorm case that could mute audio

T4a added DTS/DTS-HD/DTS:X dialnorm defeat (on by default), but the DTS-HD extension-substream header CRC was recomputed with a lookup table (AV_CRC_16_CCITT) that isn't compiled into Kodi's libavutil. The call returned garbage, so the rewritten header carried an invalid CRC. Strict AVRs and soundbars rejected the extension and played silence, while lenient decoders (and the offline validation, which used a correct CRC) were fine. So it was rare on two counts: it only hit strict decoders, and only on the uncommon DTS-HD / DTS:X titles that actually carry a dialnorm value in their extension substream. Frames without dialnorm never recompute the CRC, so they were never touched.

T4b computes the CRC itself (CRC-16-CCITT, poly 0x1021), and the output is byte-identical to a known-good reference stream. If DTS-HD MA went quiet for you on T4a, this is the fix. You can also just turn the defeat off under Settings/System/Audio.

2. Boost the brightness of DV/HDR10 → SDR conversion

DV and HDR10 tone-mapped to SDR through VS10 look dim next to the GUI and native SDR content. T4b adds a control that lifts it: "Boost VS10 SDR output brightness" (Settings/System/CoreELEC, under the DV settings: Off / Auto / Manual, default Off).

It works on the source side. The Dolby tonemapper builds its curve for the source's declared mastering peak, and most content never comes close to that number. All the headroom between the actual content peak and the mastering peak is picture range thrown away. Cap the declared peak and the tone curve spends the SDR range on picture instead.

• Auto assumes the source peaks at its actual content peak (MaxCLL) instead of the mastering display peak — the strongest boost that cannot clip, since the headroom above the content peak is unused by definition. For DV titles without an L6 metadata block it falls back to the base layer's HDR10 SEI CLL; with no usable peak metadata it does nothing.
• Manual sets a ceiling on the assumed source peak ("Maximum source luminance", 100–4000 nits). Titles below the ceiling keep the full no-clip Auto boost; brighter titles are treated as peaking at the ceiling, and their content above it clips. Lower is brighter. The ceiling is also used directly for titles without peak metadata, which Auto alone can't help.

HLG sources are not affected: the Dolby library substitutes its own internal peak assumption for HLG, so no lever exists on that path (proven on-device).

Validated on-device with Dunkirk (4000-nit mastering, 323-nit content peak): Auto lifts it, Manual 400 matches Auto, Manual 200 is brighter still. This control replaces the T4a "VS10 SDR target luminance" slider, which an on-device A/B proved the Dolby library ignores outright (10 and 4000 nits gave identical output); that setting could never work and is gone.

3. The green-flash hold can now be limited to Dolby Vision

T4a added an on-by-default black hold that hides the brief green flash on the video plane at the start of playback and on seeks. It blanks the picture through the decoder restart until the first clean frame arrives, which means a moment of black on every start and seek. T4b lets you apply that hold to Dolby Vision streams only, so everything else restarts without the blank. The new sub-setting is coreelec.amlogic.video.restart.mute.dvonly (default off, so nothing changes unless you turn it on); the seek-edge settle, which only runs while a hold is engaged, follows the same gating.

4. Also in T4b

• Bitmap subtitle zoom down to 10%. The minimum zoom for image-based (PGS/VobSub) subtitles drops to 10%, so oversized bitmap subs can be shrunk much further.
• German translations resynced. A full de_de resync against the current English strings, in both Kodi and the CoreELEC Settings addon. Kodi discards a translation when its stored English source no longer matches the live string, so after all the T4a/T4b setting reworks some German labels had fallen back to English — this brings them back.

---

Known issues

Denon / Marantz AVRs: black screen or "no signal" on HDMI mode switches

This is not new, and we did not introduce it. It happens on stock (vanilla) CoreELEC too, not just our builds, and goes back well before T4. It is a long-standing AVR-side issue, not a p3i regression.

On some setups with a Denon or Marantz AVR between the box and the TV, the TV can drop to black or "no signal" around an HDMI mode or format change: a title starting, a resolution or refresh switch, or playback entering or leaving Dolby Vision. We have not been able to pin down exactly what sets it off; it may be any mode switch. The only reliable recovery is to power-cycle the AVR (sometimes the TV too).

In every captured failure the box was still putting a valid signal on the wire (correct timing, valid AVR EDID), but the AVR stopped forwarding it to the TV. The same box plays the same content cleanly straight into a TV, and through other AVRs and soundbars. Because the trigger is downstream of the box, no setting in the build fixes it. What does help is on the AVR side:

• Set the AVR's HDMI input Signal Format (the "4K/8K Signal Format" option) to Enhanced. This is the classic Denon/Marantz 4K-black fix.
• Update the AVR firmware.
• To test or work around it, bypass the AVR: run the box straight into the TV and take the audio back over eARC.

VS10 SDR can drop video on some live-TV streams

On some live-TV sources (IPTV Simple Client / inputstream.adaptive and Tvheadend), VS10 SDR conversion sometimes fails to put out video when a stream starts. You get a black screen while the GUI still works: you can open the OSD and the menus, there is just no picture. This is not the HDMI/AVR blackout described above.

Disabling VS10 SDR avoids it entirely. It looks like a timing issue at live-TV start; we are still looking into it.

---

Changelog

Everything since T4a.

xbmc / Kodi (9 commits)

• 08e05ea953 Subtitles: allow bitmap subtitle zoom down to 10%
• bc189bc9aa Lang: de_de — full resync against en_gb
• 6c110988bf DV: SDR brightness boost — drop the HLG claims from the help texts
• fd16e005a0 DV: refresh the SDR brightness boost param on every DV engage
• 9ee4b773d4 DV: replace the dead VS10 SDR target nits with a source-peak brightness boost
• 4481df935b DV: VS10 SDR target nits — fix no-op param write, move below VS10 DV (superseded by the boost above)
• 7c5e6cbc53 AMLCodec: add a DV-only sub-setting for the green-flash video hold (default off)
• f5a1e63b05 DV: fix the VS10 SDR target nits setting never showing in the GUI (superseded by the boost above)
• 02169a0bd6 AEStreamInfo: fix DTS-HD MA dialnorm defeat muting audio (bad EXSS CRC)

Kernel (linux-amlogic, 3 commits)

• 07c0670d43 amdolby_vision: SDR boost auto — fall back to BL SEI CLL when L6 is absent
• d762ac4d9e amdolby_vision: add xbmc_dv_sdr_src_max_nits — source-peak cap to brighten →SDR
• 5e664b1a62 amdolby_vision: map extended source formats onto the target_lum_max rows

CoreELEC (distro)

• 9601b29c8d bump the bundled skin.p3i.estuary to 8.8.15
• 4644f095c1 update README, plus the T4b version marker

CoreELEC Settings addon

• 681031c lang: de_de — translate all missing German strings

---

Donations

Installation

Note

Coming from T4a, this is a plain dirty upgrade — your skin and settings carry over and nothing needs resetting. The new "Boost VS10 SDR output brightness" control and the green-flash-hold sub-setting appear on their own. Coming from before T4a, follow the T4/T4a install steps (including the Settings/System/CoreELEC reset) first.

1. Dirty

Drop the update tar into your CoreELEC update folder and reboot.

Should hitting reboot result in a black screen (long-standing issue with any build), wait 10 seconds to make sure this wasn't just a fluke, then unplug and re-plug the device's power. The upgrade will commence afterwards.

2. Dirty (safe)

Drop the update tar into your CoreELEC update folder, shut down the device, pull the power plug for 30 seconds, replug.

3. Flash

Use the provided Flash img.gz to prepare your SD card as you would with any other CoreELEC build.

---

Thanks

A massive shoutout to everyone involved in this build! Special thanks to the testers who flagged the DTS-HD MA audio dropout, and to nissel for the on-device A/B work that proved the old VS10→SDR target a dead end and then dialled in the new brightness boost. Upstream projects this builds on: avdvplus (DV metadata handling), libdovi, libass and FFmpeg, with eac3to as the reference for validating the DTS dialnorm output.

Full Changelog (Kodi core): https://github.com/pannal/xbmc/commits/T4b/
Full Changelog (Kernel): https://github.com/pannal/linux-amlogic/commits/T4b
Full Changelog (CoreELEC): https://github.com/pannal/CoreELEC/commits/T4b
Addon repo: https://github.com/pannal/p3i_repo

Contributors

Sources and contributors whose work landed in T4b:

• nissel — on-device VS10→SDR A/B testing (proved the target-nits path dead, validated the source-peak boost)
• Everyone who reported the DTS-HD MA silence
• CPM / avdvplus (R9) (@cpm-code) — DV metadata lineage
• eac3to — reference for validating the DTS dialnorm output
• libdovi / libass / FFmpeg — upstream projects

---

This discussion was created from the release Release T4b.

[pannal]

Rebuilding, current build didn't include the latest changes

[pannal]

Build updated. Make sure you're using T4b_20260704001258.

[manuelh]

Since things are looking quite stable at the moment, I'd like to humbly suggest another audio feature idea/improvement, with reference/inspiration to https://forum.kodi.tv/showthread.php?tid=318686

It would be very nice to make use of a provenly better audio resampling library than what ffmpeg and thus Kodi uses by default.

At present, the ffmpeg resampler supports either 'swr' (libswresample), which is used by default, or optionally 'soxr' (libsoxr), if specified (e.g. resampler=soxr), and available (i.e. ffmpeg needs to be built with libsoxr)

For proven measurable differences, please visit https://src.infinitewave.ca, and select "ffmpeg 7.1 (swr)" and compare it against "ffmpeg 7.1 (sxor)" across the various test results.

Soxr also has support for multiple resampling engines, as per documentation:

As available on a given system, options for including up-to five resampling
‘engines’ are available (per above) as follows:

WITH_CR32: for constant-rate HQ resampling,
WITH_CR32S: SIMD variant of previous,
WITH_CR64: for constant-rate VHQ resampling,
WITH_CR64S: SIMD variant of previous,
WITH_VR32: for variable-rate HQ resampling.

By default, these options are all set to ON.

When both SIMD and non-SIMD engine variants are included, run-time selection
is automatic (based on CPU capability) for x86 CPUs, and can be automatic for
ARM CPUs if the 3rd-party library `libavutil' is available at libsoxr
build-time.

Additionally:

The libsoxr API structure ‘soxr_runtime_spec_t’ allows application developers
to optimise some aspects of libsoxr’s operation for a particular application.
Optimal performance however, might depend on an individual end-user’s run-
time system and the end-user’s preferences. Hence environment variables are
available to set (override) run-time parameters as follows:

Env. variable        Equivalent soxr_runtime_spec_t item (see soxr.h)
------------------   -----------------------------------
SOXR_COEFS_SIZE      coef_size_kbytes
SOXR_COEF_INTERP     SOXR_COEF_INTERP_xxx
SOXR_LARGE_DFT_SIZE  log2_large_dft_size
SOXR_MIN_DFT_SIZE    log2_min_dft_size
SOXR_NUM_THREADS     num_threads

Additionally, the SOXR_USE_SIMD32 and SOXR_USE_SIMD64 boolean environment
variables can be used to override automatic selection (or to provide manual
selection where automatic selection is not available) between SIMD and
non-SIMD engine variants.

Perhaps some of these variables could also be tweaked for ARM, and specifically for S922X-J use.

Interesting discussion here regarding soxr: https://superbestaudiofriends.org/index.php?threads/hqplayer-vs-sox.11286/, including small patches made to soxr source to increase maximum filter length: https://github.com/rhgg2/sox

Probably a bit more work than usual to realize, but this would be a wonderful improvement for anyone resampling their audio, and would put all current Kodi users forced to use libswresample to shame 👍

[ac16161]

Interested in your thoughts on what's happening here. Most of my HDR10 titles have been processed by DoviScripts to CMv4 DV. Here we have display-led DV (LG C5) and I have a rectangular shadow over the picture. Doesn't do it in player-led DV. I only tried a couple other titles and they were ok. Issue doesn't happen with TV-led DV with my Panny HZ980, much older than the C5. Latest CE22 nightly has the same problem, possibly an LG issue?
https://paste.coreelec.org/PatronsTragic

[nissel]

The photo is of the Panasonic, so I'm not sure why you say it's happening on your LG.

But it looks a bit like a really big incorrect L5 value on the left. Does the player process info show the L5 values? Can you try using the L5 to zero and not source option?

Seeing as you say it happens on CE22 its got to be bad file or a problem with your display.

[ac16161]

Look again - the Panasonic badge is on the soundbar hanging behind the LG :-) Will try the L5 options.

[ac16161]

It looks like the file has a bad left L5 value, been a while since I tried it with TV-led DV, guess the issue didn't manifest before proper L5 support arrived. Evidently something slipped through on this instance of running Dovi Scripts, will fix the file. When I flip the L5 setting to pass through zero all is good. Appreciate the suggestion.

[nissel]

Yeah maybe you had a random L5 text file present when you ran dovi scripts

[Bo0ne]

Hi, I need some help.

After doing a dirty upgrade from T4 to T4a and then to T4b, my dovi.ko got corrupted and I can no longer play DV content.

 # journalctl -l | grep -i dovi
Jul 10 17:26:28 CoreELEC kernel: g12 dovi disable in uboot
Jul 10 17:26:29 CoreELEC dovi-loader[3569]: run dovi 'start' for ng
Jul 10 17:26:29 CoreELEC dovi-loader[3569]: loading '/storage/dovi.ko' module
Jul 10 17:26:29 CoreELEC dovi-loader[3605]: filename:       /storage/dovi.ko
Jul 10 17:26:29 CoreELEC dovi-loader[3605]: license:        AML
Jul 10 17:26:29 CoreELEC dovi-loader[3605]: description:    Amlogic Dolby Vision Driver
Jul 10 17:26:29 CoreELEC dovi-loader[3605]: depends:
Jul 10 17:26:29 CoreELEC dovi-loader[3605]: vermagic:       4.9.y SMP preempt mod_unload modversions aarch64
Jul 10 17:26:29 CoreELEC kernel: dovi: disagrees about version of symbol module_layout
Jul 10 17:26:29 CoreELEC kernel: dovi: module license 'AML' taints kernel.
Jul 10 17:26:29 CoreELEC kernel: dovi: disagrees about version of symbol register_dv_functions

Does anyone know where I can get the right version of dovi.ko again?
I tried the one from here, but it did not work.

[nissel]

The ones in the link are correct. It should have a sha256 hash of 5ffe2348b2e12d682543d275f7282fb43aedfdcc7aaa8339d229ddca6abd130b

[nissel]

I have the same messages in my log and it's working. You probably just need to reset your system / CoreElec settings and reboot. Then check your settings are correct again.

[Bo0ne]

It's fixed. I forgot to reset the CoreELEC settings after the upgrade.
However I still have those entries in journalctl saying CoreELEC kernel: dovi: disagrees about version of symbol register_dv_functions. Is that normal?

[Bo0ne]

Thank you so much @nissel
Appreciate your help.

[PetroDeineka]

Arcane: League of Legends (2021)
DV P7 FEL CM 2.9 to CM 4.0 Always / Smart
I noticed that the black bars at the top and bottom remain black, but the black area behind the subtitles is raised—it is lighter than the black bars above and below.
Previously, the black level was perfect across the entire screen, including the subtitles.
I also noticed a scene in Season 2 where the entire screen is supposed to be completely black. However, with CM 4.0 Always / Smart, the black is no longer true black. With native CM 2.9, it is completely black as intended.

If I output CM 2.9 as CM 2.9, the black around the subtitles is exactly the same black as the bars at the top and bottom.

Ballerina (2025)
DV P7 FEL CM 2.9 to CM 4.0 Always / Smart
The black around the subtitles is the same black as the bars at the top and bottom.

House of the Dragon
P5 CM 2.9 to CM 4.0
Here, the black around the subtitles is also 100% black.

In my opinion, CM 2.9 darkens the image too much compared to HDR10.
On the other hand, CM 4.0 Always / Smart can sometimes make the image look overbright. This may be because the content was color graded with CM 2.9 in mind.
The colors can also shift slightly. For example, in Arcane, orange-red tones became slightly pinkish. The overall contrast is also reduced, which decreases the perceived depth of the scene.
That said, for movies I still prefer CM 4.0 Smart overall.