It's not obvious why do you think so.
Check the current mapping with ir-keytable -r
If it's not what you expect, check the path to keymap file (path-to-new-keymap in /storage/.config/rc_maps.cfg file should be /storage/.config/rc_keymaps/yourfilename ) and the keymap file format (for editing use nano from LE command console and not Windows editors except Notepad with Word Wrap disabled).
strange we haven't merged yet anything that should stop them
but there are no addons available yet for LE11 (intentionally) maybe there are some problems
I did not have time to analyze deeply but the kernel log complained about writing error to i2c related to DVB-T stick (even after unplug / plug and even after reboot).
Edit - with LE 11 Nightly 20210819 it works again but kernel log is quickly filling with: rpivid feb10000.codec: PPS changed (seen in past, on LE 10 Nightly 20210808 it was rare)
Try to run ir-keytable -a /storage/.config/rc_maps.cfg -s rc0
The LE11 builds are not really usable yet.
Yeah I can confirm that as I have already tried LE 11 Nightly and my DVB-T USB stick stopped working so I had to revert back.
OK, thanks for your reply. I'll give it a try when I find some free time.
Edit: After upgrade to LE 11 Nightly 20210819 the sensor works again with the old script.
I am using AHT10 sensor, so far with Python script, based on this project: GitHub - gejanssen/aht10-python
Unfortunately, in latest LE 10 Nightly builds (perhaps after move to 64 bit kernel) it stopped working, it's a timing issue with i2c communication which returns IO Error 121 or nonsense results. Despite I tried to struggle with time.sleep wait constants, couldn't get it working again. It looks the python script should be improved to communicate with AHT i2c device properly but I am not able to tune it up.
The current script looks like:
#!/usr/bin/python3
# https://github.com/Thinary/AHT10/blob/master/src/Thinary_AHT10.cpp
# https://myhydropi.com/raspberry-pi-i2c-temperature-sensor
# cleaned up and documented smbus 1 and some errors
# GJ 03-2020
# i2cdetect -y 0
import time
import sys
sys.path.append('/storage/.kodi/addons/virtual.rpi-tools/lib')
sys.path.append('/storage/.kodi/addons/virtual.adafruit-libraries/lib')
sys.path.append('/storage/.kodi/addons/virtual.system-tools/lib')
import smbus
# Get I2C bus
#bus = smbus.SMBus(0) # Rev 1 Pi uses 0
bus = smbus.SMBus(1) # Rev 2 Pi uses 1
# when you have a 121 IO Error, uncomment the next pause
time.sleep(1) #wait here to avoid 121 IO Error
config = [0x08, 0x00]
bus.write_i2c_block_data(0x38, 0xE1, config)
time.sleep(0.05)
byt = bus.read_byte(0x38)
#print(byt&0x68)
MeasureCmd = [0x33, 0x00]
bus.write_i2c_block_data(0x38, 0xAC, MeasureCmd)
time.sleep(0.05)
data = bus.read_i2c_block_data(0x38,0x00)
#print(data)
temp = ((data[3] & 0x0F) << 16) | (data[4] << 8) | data[5]
ctemp = ((temp*200) / 1048576) - 50
print(u'Temperature: {0:.1f}°C'.format(ctemp))
tmp = ((data[1] << 16) | (data[2] << 8) | data[3]) >> 4
#print(tmp)
ctmp = int(tmp * 100 / 1048576)
print(u'Humidity: {0}%'.format(ctmp))I suppose the better results could be achieved with using directly AHT libraries but in Adafruit Libraries Add-on 10.0.0.107 only these are present:
ls /storage/.kodi/addons/virtual.adafruit-libraries/lib/
Adafruit_ADS1x15 Adafruit_LED_Backpack Adafruit_SSD1306
Adafruit_ADXL345 Adafruit_LSM303 Adafruit_TCS34725
Adafruit_BMP Adafruit_MCP3008 Adafruit_VCNL40xx
Adafruit_CharLCD Adafruit_MCP4725 Adafruit_WS2801
Adafruit_DHT Adafruit_PCA9685 SI1145
Adafruit_GPIO Adafruit_PureIO
So the quiestion is - could be possible to extend the Adafruit Libraries Add-on a bit please, at least with AHT?
Yeah I understand, will try to match all the debug requirements next time but as I am using almost only the Live TV in LE, it's hard to provide you with the 'corrupted' files. I know it's hard do debug if you can't reproduce it. But now it's really easy to crash Kodi when the TV signal is weak. Never seen it in past. The question is how sensitive it is over the corrupted multimedia files...
Thanks for your hard work.
Thanks for the feedback.
I have put the Kodi crash log in another issue report with no reaction ( LE 10 Nightly unstable / Kodi crashing on RPi 4B ).
This time the kernel panic stopped my debug activity. 
But I suppose many Kodi crash logs are still there so I could publish them (couple days later as I am leaving for holidays today) if there's a chance anyone will have a look on it.
In fact the LE stability is worse than earlier in LE Nightly builds for RPi 4B. In past, Kodi never crashed completely when the Live TV stream was temporarily corrupted.
Regarding to OOM killer - in past when it happened sometimes (usually when the Timeshift operations was requested) the Kodi usually restarted and worked for another long period. These days I saw the situation that Kodi was not able to start again. Looks as a memory leak or something like that.
I am afraid this kernel has more issues than the bug with 2 displays and perhaps should be reverted to earlier version.
I have experienced Kodi crashes and in the end kernel panic due to exhausted memory.
Connect to your RPi 4B with SSH console and copy / paste these commands there:
#
rpi-eeprom-update > /tmp/temp.txt
echo >> /tmp/temp.txt
vcgencmd bootloader_version >> /tmp/temp.txt
echo >> /tmp/temp.txt
vcgencmd bootloader_config >> /tmp/temp.txt
echo >> /tmp/temp.txt
lsusb >> /tmp/temp.txt
echo >> /tmp/temp.txt
uname -a >> /tmp/temp.txt
echo >> /tmp/temp.txt
#Then disconnect the HDD, connect it again, copy / paste these commands as well:
#
dmesg | tail -n 50 >> /tmp/temp.txt
paste /tmp/temp.txt
#Then share the HTTP link from paste here.
...new kernel hangs during boot if two HDMI devices are connected (checked that here with two monitors).
Yes that was my case as well ( 2 FullHD displays attached, Secondary disconnected from power).
As soon as I started RPi OS (with earlier kernel), terminal window (that I needed for analyzing the issue) opened on Secondary (unpowered) display and the most easy way to get everything displayed on Primary display was to disconnect the HDMI cable from Secondary display and reboot RPi.
So my assumption that restoring the distroconfig. txt to earlier form did fix the issue was wrong...
Thanks for the explanation of the issue root.
Fixed by restoring distroconfig.txt from backup.
For those who fell into the same trouble, it should look like:
# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright (C) 2019-present Team LibreELEC (https://libreelec.tv)
# WARNING: DO NOT EDIT THIS FILE - IT WILL BE OVERWRITTEN WHEN UPGRADING!
dtoverlay=vc4-kms-v3d,cma-512
dtoverlay=rpivid-v4l2
disable_overscan=1
disable_fw_kms_setup=1As I had to turn off / on the hanged RPi, after LE recovery I found this message in kernel log (dmesg) :
FAT-fs ( sda11 ) Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
So another necessary task was to Remove dirty bit using:
fsck.vfat /dev/sda11
Edit - see the post #8
I have upgraded from LE 10 Nightly 20210717 to latest 20210720 but it does not boot on my RPi 4B / 2GB from HDD connected through USB/SATA adapter anymore. 
There is a multiboot (RPi Noobs, menu starts without issue and when I select RPi OS it starts OK).
Boot to LE ends with a black screen and it's not even visible on network anymore.
I'll try to investigate from RPi OS what happened with LE filesystem and if it's possible to recover it somehow.
It looks several latest LE 10 Nightly builds are extremely unstable on RPi 4B - Kodi is crashing as soon as the Live TV signal is weak. Then LE starts in safe mode.
Please note the LibreELEC is a custom OS build which is lightened and tuned for multimedia. So many commands from a 'full' RPi OS won't work as they are missing.
I have no experience with Docker but perhaps you could build the rpi-minecraft container under standard - 'full' - RPi OS and then run it from LibreELEC's Docker.
It's strange. I am running the LE 10 Nightly (currently 20210703) on RPi 4B, using output GPIOs 4, 6 and 27 for relays and LED, also in BCM mode and did not encounter any issue so far.
There's a difference between GPIO pins so it may play a role... For instance, GPIO 13 supports hardware PWM while GPIO 4 does not.
Maybe it depends on which GPIO pins are you using. For instance, some GPIOs does not keep their state during reboot.
I am running the LE 10 Nightly (currently 20210703) on RPi 4B, using GPIOs 4, 6 and 27 for relays and LED and did not encounter any issue so far.
Perhaps the solution is described here: [SOLVED] AutoMounting of Partition Filesystems