A couple of months ago I tested with the gpio-shutdown dtoverlay on LE9 and it worked as expected (power off and on by a button on GPIO3) -no need for any additional python scriptery.
I haven't used the gpio-poweroff dtoverlay yet, but if it doesn't work please drop me a line and I'll look into it.
so long,
Hias
This can be changed easily with a kodi keyboard.xml file. Just map the "power" key to "ShutDown()" - the default is "ActivateWindow(ShutdownMenu)".
so long,
Hias
If you dont't have /sys/class/rcX, then the remote receiver is quite certainly a HID device and the remote appears as a keyboard to the system.
Changing scancode-to-keycode mappings via ir-keytable is not possible in this case, but you can change the keycodes with a udev hwdb file - see eg here: Ok button doesn't work on H1 remote
To see all keycodes generated by the receiver you can use evtest (from the system tools package).
Some of these "keyboard" remotes are routed through eventlircd, by udev rules matching the device attributes. In that case the button presses show up as LIRC events instead of keyboard events in kodi debug log.
so long,
Hias
The original xbox IR receiver is no longer supported but with another IR receiver (eg the one integrated into NUCs or an MCE USB receiver) and the lircd.conf file posted in this thread it should work.
so long,
Hias
This is already implemented in the LE master branch: systemd: don't power off when power button is pressed by HiassofT · Pull Request #2658 · LibreELEC/LibreELEC.tv · GitHub
so long,
Hias
USB storage devices not behaving as they should is unfortunately not too uncommon - see the unusual_* files in the linux kernel: linux/drivers/usb/storage at master · torvalds/linux · GitHub
Please post your dmesg after an error has occurred - there should be some hints in it what went wrong.
You can then try to enable various quirks, add "usb-storage.quirks=XXXX:YYYY:Z" to the APPEND line in syslinux.cfg and check if they resolve your issues. Details about the available quirks are in the kernel documentation - look for usb-storage.quirks here: The kernel’s command-line parameters — The Linux Kernel documentation
As a wild guess you could try to disable UAS mode (quirk "u") and/or limit the number of sectors to transfer at a time (quirks "g" or "m").
so long,
Hias
udev rules and separate scripts are the ancient method to configure the card, since LE7 the card is setup via .config/rpi-cirrus-config.sh - see also previous postings in this thread, eg Wolfson/Cirrus Logic audio card is now supported in official LibreELEC builds
Just copy the sample file in the config directory to rpi-cirrus-config.sh and add the following 2 lines
setup_line_in 8
set_mixer $line_out_signals $line_in_signals 32 2so long,
Hias
No soldering required on RPi3, you just plug in the audio card and screw in the board standoffs. Pretty much like Ikea 
If you want to have all of that in a case it's best to stick to the well known vendors (HifiBerry, Justboom), they also sell cases for RPis with their specific DAC/Digi/... boards. Standard RPi cases are too small (the boards add height) and larger cases for other HATs might have the cutouts for RCA/Toslink/... connectors in the wrong place.
Of course you can use Lego, wood, ... to build your own case - if you like.
so long,
Hias
ccache: error: execv of /home/openkd/http://LibreELEC.tv/build.LibreELEC-S905.arm-8.2-devel/toolchain/lib/gcc-linaro-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc.real failed: Exec format error
Amlogic (and Rockchip) use precompiled compilers to build the kernel. These are 64bit binaries, so if you try to run them on a 32bit system you'll get that error.
You could either change the gcc-linaro packages to download 32bit compilers or just switch to a 64bit build host - the latter would make building LibreELEC a lot easier.
so long,
Hias
make[1]: Leaving directory '/home/openkd/CoreELEC/build.CoreELEC-S905.arm-9.0-devel/openssl-1.0.2o/.i686-linux-gnu'
"i686-linux-gnu" means you are trying to build on a 32-bit system which is not supported - your build host has to be 64bit.
And you seem to try building CoreELEC, not LibreELEC. So please post your question(s) in the CoreELEC forum https://coreelec.org/forums/
so long,
Hias
You can use the Zoom setting to get rid of encoded black bars. See Video playback - Official Kodi Wiki
so long,
Hias
You can see what i have changed from the git checkout in my release posts. The 2 you want to look are #26 and #29. They are both running fine in short test without crashing kodi.
Thanks a lot for the info! Glad you got it working and that there doesn't seem to be an issue with gcc 8.1.
so long,
Hias
Yes. df52423 is the LE master tree from 2 days ago (just checked).
Do these builds contain the exact same set of patches, as the working gcc 7.3 build and do they crash kodi or not?
so long,
Hias
A fresh full build of df52423 with the changes from the quote is working right now.
Thanks for testing!
Have you tested the same set of patches on top of LE master tree as well?
If not, testing that or on top of the gcc 8-1 bump commit (01391bb7db) would give some hint if the crashes are related to gcc 8.1 or not.
so long,
Hias
Interesting, it's crashing in python. No idea why that's happening but 2 educated guesses:
sky42 could you test if a plain LE master build from commit bfd442ae06 also crashes? That's the commit before the gcc bump from 7.3 to 8.1. We had an odd issue with the Netflix addon after the gcc bump so it would be good to know if the gcc bump caused other side effects we are not aware of.
Another thing to try would be bumping kodi from 593949a to 002ec67a82. That's the version I've been running the last few days and I had no issues with it on RPi2.
so long,
Hias
Instead of using userspace Lircd it might be better to use the more modern in-kernel / ir-keytable configuration - read this wiki page for details: Infrared Remotes [LibreELEC.wiki]
If you do this it's best to disable Lirc in LibreELEC settings and rename (or remove) your .config/lircd.conf file and other lirc-related configurations so they don't get in the way of ir-keytable configuration.
so long,
Hias
Thanks a lot for the feedback!
I'm still a bit puzzled why gpio-ir works better, but then I'm glad it does and I hope it stays this way.
so long,
Hias
Ah, very interesting - I had expected that lirc-rpi and gpio-ir performance would be about the same.
Out of curiosity: are you still using Lirc with gpio-ir or have you switched to ir-keytable/in-kernel decoding?
so long,
Hias
