The Libre.Computer boards aren't following the Android box reference designs and have no WiFi/BT hardware so 100% guaranteed those devices will be missing. I'd experiment with some of the Generic box gxm device-trees like Q200/Q201.
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).
-
Can you help me?
We don't provide BIOS software that implements support for missing features, so probably not..
-
.. it's the kind of thing you'll have to try yourself to find out, staff won't have the hardware
-
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.
-
You'll need to explain which device-tree file is being used and which WiFi/BT module is in the box - we (me) are not mind-readers.
Read this for remotes: https://wiki.libreelec.tv/configuration/…ration-advanced
Reboot instead of halt is possible. You might want to try current nightlies (not sure what 'latest' image you're using) as I've had reports that magically it started working there on some other boards.
-
I'm an hobbist and a bad developer, but I'll try. I'll try also to buy this board.
Chat to Da and he'll probably just send you one. Worst case feel free to acquire one and expense to LE via OpenCollective. We can always discuss that process more in Slack if needed.
-
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
-
ISTR it's not functional unless "sync playback to display" is enabled .. and for general best results with Kodi on a normal TV you want to leave that setting disabled.
-
That patch is included in the newer kernels used in LE12 nightlies, so updating will make the harmless but user confusing message go away..
-
I'd update to current nightly images (LE11 or L12) as there are some improvements that might be relevant.