Please use the "Upload latest Kodi log" function in the LibreELEC settings addon and post the URL. See here for details Provide Log File [LibreELEC.wiki]
It would also help if you could test with the previous LibreELEC beta releases and post which ones work. You can download them directly from one of the mirrors Mirrors [LibreELEC.wiki] - just download the LibreELEC-RPi2.arm-8.95.XXX.tar, copy it to the Update samba share and reboot.
so long,
Hias
Use pin5 - it has an external pull-up on the board so it's guaranteed to be high as soon as power is applied.
You can also use the gpio-shutdown overlay with other GPIO pins to get a shutdown button if you don't want to use pin 5 for that.
Powerup from shutdown by shorting pin 5 to GND is independent of overlays, that's a feature of the RPi (GPU) firmware which will always work.
so long,
Hias
Without external hardware you can't turn off the RPi completely. You can use eg the gpio-poweroff overlay to signal shutdown to an external circuit which then cuts power to the RPi.
so long,
Hias
Have a look at the gpio-shutdown dtoverlay https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/readme#l692-l721
By shorting pin5 and pin6 on the GPIO header you can shutdown LibreELEC and if you then press the button again it'll power up again.
so long,
Hias
A faulty SD card might cause those issues but most of the time it's the power supply. Amp rating on USB chargers usually doesn't mean much and/or the USB cable might not be up to the job and cause a voltage drop. The RPis, especially 3B and 3B+ are very picky about that.
You can easily check that, use the RPi running LibreELEC for a while then ssh in and run
vcgencmd get_throttledIf you get anything else than throttled=0x0 you have a problem.
so long,
Hias
I'm not 100% about the audio issues. Analog audio out of the RPi isn't great so almost no one uses it. Some time ago audio quality was improved via a firmware update (see this thread here Analogue audio testing - Raspberry Pi Forums) but this seems to have caused higher GPU load and people reported issues with HEVC playback or deinterlacing.
Going the HDMI route isn't easy, if you use HDMI then the analog video output will be disabled.
Probably the easiest and cheapest method will be to use one of the plenty RPi soundcards. Hifiberry, Iqaudio, Justboom, Pimoroni pHAT DAC and several others work out of the box (some need a dtoverlay line added to config.txt) or if you want it cheap get some RPi soundcard with a PCM5122 or PCM5102 from Asia - they should work fine as well and provide a lot better audio quality than the on-board output.
so long,
Hias
If you add overscan settings in config.txt you also have to set overscan_scale=1, otherwise the settings don't apply to kodi (they only affect the framebuffer that's shown during boot). While that removes the borders you'll still get a stretched display on 16:9 screens in anamorphic mode which you'll need to compensate for in kodi screen calibration.
So, it's better to use only kodi's screen calibration to set both the corners and the aspect ratio, that's easier to do and also avoids having 2 scaling steps (one from kodi and one from the firmware).
so long,
Hias
This is normal. ICE1724 only supports 32 bit format and the default alsa configuration (default:0 pcm) uses the dmix plugin with a fixed 48kHz rate - this is identical to how it works on other Linux distributions.
You either need to access the hw: device in 32bit or use plughw so it can auto-convert other formats to 32bit.
so long,
Hias
This change has been included in Linux kernels for almost 11 years now.
commit d16be8ed69f3e59d36be8c422508c3a10082fdaa
Author: Pavel Hofman <[email protected]>
Date: Thu Mar 20 12:10:27 2008 +0100
[ALSA] ice1724 - Improved the Juli rate settingIf you have issues we need some more info and a description what exactly doesn't work.
so long,
Hias
The log shows you are running some community build from early October 2018
18:50:00.767 T:139930272209024 NOTICE: Running on HTPC (community): devel-20181005235021-6499607 9.0, kernel: Linux x86 64-bit version 4.18.10Can you please test with the latest official LibreELEC version (currently 8.95.002)?
so long,
Hias
Actully better to bui air mouse remote, looking how does it work after drop old remote.conf it's not worth, at least for me, not enough patience to use ir remote now. No matter what I do or configure, unable to fire fast events by continous fast key press, it's very frustrating especially when I need to scrool down 100 channels in pvr mode. I would advice to return back to remote.conf until this issue is resolved but I know this is not gonna happen.
If you want precise control then use an IR remote using the rc6 protocol (eg Microsoft MCE remote) or the rc5 protocol (eg Philips or Hauppauge remotes).
IR remotes using the NEC protocol (eg most of the cheap remotes from Asia) won't work as precise as the former ones as there's no toggle bit in the protocol.
You can work around to some extend by reducing the IR timeout (ir-ctl -t ...) but in the end you got what you paid for 
so long,
Hias
Just tested and it's working fine here in Austria on RPi3B+, LE 8.95.002, Netflix addon v0.13.21, inputstream.adaptive v2.3.12.0.
IIRC I usually needed to restart kodi (or reboot LE) after widevine updates, otherwise I'd get the spinning circle and was then dropped back to the list after a couple of seconds. So doing a reboot after widevine installation or update won't hurt.
so long,
Hias
This is a line I was already searching for a long time ago and eventually figured it out myself. This should be put somewhere in the LibreElec remote wiki. It would have spared me a lot of time figuring everything out.
To be honest, as well the kodi wiki as the libreElec wiki are a little bit confusing about this matter.
I just added a paragraph to the Introduction section of the IR wiki page, with links to the relevant kodi wiki pages. Hope this makes things clearer now.
so long,
Hias
Can I bring back old approach with remote.conf from LE 8 without need to recompile image?
No, this stuff is gone for good. AML now uses the same method to support IR remotes as all other platforms.
so long,
Hias
I am still confused with that. In general, no lags but if (for example) I keep pressing Down button very quickly, 1 of 3 events are lost.
This is caused by a combination of using remotes with the NEC protocol (which doesn't have a flag if it's a new button press) in combination with the old 3.14 kernel (which is missing the IR optimizations found in current linux kernels).
You can get better remote response by running
ir-ctl -t 30000Just add it to autostart.sh (you can test with lower values, down to 10000-20000 as well)
so long,
Hias
Best stick to the kodi button names in the devinput section of Lircmap.xml and use the keycodes that are mapped to kodi buttons (eg KEY_INFO, KEY_MENU, KEY_FORWARD, KEY_REWIND, ...).
A full list of kodi button names is in the IRTranslator source file irtranslator.cpp#l164-l229
As explained in the Kodi wiki LIRC - Official Kodi Wiki remote button mapping is a two-step process. First Lircmap.xml maps a KEY_xxx code to a kodi button name and then you assign actions to kodi buttons in remote.xml
so long,
Hias
What kind of remote are you using and did you create the IR keymap file by yourself?
If you create an IR keymap it's best to stick to the keycodes that are usually found on remotes (see eg the rc6_mce keymap of the Microsoft MCE remote) as these will work out-of-the-box in kodi. More details are in the wiki Infrared Remotes [LibreELEC.wiki]
If you are using an RF remote it's not using the ir-keytable configuration discussed in this thread - in this case please open a separate thread.
so long,
Hias
Remote input is handled differently than keyboard input.
Kernel input events from remotes are translated to lirc events by eventlircd, then received by kodi as lirc events and run through the Lircmap.xml -> translations in Kodi and are finally mapped by <remote> blocks in keyboard.xml files.
so long,
Hias