and also used the system to install Transmission, Qbittorrent
I don't know what your channel is (and not sure I want to be informed). However I will clearly state that if your channel instructs people on how to setup download (aka. piracy) rigs on our distro you are not welcome in this forum.
Amlogic mmc controller issues normally exhibit with high-speed card modes and faster speeds and the current/upstream U9-H device-tree is already defeatured to run at a minimum level. The usual way to rule out those issues with modern cards (that have fancy modes and such) is to test with an old, slow, low-capacity card. I have some 2GB cards which aren't much use for an install but are reliable for that kind of testing. Most vendor firmware will power-up the USB section in u-boot automatically which will make the AMLGX boot media discoverable and useable there too, so perhaps try with a USB stick instead of SD card.
NB: For power-issues I'm thinking the device-tree description of how things are connected (which influences driver probing and power sequencing) might be off; not that the PSU itself is bad (although that would also cause problems). The vendor kernel has drivers for a Minix MCU chip which is not supported upstream; the MCU does handle some power things, but it's mostly low-level and the essentials are configured by u-boot so Linux shouldn't really need to care.
I'm guessing, but using a static EDID config should solve this: https://wiki.libreelec.tv/configuration/edid#raspberry-pi
RPi3 and older have no hardware decode support for HEVC but the legacy display pipeline was tweaked (using never upstreamed patches) to offload some compute tasks to the GPU and this achieves enough headroom for low-bitrate 1080p HEVC adnd low-bitrate 720p DRM'd HEVC media to be software decoded. The current display pipeline hasn't reimplementated that (50,000 LOC) patchset becaue it would require a large effort and more importantly, the goal is run upstream-only or minimally-patched code and it was ultimately a clever hack that upstream maintainers aren't going to accept.
IIRC RPi 4/5 only support Vulkan under Wayland, and we do not run Kodi under Wayland because Wayland does not support refresh rate changing for optimal media playback. So yes FFMpeg added some support for DV but the devil is in the details and this is not a usable solution for our use-case. I'd also argue that using shaders is not "true" DV support; it's simply a way to get DV encumbered media to display with an acceptable (but not exact) on-screen appearance. True support requires knowledge of the proprietary stuff or a clean-room implementation. The former won't happen because it torpedo's Dolby's commercial model and the latter is rather unlikely since it will require a massive effort and the Linux community generally prefers to make a minimum acceptable effort when the target "standard" is vendor proprietary crap. I'll update/reword the wiki article a little to prevent further 2+2=5 conclusions.
Pastebin the full debug log not the snippet please (use "pastekodi" in the OS).
If the device is booted from USB? and then the device unmounts the OS will mark things read-only and a bunch of things will stop working. Run "journalctl -f" and you might get lucky and see somehing in the journal before things start to fail. If you're unable to SSH in then it's likely the connection drops so you won't be able to run dmesg.
I mostly see people trash-talking 4.3 because there's no direct upgrade path from 4.2 (and thus some effort is needed to make the switch) and because development has rolled on forever which created the wrong impression. If there's a factual problem (not an opinion problem) it needs to be reported.
is gxm_q200_3g my best dtb? I have always used that in the past but dont know which one i should actually use
It will probably work (other than BT). If it doesn't you'll (emphasis on the you) will need to experiment, but if chasing BT support you can skip the effort as I looked and there are no GXM device-tree files with support for QCA9377 modules in the upstream kernel so you won't find one. Running some fdtput commands from userspace can probably temp-fix the Q200 dtb file.
[ 512.554914] mmc0: card 59b4 removed^ at that point the system is screwed because the OS is booted from the SD card device; hence all the "EXT4-fs error" messages that are logged. I'm only surprised it doesn't fail more completely/spectacularly.
I have a hunch this is a power problem, but figuring it out might be a challenge. When you start Kodi the GPU is used for the first time which increases power demand on the system. The current assumption is that the box follows the Q200 reference design (the legacy device-tree suggests this: https://github.com/LibreELEC/devi…inix_neo_u9.dts) but there are probably differenes. I do have the schematics for the box, but I'm not the greatest reader of them.
I'll send you a PM re the box.
The Pi devs are good at upstreaming their changes these days but there's always a delay between them fixing or proving something and getting patches into an upstream kernel so we use their downstream fork for Pi devices. Allwinner and Rockchip SoC's maintain their own patches for DRM things (mostly codec or core IP support) but most of the V4L2 items are common and upstream.
NB: Be aware that Pi support for RPi 0/1/2/3/4 is stateful (so nothing to do with v4l2_request) for H264 and stateless (using v4l2_request) for HEVC on RPi 4/5 hardware. Stateful things in the upstream kernel are not as mature/robust as stateless.
I'd suggest you reach out to JC and let him know that you're packaging for Gentoo. Although his primary focus is the Raspberry Pi OS, the secondary mission is ensuring Pi hardware works great under any distro, so it's good for him to know how and where his patchsets are being used.
Using an LE12 image put Kodi in debug mode, reboot, than run "pastekodi" after reboot, and share the URL.
It's a nice idea but the advice was wrong. The underlying OS only sees a shutdown event being signalled when the timer expires. The poweroff schedule/timeout is managed within Kodi so the notification has to be implemented and triggered within Kodi. This will also ensure the feature works on all distros and not just LE.
60 seconds of glancing at Kodi code suggests this is involved: https://github.com/xbmc/xbmc/blob…werHandling.cpp .. but I'm not a programmer, so you'll need to take the intiative.
Also see https://github.com/xbmc/xbmc/pull/23299 which is unrelated but will give hints on where to add settings changes. I'd suggest the time value for the notification (how many mins before timer expiry to pop something) is made a configurable item.
Are there builds for S912 gxm_q200_3g
Use the AMLGX "box" image and pick the Q200 device-tree. Read https://wiki.libreelec.tv/hardware/amlogic because the install process is different from legacy images and other distros. WiFi will probably work as the SDIO bus supports discovery. BT will not work as it's a serial UART device and the Q200 device-tree assumes a Broadcom module. Read the current LE release notes to understand the general state of Amlogic support.
The upstream Linux kernel that LE consumes pursues technical standards and this sometimes results in compatibility issues when other hardware vendors implement things poorly. Problems are often resolved, but the changes often take time because Yamaha or the TV vendor will need to accept that it has a bug and then push corrections via firmware changes. It's also possible that the upstream kernel has bugs too of course, though crowdsourced testing via general purpose distros generally spots things.
The downstream Amlogic vendor kernel that CE uses contains hacks to bend 'standards' around the shoddy implementations of other vendors. Some will claim this is a benefit because it's more likely to result in a working result for users, but the hacking can be invasive and the long-term maintainability of the codebase becomes poor. So it's all great until it doesn't work, when it becomes impossible to fix the issue for one vendor/device without breaking support for another vendor/device.
It will be hard for you to pinpoint the problem without an intermediary device (HDFury or similar) to report exactly what is being sent to the TV with and without the AVR inline.
Great playback behaviour/performance with Kodi requires kernel, ffmpeg, and Kodi patches. The kernel patches are normally a mix of things that are already on upstream mailing lists and capabilities that are still work-in-progress. Over time LE accumulated several DRM maintainers and notable contributors as project staff, and we deliberately chat with folks from Collabora and Raspberry Pi who are involved with commercial work in the DRM/V4L2 ecosystem that overlaps with our needs: LE gains from their efforts to push code upstream and they benefit from LE/Kodi being media focussed so our devs/staff are good testers.
Our goal is to have zero Kodi patches (beyond basic distro packaging) but Kodi features for RPi currently depend on some kernel and ffmpeg capabilities which are not yet upstream, e.g. until the Red Hat sponsored 'HDR' working group met earlier this year the forward path for colorimetry and some related userspace bits were blocked pending decisions on how to implement; and as the ripple effects of agreement start to unblock things we are adapting and retooling where needed.
Upstreaming FFMpeg changes is the greatest challenge and we are mostly working through JC (who maintains ffmpeg and related things for Pi foundation) but the changes are often complex, the mailing list is opinionated, and the resulting merge rate is low so there's a large patch backlog. Kodi is using FFMpeg 6.0 currently and won't need to bump to 6.1 for a while, but I understand JC has now started work on that. One of the things we do for JC is test his branch over a range of SoC devices to ensure the changes for RPi don't break support for other SoC platforms (to help with upstreaming).
So as a general rule you should be able to pick and choose the media-related kernel patches LE has for Allwinner, Amlogic, Rockchip into a common 'arm64' codebase with FFMpeg 6.0 from JC and a few Kodi changes from LE. In our own codebase we still keep things a little separate to reduce interdependencies for individual SoC platform maintainers, but there are others that we chat with who are doing that; e.g. the developers behind MiniMyth (single image for all arm/arm64 devices) and Manjaro (similar..)
https://chewitt.libreelec.tv/testing/ <= Images are based on LE12 which has newer everything including a more recent kernel. The amount of change in the Amlogic kernel is low but that also means it's low risk to use (nothing is likely to be fixed or more broken) but we remove the doubt. And I block PM because far too many users seem to think I provide a personal support service. If you see a U9-H box for sale post publicly here and I will see the post, and can follow-up offline.
Use the LE12 codebase for all testing (LE11 and before are now dead/done) and focus on hardware matters because all effort made on updating old add-ons and such is pointless unless the underlying hardware works. Ignore ChatGPT, it's clueless for this task.