Posts by chewitt

    ISTR the pre-built u-boot that Hardkernel share for C1 doesn't support some of the bootscript content that we use to hook the boot process and run LE instead of a conventional distro with separate kernel and initramfs. I did start to look into it, but my u-boot skills aren't awesome and what I do know is relevant to modern u-boot, and C1 u-boot is an archaeology trip back to 2011. The only way I was able to boot the board is entering the u-boot console and manually running some bootscript commands. I forget now what the working state of https://github.com/chewitt/LibreE…1a88eaf5421f267 and other commits in that branch are, but I from commit names I think I was just experimenting and it wasn't 100% working. It's been 18-months since I did any work on AMLMX, but Martin B was recently threatening to do some more kernel work over the winter, so maybe I have to dig the board out again early next year (for the annual rebase onto current LE).

    NB: That error in mount_flash warning seems to be a thing sometimes. Perhaps try hardcoding /dev/mmcblk1 devices instead of using LABELS or GUID strings.

    The idea of watching videos at the wrong speed is abhorrent to me, but one mans chalk is another mans cheese. If the old release works better, use it. There's no rule that says "thou must upgrade" all the time. There are still ~40% of our active RPi installs on LE 9.2.8. Kodi stats are less accurate than ours (we have some basic stats, they only estimate) but the current percentage estimate means my guess above is missing a bunch of zero's.

    That screen only appears when the board thinks there is no card present. Perhaps a glitch in the SD card reader hardware or the precursor signs of a dying card (back-up the content if you care about it, cards don't last forever).

    It looks like RGB-pi requires a .dtbo (overlay) file to work and this is not present in the upstream Raspberry Pi kernel repo and thus isn't included with LE images; hence when you add the necessary things to config.txt it doesn't work.

    You can try the dtbo file here https://github.com/mortaca/RGB-Pi/tree/master/overlays and copy to /flash/overlays (or drop onto the SD card when not inserted into the Pi) but this file was compiled around 7-years ago so there are no guarantees it will work with the modern Linux kernels LE uses today. The source file is there though, so you could always build a custom LE image with changes to add it or with changes to fixup it's content to work.

    Anyone can contribute documentation to our wiki .. markdown isn't hard to learn.

    Tvheadend will also be getting a new website/forum soon and then one of the 'elephants in the room' is for them to sort out the multiple (but all outdated) sets of documentation they have.

    WiFi uses the SDIO bus which supports device discovery so as long as device-tree contains a reference to some form of WiFi device it will normally result in probing and the drivers being loaded. BT is a serial UART device so the're no discovery and device-tree needs to contain the right GPIO and compatible details for it to work. The Q200/Q201 device-trees both assume a Broadcom module. If you have something else e.g. QCA9377 then the details are wrong and .. it won't work. It's not too hard to create custom device-trees but if you need BT support the easiest option will be a $5 generic USB BT device from Amazon/eBay.

    You can implement a custom keymap that maps a button to the "RunScript(script.scriptname)" action which will execute the same name Python(3) script. I forget what the correct path is, but probably /storage/.kodi/userdata/Scripts/scriptname.py (note Scripts not scripts) and from the script you can drive whatever webhook things you like. If you're looking to monitor Kodi activity and drive actions automagically, i.e. press play and fire something to a webhook, that should be possible using the JSON-API, but to ensure that runs all the time you're probably heading down the custom add-on route. I'm not aware of anyone creating a webhook add-on and I can't point you to any specific guides on how to build things, but if anyone already trod the same path there's probably useful info in the Kodi forums (more than here).

    It looks like pipewire might be here to save us and get Hyperion working again. Routes video from Wayland.

    Your incorrect assumption is that LE runs under Wayland. We don't, a) because it's not needed and we use GBM natively, b) if we did use Wayland we'd lose the ability to switch refresh rates to match media spec for the best playback experience.

    Your personal "most important feature" is probably used by 0.00001% of Kodi users, and that's why it's not the default or on some kind of hot-button. Fortunately Kodi is an extensible and scriptable platform so you should be able to (with a little fiddling) toggle the sync-playback-to-display feature via a JSON API request which can be put into a shell script which is mapped to a spare remote button through a custom keymap. There's no HOWTO guide for doing exactly that I can point you to, but all the individual bits for doing that workflow are out there in wiki's and such.

    LibreELEC is an intentionally simple distro but we should support all the normal bash scripting commands because we use the same things within the distro. Note that we use busybox for lots of things which can reduce command options. The full /usr/bin/vcgencmd binary exists in the image already.

    For things like GPG and Dropbox we don't have any native capabilities and unless you want to build custom images that you added more packages to (do-able but probably more work than you're looking for as we build everything from source) the main escape route will be using Docker (installed as a Kodi add-on) to run a container that provides whatever binary that you're missing. You get bonus credit for authoring your own container that adds all the missing stuff in one container to avoid running loads of containers (overhead you don't need, and the one thing that's likely to result in high temps etc.).

    NB: While I understand that some users like to monitor everything, the controlled and appliance-like nature of the distro also largely eliminates the scenarios where general purpose distros drift into bad shape over time requiring monitoring. LE is super lightweight and highly optimised for Pi hardware and with normal movie watching duties the only thing that's needed for avoiding high temp and under-volt scenarios is a half-decent passive or fan-cooled case and the official PSU. I've managed enough infrastructure over time myself to understand the inner need to monitor, but watching movies is more fun ;)