Question 
With this “Updated Amlogic Wi-Fi and Bluetooth drivers and firmware (w1-aml, w2-aml, rtkbt-firmware-aml)” does this mean that I don’t need my USB Bluetooth adapter for my Ugoos AM9?
Can I just place this file ”CoreELEC-Amlogic-no.aarch64-22.0-Piers_rc1-Generic.img.gz”
Into the update folder of my CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20261002 build?
Or do I need to perform a fresh install?
Yes, Definitely.
Thanks, I’ll use the backup utility and perform that step manually. 
Completed a fresh installation of RC1 on an AM9 Pro. Post-installation, the system boots with an apparent 8-bit color display showing the CoreELEC logo, then switches to a black screen with a large white cursor positioned in the upper left corner. SSH access is unavailable, so the root cause remains unknown. BETA2 operates normally.
You need to update Android to use it on AM9 or AM9 pro:
Hello,
I’ve had this problem since nightly build 20260929. Now I’ve flashed the RC1 image and the problem persists.
WaipuTV, the n-tv channel, and History (the History channel is extremely poor) keep freezing, a circle appears in the middle of the screen showing 100%, then it continues for a few seconds, but not a full minute.
My device is: X96 Max+ Ultra
LAN: 100 Mbps
RAM: 4 GB
SOC: S905X4
TV: Hisense with Dolby Vision
I did a fresh installation on a USB flash drive, installed WaipuTV and the necessary add-ons, but unfortunately, the problem remains.
When I revert to version Beta 2, everything works perfectly.
Logs are attached below:
The nightly build 20261005 exhibits the same behavior.
Thanks for the quick response, it’s working now. I had completely missed that new firmware was required.
I’ve noticed that when I start to watch a tv show after like 2 or 3 minutes the audio goes out of sync with the video. After exiting back from the video and starting it again, it plays fine (everythings synced) until the end of the episode.
Mine was in exactly the same state, but ssh was available.
I also experience audio lag sometimes (whenever it happens, it’s specifically a 100–200 ms delay, not the audio playing ahead of the video). I’ve noticed that if the audio is simply passed through, the problem doesn’t occur. It usually happens with YouTube or HTTP streams, since 90% of the time they don’t use Dolby Digital. The issue might appear with a specific video one time but not the next. This has been going on for a long time - ever since I started using CE 22 six months ago. There could be many culprits 
Inputstream Adaptive, Kodi, CoreELEC, or - as I suspected - the fact that my TV has old ARC rather than eARC. It doesn’t happen often.
Aside from that, I have no other issues. Everything runs very smoothly, especially after the 20261002 build.
I have also noticed some issue with the usb devices and Hyperion.ng connected to the ttyUSB0 - for some reason it drops the serial connection and the device disappears from system and Hyperion.ng. Rebooting the device doesn’t help, you have to actually turn off the device and swap the usb port to make it work again.
I also have the same issue on AMB6+. Hopefully the team will look into it. I can provide necessary logs when requested.
Hi all,
Thanks for the RC1! I’m seeing a reproducible boot issue on the Homatics Box R 4K Plus (S905X4, sc2_s905x4_sei_smb_280_id5), connected directly to an LG OLED B1. CE 21.3 (5.4 kernel) is stable on the same setup.
On about 50% of cold boots/reboots the colors are inverted (neon green/magenta) with vertical raster lines, starting right at the boot logo. Changing resolution or refresh rate in Kodi immediately restores normal output.
From my analysis: U-Boot leaves ready = 1 in 8-bit (hdmi_tx_main.c:3989). When DRM then negotiates 10-bit (cd:5), hdmitx_common_pre_enable_mode() skips the PHY teardown because ready == 1 and logs:
HDMITX_ERROR Should run disable_mode before enable new mode.
This leads to an SCDC NACK, leaving the transmitter stuck in 8-bit while the pipeline runs in 10-bit.
Limiting color depth to 8-bit avoids the glitch, but then HDR10 falls back to 8-bit.
I have an analyzed teardown patch for hdmitx_mode_set.c and can provide dispinfo/dmesg logs (corrupted boot vs. recovered state) on request. Happy to test any build or change if it helps. Thanks for your work on this!
CoreELEC 22.0-Piers_rc1 installed and working well. (I forgot to add on an Odroid+ N2 Usd card). It has an external exFat USB HDD from a previous 21.3 Coreelec install, and this is working fine for playing/deleting, movies and TV series , except, when accessing this shared external HDD from a network Windows 11 machine I can’t create a folder in the drive which is essentially over the network.
Currently I can create a TXT file from the windows machine ok, but not copy from the windows drives to the Corelec external drive. Error when trying to copy from a windows HDD to Coreelec I get this message in windows “could not find this file”. Not sur eif its refering to the source or to the destination location.
This seems to be every time I upgrade from 20 to 21 to 22. When I get it working with so much stuffing around I can’t remember what to record what actually solved the problem.
Sometimes the Coreelec HDD is /dev/sda2 and sometimes it looks like /dev/sdb2.
Thanks for any guidance that assists how to transfer files from a windows computer to the Coreelec external attached HDD.
Edit: I can create a text file, edit the file and that works ok, but not create a folder, not copy and paste a file across. Seems like permissions but I am not up with Linux to do this.
Edit2: Working with ChatGPT (first time) and worked through all alterations of SMB.conf by adding and deleting Seagate5TB share in Corelec and no joy. have turned off samba-rebooted, enable samba-rebooted and even created another share SeagateRW with all the correct share items as suggested and “read only = NO” even though entered does not appear in the final smb.conf. I can delete files and folders from windows, can create a file like a txt file ok and edit that from windows, just not a folder. Even Chatgpt with lots of results and suggestions cannot solve the problem because it seems unsolvable.
The error message in windows claims "Could not find this item This is no longer located in d:\downloads etc. So now it appears to be missing inside windows? While creation of a folder in the HDD from windows says it cant “cant find the item. This is no longer located in \Coreelec\Segate5TB” Verify the location and try again.
Edit3: Change back to Coreelec 21.3 uSD card and it all works fine. No other change needed using same external HDD, same windows, therefore problem exists inside 22. Also tried nightly update 261005 and no change. Must be a samba or OS configuration.
Edit4: New card, loaded nightly 20261006, change IP to static, nothing else, same problem! Replace with 21.3 card, working again.
Edit5: Slept on problem. loaded 21.3 to eMMC, tested all working ok. loaded Coreelec 22.0 RC1 to the update folder and rebooted where it did an upgrade from 21.3 to 22. Looked like all settings were retained, IR remote still working, Samba appears to be the same settings as 21.3. However we now have the problem where a folder cannot be created from a network desktop PC.
Maybe the Samba upgrade in 22 is the problem and as its part of Coreelect I dont think there is a replacment or reinstall possible.
As far as I can see problem is with the 22 installation. No nightly or other option appears to be available to me to fix this. Anyone got any clues or suggestions please?
Minsik.
I have found a reproducible CEC issue on an Ugoos AM6B+ (S922X-J / G12B) running CoreELEC 22 nightlies.
Hardware / software
-
Ugoos AM6B+, 4 GB
-
Sony Bravia 7 connected directly over HDMI
-
TV remote used through HDMI-CEC
-
No AVR or soundbar
-
CoreELEC:
22.0-Piers_nightly_20261008 -
Build ID:
5b2970d67edf13285386d9588abdb40a5fca8bd6 -
Device tree:
g12b_AM6b_b4g -
CoreELEC installed to eMMC
-
eMMC running correctly in HS400 mode
Symptom
After several nightly updates, CEC became unreliable at startup.
Kodi starts normally, but the Sony TV remote does not control Kodi for approximately 2-3 minutes. After that delay, CEC begins working without any manual intervention.
Previously, with an earlier CoreELEC 22 build, I had already traced a similar problem to the G12B CEC selection.
Finding
The current DTB contains the following property under /aocec:
ee_cec
The live device tree confirms it is active:
if [ -e /proc/device-tree/aocec/ee_cec ]; then
echo "CEC-B active"
else
echo "CEC-A active"
fi
With the stock nightly DTB:
CEC-B active
The relevant /aocec properties in /flash/dtb.img included:
cec_log_en
ee_cec
cec_sel
The current CoreELEC common_drivers G12B DTS also contains:
&aocec {
ee_cec; /*use cec a or b*/
cec_sel = <1>;/*1:use one ip, 2:use 2 ip*/
port_num = <4>;
};
Controlled test
I backed up the stock nightly DTB and removed only the ee_cec property from the B4G member:
mount -o rw,remount /flash
cp -p /flash/dtb.img \
/flash/dtb.img.20261008-before-CEC-A
fdtput -a g12b_AM6b_b4g -d \
/flash/dtb.img \
/aocec \
ee_cec
sync
mount -o ro,remount /flash
reboot
Nothing else in the DTB was changed.
After reboot:
GOOD: CEC-A active
The Sony remote then worked immediately when Kodi appeared, with no 2-3 minute delay.
I repeated the check after boot and confirmed that HS400 remained unaffected:
clock: 200000000 Hz
actual clock: 199999997 Hz
bus width: 3 (8 bits)
timing spec: 10 (mmc HS400)
signal voltage: 1 (1.80 V)
The eMMC DT settings were also unchanged:
mmc-hs400-1_8v
mmc-hs200-1_8v
tx_delay = 16
Kernel CEC log
With CEC-A active:
[ 2.256408] input: cec_input as /devices/virtual/input/input0
[ 2.256521] cec: not find 'arc_port_mask'
[ 2.256531] cectx ff80023c.aocec: mbox_request_channel_byname() requires an "mbox-names" property
[ 2.263728] cectx ff80023c.aocec: Not find mbox channel byname
[ 2.307105] cec: wakeup_reason:0x0
[ 2.307396] cec: wakeup_data: 0x0 0x0
Kodi registers the CEC device normally:
2026-10-08 21:03:17.991 info: Addon Manager: Found addon: 'game.controller.cec.adapter v1.0.5'
2026-10-08 21:03:19.278 info: Loading controller layout: /storage/.kodi/addons/game.controller.cec.adapter/resources/layout.xml
2026-10-08 21:03:19.281 info: Register - new cec device registered on cec->AOCEC: HDMI (0000:0000)
A/B result
The result is reproducible on the same hardware, TV, HDMI connection and CoreELEC nightly:
Stock DTB:
ee_cec present
CEC-B active
Remote unavailable for approximately 2-3 minutes after startup
Modified DTB:
ee_cec removed
CEC-A active
Remote works immediately
This appears to isolate the problem specifically to the G12B CEC-A/CEC-B selection rather than libCEC configuration, Kodi settings, the television, or eMMC configuration.
Nightly updates
A further issue is that CoreELEC updates replace dtb.img, so the manual CEC-A modification is lost after a nightly update and ee_cec returns.
For now I have a guarded systemd service which runs before Kodi, detects whether the current AM6B+ B4G DTB contains ee_cec, removes only that property, verifies the resulting multi-DTB and reboots once. This restores CEC-A automatically after an update.
Question for the CoreELEC team
Is ee_cec; intentionally enabled for G12B / Ugoos AM6B+ in the current device tree?
Given that the AM6B+ works immediately and reliably with CEC-A, while CEC-B introduces a reproducible 2-3 minute startup delay, would it make sense to remove ee_cec specifically for the AM6B/AM6B+ device tree, or otherwise select CEC-A for this hardware?
I can provide the complete DTB before/after files, additional boot logs, Kodi debug logs, or test a proposed patch/nightly if useful.
We really don’t like such AI generated analysis because then you should be also able to solve the “problem” by yourself.
Also we need an AI to sum up everything short to not waste time, even when the analysis is wrong or incomplete.
Most posts like this are just ignored!
To give more background:
AI just don’t see everything and have no experience and do just a lot of spam.
Maybe it’s the case for your setup it works better but all other setups do work more reliable by using CECB. Since we switched permanent to CECB all user issues were solved. This is since CoreELEC-19.