[EXPERIMENTAL] CoreELEC 22 · samurihl DV build (20260808164352)
Pre-release
⚠️ EXPERIMENTAL · UNSUPPORTED · USE AT YOUR OWN RISK
This is an unofficial, experimental CoreELEC 22 build. It is NOT an official
CoreELEC release and it is NOT a supported CE22 port. I am not a CoreELEC 22
port maintainer, and I will not be providing support, bug fixes, updates, or
ongoing maintenance for this build.
The only purpose of this build is to give Amlogic AM9 Pro-class users a more
complete Dolby Vision experience than stock CoreELEC 22, by carrying a set of
custom Kodi features I built for my own device. That is the entire scope.
READ THIS BEFORE YOU FLASH ANYTHING
- USE ENTIRELY AT YOUR OWN RISK. There is no warranty of any kind, express
or implied. It may fail to boot, misbehave, break Dolby Vision, or do nothing
useful on your hardware. - BACK UP YOUR CURRENT INSTALLATION FIRST. Take a full CoreELEC backup
(Settings → CoreELEC → Backup) and/or image your existing boot media before
you install anything from here. Assume you may have to restore it. - Prefer a SEPARATE SD card or USB stick you can boot from, instead of
overwriting a working internal (eMMC) install. - Do NOT report problems with this build to the CoreELEC team or forums.
This is not their build; it is not their responsibility. Do not ask them to
support it. - I am also not offering support. If it breaks, you keep both pieces.
By downloading or using any file in this release you accept all of the above.
Install
- Clean install (recommended): flash the
*.img.gzto an SD card or USB with
balenaEtcher (or the Amlogic USB Burning Tool for eMMC), then boot from it. - In-place update: copy the
*.tarto the/storage/.updatefolder on an
existing CoreELEC install and reboot. (Back up first — see above.) - Verify your download against the SHA256 sums below before flashing.
What's changed in this update
This is an incremental update to
v22.0-samurihl-20260804163650
(see that release and its predecessors for the standing feature set: Blu‑ray disc
menus, HDR10+ → Dolby Vision conversion, DV → HDR10 that stays in HDR10, FEL
profile‑7 reconstruction on non‑DV displays, VS10 output on non‑DV displays, VSVDB
override, tone‑mapping target controls).
Two audio fixes and one HDR picture‑accuracy fix. If you have an AV receiver,
the first two are the reason to take this build.
⚠️ Still experimental and completely unsupported — see the disclaimer above.
Back up your current install before flashing.Dolby Vision still requires
dovi.ko(the CE22 5.15 build) installed on your
device — it is not bundled; install it yourself as on stock CoreELEC 22.
You do not need to modify it — this build corrects it automatically at boot.
🔊 Multi‑channel PCM soundtracks played as stereo — or silently
The symptom. On the newer Amlogic boxes (S5, S6, T7 — including the Ugoos
AM9 Pro), anything that sends uncompressed multi‑channel audio to the
receiver — a 5.1 AAC track, a 7.1 FLAC, any surround soundtrack Kodi decodes
itself rather than bitstreaming — arrived as two channels. Some receivers
showed "5.1" on the front panel and still only drove the front pair; others muted
the stream outright and you got nothing at all. Bitstreamed formats (TrueHD,
DTS‑HD MA, Dolby Digital) were never affected, which is why this could go unnoticed
on a disc‑heavy setup and then bite the moment you played a plain surround file.
What was wrong. Three separate faults stacked on the same path, and each one
alone was enough to break it:
- The audio was being read from the wrong place. The HDMI transmitter picks
which internal audio block to read from, and it was choosing based on the
format of the soundtrack. Only TrueHD and DTS‑HD MA were pointed at the block
that multi‑channel PCM actually writes to; everything else was pointed at a
block with no data in it, so only the first channel pair ever reached the cable.
It now picks based on the device the audio is playing through, which is what
actually determines where the samples land. - The box announced "stereo" for the first second of every track. HDMI carries
a small descriptor saying how the channels are arranged, and receivers latch the
first one they see and then stop listening. Ours said "front left, front
right" for a window at the start of every stream — up to several seconds,
depending on your refresh‑rate‑change delay setting — while six or eight
channels were already flowing. The channel layout is now established before the
stream starts rather than after. Measured on an AM9 Pro: 100 descriptor samples
taken from the moment playback begins, zero of them wrong (previously 1.2
seconds of them were). - The stream was flagged as professional‑studio audio rather than consumer
audio, at a fixed 48 kHz / 20‑bit regardless of the actual track. Now computed
from the real sample rate and bit depth.
Confirmed working on an AM9 Pro: 5.1 AAC now reports 5.1 at the receiver, 8‑channel
FLAC reports 7.1. TrueHD, DTS‑HD MA, Dolby Digital and plain stereo are unchanged.
The equivalent change for T7 boxes mirrors the same reasoning but could not be
tested — no T7 hardware here.
🕐 TrueHD lip‑sync drift that the on‑screen stats insisted wasn't there
The symptom. On a TrueHD soundtrack, audio gradually sits behind the picture
by an amount that is small but perfectly visible on faces — while the player's own
sync figures look unremarkable. Skipping forward fixes it instantly, then it
creeps back. Several people reported exactly this, on release builds, on the newer
boxes.
What was wrong. This is an upstream Kodi behaviour, present in stock Kodi,
CoreELEC 21 and CoreELEC 22 alike, since May 2024. When the soundtrack is TrueHD,
the measured audio/video error is deliberately multiplied by 0.45 before
anything sees it — the intent being to damp needless corrections.
The problem is that everything downstream sees the shrunken number, including
the threshold that decides whether to correct at all. That threshold is 50 ms of
measured error, which for TrueHD means roughly 111 ms of real error — well
past the point where a human sees lips out of step. So any genuine drift below
that was never corrected, permanently. A seek performs a full resync that bypasses
the threshold entirely, which is exactly why seeking appeared to cure it.
The fix stops scaling the measurement, so the box corrects on real error
rather than on 45 % of it. The worry that motivated the scaling — corrections
fighting each other — is prevented structurally instead: the correction threshold
is deliberately kept wider than a single correction step, at every frame rate. The
worst standing error this build will sit on drops from about 111 ms to roughly
one video frame's worth — about 8 ms at 24p, rising to about 33 ms at 60p, since
a correction moves the clock by one whole frame and a 60p frame is shorter.
Validated over two unattended 75‑minute TrueHD runs (about 1,900 wire‑level
measurements each), measuring the real audio/video offset at the HDMI output
rather than trusting Kodi's own numbers:
- Real offset stayed within 23 ms for the whole of run 1 and 13 ms for the
whole of run 2, flat, with no drift. - Zero unnecessary corrections — the oscillation the scaling was meant to prevent
did not occur. - Run 2 caught a genuine slow drift of about 5 ms/hour (normal crystal tolerance,
harmless) and Kodi measured it at full size — on the old build it would have
been reported at 45 % of that. The honesty claim is now observed, not argued.
One honest gap: neither run happened to develop enough error to trigger a
correction, so the "corrects real drift when it occurs" half is backed by code
reasoning rather than a caught‑in‑the‑act observation. The change only alters what
happens above the threshold, so it cannot make the quiet case worse.
🎨 The box told your TV the wrong thing about the picture it had just sent
Who this affects. Only playback that uses the Dolby Vision engine to
tone‑map into an HDR10 output — that is, the "DV → HDR10" and VS10 HDR10
paths. Straight HDR10 passthrough and true Dolby Vision output are untouched.
What was wrong. Every HDR frame is accompanied by a small note to the display
describing the mastering monitor the content was graded on, so the TV knows how to
roll off highlights it cannot reach. When this build tone‑maps a title, it was
still sending the original file's note — measured across a 20× sweep of the
tone‑mapping target, the note never changed once. So the box would carefully map a
picture for, say, a 2,600‑nit panel and then tell the TV "this was graded at
1,000" — and the TV would apply its own roll‑off against a reference that no
longer described the signal. Two tone maps, neither aware of the other.
Two further faults in the same note:
- The colour primaries went out rotated one position — red's coordinates in
green's slot, and so on. The transmitter expected them in one order and the
Dolby Vision path wrote them in another; only one narrow branch had the
correction, and everything else fell through without it. - The content light‑level figures (peak and average brightness of the actual
material) were also the source file's, describing footage that no longer exists
after remapping. These are now cleared, which is the way the HDMI specification
says to state "this has been re‑processed and the figure is no longer known" —
letting the TV fall back on the mastering figure, which is now correct.
Separately, the box was saving its own guess as if you had chosen it. The
tone‑mapping target could be read from your TV's Dolby Vision capability block, and
that detected value was written into the settings file permanently — after which it
was indistinguishable from a deliberate choice, survived a change of TV, and
travelled to any box you cloned your settings to.
That number is now only ever used if you typed it in. Left at 0 it means what it
says: the tone mapper uses its own built‑in target and nothing is pushed at it. The
detected figure is an advertised Dolby Vision capability rather than a measured
one — panels routinely claim a peak their sustained output never reaches — so
feeding it in as a target raised the target on essentially every Dolby Vision
display, which removes highlight roll‑off that was previously being applied and
clips bright detail at the panel instead of mapping it. (The separate "is this
title brighter than my display" comparison used by Smart CMv4.0 still reads your
TV automatically — that is a comparison, not a target.)
There is also a related correction so the display's peak brightness is re‑sent to
the tone mapper only when it genuinely changes, rather than once per frame for the
whole film.
against the HDMI and Blu‑ray specifications and against measurements taken at the
cable, but nobody has sat down and A/B'd the result on a calibrated display. It is
the reason this release is worth treating as experimental even by the standards of
these builds. If HDR10 highlights look different to you on tone‑mapped material —
better or worse — that is the change to report.
If you upgrade and you already had a tone‑mapping target set, check it.
Settings → CoreELEC → Dolby Vision → display max nits. If you never deliberately
chose that number, set it back to 0 so the box detects it from your TV; a value
that was auto‑filled by an older build is now treated as your explicit instruction
and will override the detection. This matters most if your settings were copied
from a box attached to a different television.
🩹 Smaller fixes
- The Dolby Vision colour‑space override did nothing unless you had also typed a
peak brightness. The setting was visible, accepted your choice of DCI‑P3 /
BT.2020 / BT.709, and silently had no effect while the peak was left on auto.
The two settings are now independent — with the peak on auto your display's own
peak is left exactly as it advertises it, and only the colour primaries change. - Changing TV or AV receiver without restarting Kodi left the box using the
old display's Dolby Vision capabilities for the rest of the session. It now
notices at hotplug and re‑reads. - A Dolby Vision override could survive an unclean shutdown and get stuck. If
Kodi was killed rather than closed while forcing a peak onto the display, the
next start could mistake its own leftover override for the panel's real
capabilities and never clear it. It now always clears when it has no verified
reading of the panel to compare against. - A Blu‑ray with no title longer than 30 minutes — calibration, demo, concert
and featurette discs — could be added to the library as a single movie with
dozens of "versions", asking you about each one. This only bites in combination
with a new upstream library feature, so it has not been in a release before;
fixed before it could be. - Multi‑channel PCM on a box that has never had an audio device chosen. The
preference added above was missing from one of the fallback paths, so a
completely unconfigured box could still pick the internal analog output instead
of HDMI. - A pause and resume on multi‑channel PCM left the channel layout query broken
for the rest of the track, and a stray audio control could outlive the stream it
belonged to. Both are internal to the driver; neither had a reported symptom.
🔄 Rebased onto current upstream CoreELEC 22
This build also picks up current upstream, which had moved substantially. Nothing
in it is expected to be user‑visible on its own.
Known limitations
- The HDR metadata fix above has not been checked by eye on a calibrated
display. Treat this release accordingly. - The T7 audio routing change is untested — validated on S5/S6 class hardware
only. (The device‑tree mapping it assumes was since confirmed correct by
inspection, but no T7 box has run it.) - Older boxes still have the multi‑channel PCM bug. The fix above is applied
only to S5/S6/S7/T7‑class hardware. G12A, G12B, SM1, SC2 and S4 boxes have the
same fault, and the remedy is known and small — but there is no hardware here to
test it on, so it is deliberately not included rather than shipped blind. - Part of the multi‑channel PCM fix may be redundant. Of the four changes, the
Kodi‑side audio‑source selection could not be shown to affect the hardware by
reading the driver; the audible fix may come entirely from the kernel side. It
is kept because it is harmless and correct, but it has not been isolated. - TrueHD: the underlying reason the newer boxes develop any audio error at all
is still open. This release stops that error being hidden and left
uncorrected; it does not remove the source. Worst case is now a bounded, briefly
corrected transient instead of a permanent offset. - On a long title you may still see the picture step by one frame, roughly once
every half hour. This is expected, and stock CoreELEC and CE21 builds do it
too — your box's video clock and your AVR/TV's audio clock are separate crystals
that drift apart, and with a bitstreamed soundtrack the audio cannot be
stretched to absorb it. - Dolby Vision requires
dovi.ko, which is not bundled. Install it as you
would on stock CoreELEC 22; this build corrects it at boot without modifying
your copy.
Source
- CoreELEC (distro):
SamuriHL/CoreELECtagv22.0-samurihl-20260808164352 - Kodi:
SamuriHL/coreelec-xbmctagv22.0-samurihl-20260808164352
Checksums (SHA256)
8ce4f25b42098a55a3bf60ff9fb04999ef74531c2400acb356130274a56c2e83 CoreELEC-Amlogic-no.aarch64-22.0-Piers-samurihl-EXPERIMENTAL_20260808164352.tar
b102829f0b4b5a00eb2b3aef343e04624b15becd9a0226787de687b65110e70b CoreELEC-Amlogic-no.aarch64-22.0-Piers-samurihl-EXPERIMENTAL_20260808164352-Generic.img.gz