If you append video=HDMI-A-1:1920x1080M@60 to boot params in cmdline.txt (to force the initial kernel DRM state to 1080@60) does that solve the issue? - I'm wondering if it's trying to output at 4K (for reasons unknown) and the TV isn't liking that.
I'd also be interested to know what shows on screen if you remove the SD card and let the RPi boot to the test screen. Does it show that an HDMI device (and EDID) are detected?
Argon cases are "the gift that keeps on giving" for support issues 
I'm wondering if this might be relevant: https://patchwork.kernel.org/project/dri-de…s.qualcomm.com/
Snapcast is not something I use so I can't test the theory on casing issues causing problems, but the fix for that has been committed to their 'develop' branch https://github.com/badaix/snapcas…dab403dcb9991b5 so should be in their next release. Once that's tagged we can update/bump the add-on from our side.
I found out that the most recent LE version is 12.2, but I can't update to this version inside LE
Set auto-update to manual then change the release series from LibreELEC 12.0 to LibreELEC 12.2, and then the 12.2.0 release will be available in the list of releases you can update to.
Am I doing something wrong? I've got expert mode turned on.
The wiki article that mentions the PQ setting links to two GitHub pull requests; one for Windows, one for Android. TL/DR: the setting is not currently supported on Linux.
It's always cheaper to acquire something locally from Amazon than have people ship something to the UAE, and we have funds for that kind of thing .. so it's not an issue. Time is a greater factor.
You are using the Q201 device tree file which is created from:
Neither of them describes the &uart_A connection required for BT to work, e.g.
It's probably easiest to experiment with some other GXM device-tree files as GXM hardware is all pretty similar and other files will probably give you a working (or working okay enough) system.
It's interesting that N150 might also be impacted with that issue, I'd previously believed it was limited to N100.
I probably need to order a box to do some testing and experimentation with, although the current queue of stuff on my desk is getting long and I'm probably lying to myself about available free time.
Would you say this is acceptable or is there another model you'd recommend?
We avoid recommendations on wireless kit as the advert almost never tells you which chipset is inside the device, and that's the one piece of information needed to assess whether it will work OOB or not. That specific specific advert explicitly states that device does not work on LE, but that's probably based on outdated info .. so who knows.
Modern SD cards are only marginally slower than eMMC storage chips from 2014. You should also experiment and see if the AMLGX image, which is not as fully-featured as older vendor kernel images, works for you. For a good number of people it does, but it's not for everyone.
H.264 hardware decoding failure on Raspberry Pi 5
RPi5 will never hardware decode H264 media (as it has no H264 hardware decoder) .. so that's incorrect.
Hard to blind guess what the reason for software decoding to fail is. The log snippet is irrelevant, and the full log is not a debug log so we can't see any of the useful media negotiation info. Go create a a proper debug log.
CatchupTV is not on the banned list. Other items are though.
Here's the list: https://kodi.wiki/view/Official:Forum_rules/Banned_add-ons
Doesn't R40 supposed to support VP9 decoding? Why isn't hardware decoder used?
Hardware supporting it and someone coding drivers to implement that support are different things .. is probably the reason.
Read: https://wiki.libreelec.tv/hardware/amlogic#installtointernal
TL/DR: You either stick with the old install on eMMC, or boot something newer from an SD card.
LE 12.0 to LE 12.2 does not require a clean install. The core OS is updated, but it's the same Kodi version in both images.
I've no idea what the problem could be, but if you see the splash screen the OS has booted and should be running. However Kodi has not started and thus nothing gets rendered over the splash screen. If you add "ssh" to kernel boot params in cmdline.txt the SSH daemon is forced on and you can probably SSH in to capture the log from the device. Or the Logfiles SMB share might be accessible over the network.
The log isn't a debug log and the catchup plugin you are using hides all the useful ffmpeg information on the media. Then I noticed banned add-ons installed, and found something else to do.
