⚠️ 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.gz to an SD card or USB with
  balenaEtcher (or the Amlogic USB Burning Tool for eMMC), then boot from it.
• In-place update: copy the *.tar to the /storage/.update folder 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-20260810192712
(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).

This one is entirely about audio sync on disc playback — the biggest fix removes
a fixed, roughly 800ms audio delay that showed up after a menu‑to‑feature (or any
mid‑disc codec/format) switch.

⚠️ 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.

🔊 Fixed: audio landed ~800ms late after a disc menu → feature switch (or any mid‑title format change)

The symptom. Start a disc from its own menu — or hit any point where the
soundtrack changes format mid‑playback (for example a Dolby Digital menu handing
off to a TrueHD or DTS‑HD feature) — and audio could come in a fixed ~800ms behind
the picture for the rest of the title. A manual seek fixed it instantly, which made
it look like a receiver or sync‑servo problem. It wasn't — every internal sync
statistic read clean the whole time, on both a broken and a working playback.

What was wrong. This is a disc‑specific decode path (menus and DV/HDR10+
titles run "STREAM mode" instead of the simpler per‑frame mode files use). In
STREAM mode, the decoder only stamps a real timestamp on the first video frame
of a session — every frame after that gets its timestamp fabricated by adding
a fixed frame duration to the last one. A one‑time seed error at the exact moment
of the menu→feature switch was then frozen into every frame's label for the rest
of the title. Nothing was actually falling behind — the picture's timestamps were
simply lying, consistently, in a way every downstream sync calculation trusted.
A seek forces a full decoder session restart, which reseeds honestly — hence "seek
fixes it," and hence why it was invisible to statistics computed from the same bad
labels.

The fix makes the decoder stamp a real timestamp on every frame in STREAM
mode, the same as the simpler per‑frame path already does, so there is no seed to
get wrong. Verified on‑box: real per‑frame timestamp lookups jumped from one per
disc session to ~26/second with zero lookup failures, and the fix closed a
three‑week‑running user report on the acceptance disc used to chase it — "Nailed
it."

As a side effect, a workaround for this issue that was ported from another
project's player (an opt‑in "re‑sync the receiver" trick) is no longer needed and
has been removed. It worked, but at the cost of an audible drop in audio each
time it fired — never acceptable as a real fix, and now unnecessary.

🔊 Fixed: the sync corrector could park up to ~220ms out on TrueHD before this release, ~67ms after

What was wrong. The little bookkeeping loop that nudges bitstreamed TrueHD
back into sync tracks its progress in one unit but was crediting its own
corrections in a different, unscaled one — so it thought each correction was
worth more than it actually was, and stopped adjusting too early. Fixed to credit
corrections in the same currency the error is measured in. The correction floor
drops from a true ~220ms worst case to ~67ms, and the corrector now finishes its
walk in a single pass instead of parking early.

🔊 Fixed: a passthrough delay reading of exactly 0 wasn't real, it was unmeasured

What was wrong. When the audio pipeline skips a write on a RAW/passthrough
stream (nothing to send that cycle), the delay value it published afterward was a
hard‑coded zero rather than an actual measurement of the sink — an unrelated,
narrower defect surfaced during the investigation above. It's now measured for
real on every cycle, including skips.

🔊 Fixed: a slow, hours‑long audio drift on some S6‑class boxes (e.g. AM9 Pro)

Separately from the ~800ms fix above, a much smaller, slower drift (tens to a few
hundred ms per hour on some titles, self‑correcting in a sawtooth) had been under
investigation. The cause was how the renderer averages its vsync‑phase
measurement: it summed 31 raw samples and took a linear mean of what is
actually a circular quantity (a value that wraps every frame period). Near the
wrap point, jitter splits samples across the wrap and the mean becomes a sweeping
mixing fraction rather than a real phase — measured sweeping roughly 60× faster
than the true phase could physically move. The fix wraps each sample before
averaging instead of averaging the raw values.

Verified on‑box.

🔍 Under the hood

The three diagnostic/experimental sync‑error trace commits used to chase the
~800ms fix above (delay‑decomposition logging, per‑second min/max accumulation,
codec‑switch timing) were all reverted before this build — no debug‑only logging
shipped as a result of this investigation.

Source

• CoreELEC (distro): SamuriHL/CoreELEC tag v22.0-samurihl-20260812171608
• Kodi: SamuriHL/coreelec-xbmc tag v22.0-samurihl-20260812171608

Checksums (SHA256)

37cf5d1f66ccbdc24370b1985efb847bade52743e8fdbc8c0163b88865f7e152  CoreELEC-Amlogic-no.aarch64-22.0-Piers-samurihl-EXPERIMENTAL_20260812171608.tar
370bbcf1056837fdd9499d47eaaa13f581fdfc8efdfa2199fc7a3f8abdd4c892  CoreELEC-Amlogic-no.aarch64-22.0-Piers-samurihl-EXPERIMENTAL_20260812171608-Generic.img.gz