⚠️ 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-20260910194119
(see that release and its predecessors for the standing feature set: Blu‑ray disc
menus, HDR10+ → Dolby Vision conversion, CMv4.0 metadata control, DV → HDR10 that
stays in HDR10, FEL profile‑7 reconstruction on non‑DV displays, VS10 output on
non‑DV displays, VSVDB override, disc‑stated menu detection and episode lists).

⚠️ 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: menus too see‑through during HDR and Dolby Vision playback

The report. During HDR and Dolby Vision playback the whole interface looked far
more transparent than normal — "as if the transparency were tripled" — and with the
skin's background video turned off, the video could still be seen behind it.

What was actually wrong. When the output goes through the box's Dolby Vision
engine, Kodi draws its menus into a separate picture first and converts that picture
to HDR in one pass. Two things in that path made anything semi‑transparent too
see‑through:

• The way transparency was added up in that picture came from upstream Kodi's new
  HDR menu code, and it was off: every semi‑transparent layer drawn over a solid
  background punched a hole in it, so video showed through where the skin had
  painted a solid background. Upstream Kodi's developers have acknowledged this and
  have a pending change to undo it
  (xbmc/xbmc#28350); this build applies it
  now.
• The HDR conversion then applied the transparency a second time, so a panel meant
  to be 50% opaque came out at about 35%.

The fix. Transparency is now worked out exactly as it is in SDR, and the
conversion applies it once. Solid colours are unchanged; semi‑transparent panels,
dialogs and Blu‑ray menu elements now look as they do in SDR — a little lighter than
in the previous build.

Who saw it. Only playback whose output goes through the Dolby Vision engine:
Dolby Vision output, or a VS10 conversion (for example VS10 HDR10 set to HDR10 or
Dolby Vision). Plain HDR10 passthrough (VS10 HDR10 set to Off) never used this
path and is unchanged.

Checked on an AM9 Pro by measuring the menu output directly: solid colours are
identical to before and semi‑transparent areas change by exactly the predicted
amount. Please tell us how it looks on your TV.

Credit: the upstream fix is by reardonia (Kodi), applied here ahead of upstream.

🎛️ Fixed: switching VS10 during playback left the menus too dark

The report. Switching an HDR10 title to Dolby Vision during playback with
Action(vs10.dv) (for example from TinyPPI) changed the picture correctly, but the
on‑screen display turned too dark. Setting VS10 HDR10 → Dolby Vision in the
CoreELEC settings instead gave a correct display.

What was actually wrong. The live switch changed the video output but never told
the menu renderer, which kept the colour encoding it had picked when the video
started — the right one for plain HDR10, the wrong one for Dolby Vision. The reporter
traced it to exactly this in the source; thank you.

The fix. The menus now follow a live VS10 switch in every direction. For
Original, where the box's Dolby Vision engine decides the output from the source
itself, the build reads back what the engine chose instead of guessing.

Checked on an AM9 Pro with HDR10, SDR and Dolby Vision titles: after a live
switch the on‑screen display is pixel‑for‑pixel identical to what the settings route
produces.

⚫ New: a black‑level control that actually works — player‑led Dolby Vision

The report. On player‑led Dolby Vision, a reviewer's picture cut off everything
below video level 68 on a black‑level test pattern, and no setting in this build
moved it.

What was actually happening. In player‑led (low‑latency) Dolby Vision the Dolby
engine in the box does the final tone mapping, and it takes the black level from the
television's own Dolby Vision capability block (the VSVDB in its EDID). His Philips
declares a minimum of 0.0006 nit — which is exactly video level 68. The box was
faithfully doing what the TV told it.

The new setting. Black level (VSVDB), next to the existing VSVDB colour‑space
option, overrides that one figure. The choices are labelled with the video level each
one cuts at, so they can be read straight off a test pattern:

• Display — keep what the TV declares (the default; nothing changes)
• 0 nit – reference black (code 64)
• 0.0006 nit (code 68), 0.0022 nit (code 73), 0.0047 nit (code 77),
  0.0083 nit (code 81) — for panels that crush shadows and look better lifted

To use it: set Dolby Vision Led mode to player‑led, turn on Force peak onto display
(VSVDB) and leave Display peak luminance at 0 (so the TV's own peak is kept), then
choose the black level.

Checked on an AM9 Pro by reading the engine's tone curve directly: each step moves
only the shadow end of the curve, the bright end is untouched, and changing it during
playback takes effect immediately. Not checked by eye: whether level 64 looks
better than 68 on your TV. Your TV declared that floor for a reason — it may simply
crush those levels itself — so judge it on a test pattern.

Where it does nothing: TV‑led Dolby Vision (the television does the mapping with
its own settings) and HDR10 / SDR output (see the next section).

⚠️ Correction: two settings never did what we said

Earlier releases described two Dolby Vision settings wrongly. We found out by taking
the closed Dolby engine (dovi.ko) apart and by measuring its output: the values
these settings pass to it are never read. The engine uses its own built‑in targets
instead.

• "Dolby Vision target minimum luminance (reference black)" has been removed. It
  never changed the picture on any output. The notes for the 28 Aug and 9 Sep builds
  said it had been fixed for Dolby Vision; the setting was indeed being delivered,
  but the engine ignores it. Apologies to everyone who spent time turning it. For
  player‑led Dolby Vision, the new Black level (VSVDB) above is the control that
  works.
• "Display peak luminance" does not change the box's tone mapping on VS10 HDR10
  output. It was described as the peak the engine maps to. What it really does
  there is tell your television the content was mastered at that peak, and your TV
  then tone‑maps for it — which is why lowering it dims the picture. Its other jobs
  (the Smart CMv4.0 decision, and the VSVDB peak for player‑led Dolby Vision) are
  unaffected and work as described. The help text now says all this.

What this means for VS10 HDR10 output (HDR → HDR). Dolby's engine maps HDR10
output to a fixed 1000‑nit peak and a fixed 0.005‑nit black, which cuts off
everything below about video level 77. No setting in this build changes that, and we
are not going to pretend otherwise.

🔌 Fixed: a live VS10 switch now changes the HDMI link as well

What was wrong. Dolby Vision, HDR10 and SDR each need their own HDMI link
format. On our test TV, TV‑led Dolby Vision uses 8‑bit RGB, while HDR10 and SDR use
12‑bit 4:2:2. When the video starts, the box picks the right one for your TV. A live
VS10 switch only changed the signal, not the link underneath it. Switching an HDR10
title to Dolby Vision mid‑playback therefore sent Dolby Vision over HDR10's link, and
switching back left HDR10 on the Dolby Vision link. This was not new in this build.

The fix. A live switch that needs a different link now re‑trains it the same
way a refresh‑rate change does: playback pauses, the link changes, then playback
resumes. Every direction now lands on the same link as choosing the setting and
restarting playback.

What you will notice. A switch that changes the link blanks the screen briefly
and pauses playback for about as long as your Delay after change of refresh rate
(1.5 s on our test box). A switch that doesn't change the link is instant, as
before.

Checked on an AM9 Pro, reading the HDMI output after each switch:

• The Martian (HDR10): to Dolby Vision gives 8‑bit RGB Dolby Vision. Back to
  Original or to HDR10 gives 12‑bit 4:2:2 HDR10.
• Mad Max (Dolby Vision): to SDR gives 12‑bit 4:2:2 SDR, and Original goes
  back to 8‑bit RGB Dolby Vision.
• An SDR title: to Dolby Vision gives 8‑bit RGB Dolby Vision.
• Switching while paused works too.
• Blu‑ray menus that hold the disc's Dolby Vision session are never re‑trained, so
  menu navigation can't cause a black screen.

Where it does not apply:

• With Adjust display refresh rate set to Off, a live switch still keeps the
  current link. Use the setting and restart playback instead.
• An HDR10+ title with HDR10+ → Dolby Vision conversion turned off, switched live
  to Dolby Vision and then back to Original, stays on the Dolby Vision link until
  playback restarts.

🎯 Fixed: A/V sync shifted after a refresh‑rate change or a live switch

What was wrong. Whenever the display re‑trains mid‑playback, the box's audio
output restarts. That happens when a film opens with a refresh‑rate change, at a
disc's frame‑rate changes, and now at a live VS10 switch. The restart threw away
about a fifth of a second of queued audio, but the audio engine carried on as if
nothing had happened. It then re‑synchronised against a stale measurement, so it:

• re‑aligned lip sync somewhere different every time, up to 36 ms away from
  where it had been;
• sometimes jumped the video by a whole frame, several times in a row, while
  correcting that stale reading;
• gave the pause fix from 20 August a wrong target at every film that opened
  with a refresh‑rate change, so a later pause/resume could shift lip sync by
  25 ms instead of restoring it.

The fix. A display re‑train is now treated exactly like a pause and resume:
the audio returns to the alignment you were watching, using the same mechanism as
the 20 August pause fix. The target that fix aims at is now taken from settled
measurements only.

Checked on an AM9 Pro. Change in lip sync across each event, measured from the
player's own sync readings (— = not measured on that build):

No video jumps in any of the 20 events measured on this build (DTS‑HD MA, TrueHD,
PCM and a Blu‑ray disc).

Honest caveats:

• A tiny audio drop a few seconds after a switch. The first re‑alignment
  happens while the audio output is still refilling, so about 5 seconds later the
  box checks it and trims up to a few tens of milliseconds of audio. The pause fix
  does the same.
• TrueHD is less exact. It re‑aligns to within about 10 ms rather than 3, for
  a known reason we have deliberately left alone.
• PCM (passthrough off) still moves lip sync by 10–20 ms at each display
  re‑train, as it always has. It no longer jumps the video by a frame.

Tell us how it sounds and looks on your system: our measurements can't replace
your eyes and ears.

Under the hood

• Kodi‑only update: the kernel and the rest of CoreELEC are unchanged from the
  previous release.

Source

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

Checksums (SHA256)

a336056173479ca43c3277a1ce8012a32b26d33c0ae29808f410d0004dda9cbb  CoreELEC-Amlogic-no.aarch64-22.0-Piers-samurihl-EXPERIMENTAL_20260911164420.tar
d686dfd7971fe32c4c99321fd22a7df12fb110c1ca77d0433b0b8c79f417646c  CoreELEC-Amlogic-no.aarch64-22.0-Piers-samurihl-EXPERIMENTAL_20260911164420-Generic.img.gz