video=HDMI-A-1:1920x1080M@60DAdd that ^ to kernel params in cmdline.txt and see if forcing the initial DRM connector state to 1080p changes anything?
LE12.2 has a newer kernel than LE12.0 so the DRM layer can behave differently (even if ports/cables didn't change). RPi5 sometimes defaults to using 4K modes the TV doesn't like.
This is going to be a Kodi bug (not an LE specific bug) so it should be reported upstream via Kodi GitHub. Take care to follow the issue submission template; provide a full debug log that demonstrates success and then failure, and steps to reproduce.
dtb_name=/amlogic/meson-gxbb-p201.dtb
bootargs=boot=LABEL=LIBREELEC disk=LABEL=STORAGE quiet systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0 video=Composite-1:720x576@50ie^ the second and third lines are a single line (the forum wraps it). The file needs to be edited with something that respects Linux file endings. In the past Notepad.exe would mangle the file with Windows line endings and boot would break, so you'd need to use a text editor like Notepad++ to avoid the problem. I'm not sure if newer Windows OS learned not to do that, or if that's your issue..
NB: The video= content only sets the initial DRM connector state. Kodi can then mode switch to something else once running. Kodi only outputs progressive, never interlaced; hence you will never see interlaced modes listed/available for selection.
Did I miss something or is the TVH PVR Client vanished from nightly Generic builds?
This disagrees with you: https://addons.libreelec.tv/12.80.4/Generic/x86_64/pvr.hts/
Have you tried force-refreshing the LE repo?
Thanks for confirming and sharing the log. I've sent the wifi firmware patch upstream: https://patchwork.kernel.org/project/linux-…[email protected]/
For other Q's:
1. If using Composite output the DRM connector cannot auto-detect the presence of a display (or the display type) and you probably need to force ouput, e.g. for NTSC add video=Composite-1:720x480@60ie and for PAL add video=Composite-1:720x576@50ie to boot params in uEnv.ini on the SD card. Note that the default Estuary skin in Kodi is designed for a minimum 720p screen so when used with something smaller navigation can be challenging.
2. LE does not support boot/run from eMMC with Android boxes: https://wiki.libreelec.tv/hardware/amlogic#installtointernal
3. No, because the box implements rmii (internal-phy) not rgmii (external-phy) so in the upstream kernel p201 is the sole correct dtb to use. I've no idea why the upstream and downstream numbering for GXBB development boards is different, but it is.
NB: ethmactool "errors" are harmless and can be ignored, it's simply a boot-time script that ensures the Ethernet MAC is unique
If you have an older nVidia GPU (and didn't read the release notes) you can 'update' back to 12.0.2 again.
It looks like upstream linux-firmware moved the mt7601u.bin files to the mediatek subdirectory in https://git.kernel.org/pub/scm/linux/…35d3cf5bb8a8fcb so a patch is needed to check the new location (and the old one, to preserve compatibility).
I've written/added that patch now: https://github.com/chewitt/linux/…0fa9514c1bccaed so go download the AMLGX image from my test share again and the MT7601u chip should now find the firmware. NB: Only test the AMLGX image with the p201 dtb - anything else is wasted effort and noise.
Please see if an LE13 nightly or image from my test share works better? https://chewitt.libreelec.tv/testing
I don't see anything that looks obviously wrong. The channel is opened and you can see ffmpeg parsing content. Two audio streams are found; one is mpeg2audio which I'd guess is stereo, and one is ac3 which I'd guess has 5.1 audio, which is selected alongside the H264 video content.
Disabling VAAPI changes the process flow inside Kodi, although I'd have to go look at code to understand more. I'm wondering what differences might exist/show in the logs as a first step. Please share some additional debug logs (separate logs/pastes if possible, as these are easier to search).
NB: LE did bump the Tvheadend version last week https://github.com/LibreELEC/LibreELEC.tv/pull/10719 but the list of changes in the update are not particularly interesting (compile fixes, translation updates, etc.). There are also ffmpeg changes to improve the transcoding capabilities (mentions of VAAPI here, but this is encoding not decoding) so I'm not immediately seeing a connection to the problem reported.
The feature was added to the addon in the last two days. You just happen to have needed it as it was merged/built/published.
Remove all HDMI settings from config.txt. HDMI settings belong to cmdline.txt now.
Note that 'kernel param' settings in cmdline.txt are completely different from old-style config.txt settings. If you put the old-style settings in the wrong file the board probably doesn't boot.
I don't see the errors reading firmware/version that you do when running flirc_util, e.g.
ROCK5B:~ # flirc_util
[W] lib/cmds.c handle_longopt(180): `version' doesn not take '--pretty' option
flirc_util version b71c83813a98efb92d565792bdcab96efa3533e0 [b71c838+]
Firmware Detected
FW Version: v4.10.1
SKU: Flirc 2.0 [dori]
Branch: release
Config: release
Hash: 0x26D56A46
Commands:
delete Delete next remote button flirc sees from saved database
delete_index Delete button at index displayed in `flirc_util settings`
device_log Displays the log on the device
dfu Kick in or out of Device Firmware Upgrade mode
format Remove all saved buttons from flirc
help Show this help. Also try `help <command>`
interkey_delay set the interkey delay
loadconfig Load configuration file from disk to flirc
loglevel set the log level
mode Enable or disable a usb mode
noise_canceler Noise canceler to prevent phantom presses
normal Put flirc in normal user mode
profiles enable or disable built in profiles
reboot Displays all the devices current settings
record Record infrared buttons and link them to HID keys
record_api Advanced button recording
record_lp Record a long pres key
record_macro Record a macro key
rom_table enable or disable a give rom table
saveconfig Save configuration file to disk
script run a command script
sendir Send a packet over the IR transmitter
settings Displays all the devices current settings
sleep_detect Turns on sleep/suspend detection
unit_test Performs a self test
upgrade Uploads new firmware image to flirc hardware
version Print the application version and device version if connected
wait Waits for the device to be plugged in (used for scripting)I'd suggest contacting flirc support as they know their hardware better than we do.
The upstream kernel p200 dtb is for devices using external-phy (rgmii) with Gbit Ethernet and the chip on reg=3 of the MDIO bus.
The upstream kernel p201 dtb is for devices using internal-phy (rmii) with 10/100 Ethernet.
The downstream kernel gxbb_p200_1G_100M_RealtekWiFi file uses rmii so p201 upstream is the correct one to use.
In the upstream kernel both p200 and p201 have identical SDIO (WiFi) configuration inherited from the p20x.dtsi. This is set to probe SDIO reg=1 and although it is technically possible to have other SDIO reg assigments on the bus, I have never seen any Amlogic device with any SDIO module use anything other that reg=1, so the p201 dtb should result in SDIO probing and loading of the WiFi driver in the image. I'm not seeing any SDIO probing so you either share a log from the CE image to prove something exists, or we believe the upstream kernel logs that show a MediaTek MT7601U chip connected to the USB bus. Assuming this is not an external USB dongle; the chip is internally wired. If true it will be the first time I see that specific chip used in an Amlogic box, but it's a cost-engineered (cheap) internal-phy box with 10/100 Ethernet so using a cheap USB chipset internally is completely plausible.
The latest RK356X, RK3576, and RK3588 images in my test share have a fix for broken multi-channel audio (missing channels and speaker placement issues). Enjoy 
No idea .. perhaps see if the LE13 images in https://chewitt.libreelec.tv/testing are any different?
It won't be unless you install the "flirc_util" add-on from the LE repo and then logout/login over SSH.
There's been recent activity here: https://github.com/LibreELEC/LibreELEC.tv/pull/10592 .. but it reads like some further work and testing is required before things are mergeable.
I'm using a BT remote with an RPi5 on LE13 nightlies for years so I don't think there's a general issue with Bluez. The only issue I have is a few unmapped keys, but that's laziness on my part. I keep telling myself it's a "rainy day" task to update the hwdb file, but as it only rains twice a year (briefly) here it never happens 