Could you please test if you get the same crackling if you use the firmware from 8.2.4 on the working 8.2.3 builds?
Details how to install the newer firmware (and go back to the original one) are here: LibreELEC 8.2.4 causes Slice 3 to hang
so long,
Hias
Could you please post the output of "ir-keytable" and then run "ir-ctl -r", press a button and post the output you got on the console (a sequence of "pulse" and "space" lines).
so long,
Hias
If you are using NOOBS you have to update NOOBS as well.
Unfortunately NOOBS doesn't seem to have an auto-updater so you have to do it manually.
I've posted instructions how to do this here:
Changing from RPi 2/3 to RPi 3B+, FIRST upgrade to 8.2.4 (including NOOBS instructions)
so long,
Hias
There is be a problem if you are using NOOBS. Updating LibreELEC is not enough, you also have to update NOOBS before the SD card will boot in a RPi 3B+.
I've found instructions how to update NOOBS here Updating Raspbian on your microSD for the Raspberry Pi 2 – The Pi Hut and successfully tested this with a NOOBS 2.4 installation.
You can either do this on your PC or with the following commands from within LibreELEC:
mkdir noobs
cd noobs
wget -O noobs-lite.zip https://downloads.raspberrypi.org/NOOBS_lite_latest
mkdir extract
unzip -d extract noobs-lite.zip
rm extract/recovery.cmdline
mkdir part1
mount /dev/mmcblk0p1 part1
cp -r extract/* part1/
umount part1
cd ..
rm -rf noobsso long,
Hias
The firmware is included and updated with LibreELEC updates and usually there's no need to do that independently from that.
If you really want you can update the firmware files manually, at your own risk:
Download bootcode.bin, start_x.elf and fixup_x.dat from the RPi firmware github repository, rename start_x.elf to start.elf and fixup_x.dat to fixup.dat and copy the 3 files to the /flash partition.
You can also easily do that from Windows/Mac/Linux (can be helpful if you messed it up) as the /flash partition is FAT formatted.
so long,
Hias
Wireless will always be prone to interference, a problem which you won't have with a wired ethernet connection. So it's a general recommendation to use wired network, especially for high bitrate files. Buffering can work around short dropouts, but has it's limits.
If wireless works fine for you than use it. But if you get occasional stuttering this can be due to interference and switching to wired should solve it.
so long,
Hias
bcmstat output of non-overclocked 3+:
HW Block: | ARM | Core | H264 | SDRAM |
Min Freq: | 600MHz | 250MHz | 0MHz | 500MHz |
Max Freq: | 1400MHz | 400MHz | 300MHz | 500MHz |so long,
Hias
To use lircd instead of in-kernel decoding you just need to create an empty .config/rc_maps.cfg file, and enable lirc in LE settings, as outlined in the wiki.
It's odd though that your remote suddenly starts lagging. My first guess is that kodi is busy and can't immediately process the remote events. I've been experiencing this on my RPi1 when kodi is updating addons after startup - top shows kodi.bin using all CPU resources and after a minute or so when addons have been updated things (CPU usage and remote response) are back to normal.
To narrow things down run the following command when your remote started lagging:
irw /run/lirc/lircdThis let's you monitor the remote events as they reach kodi. Press a few buttons on the remote and check how long it takes until they show up. If they show up almost immediately here but navigation in kodi is delayed it must be something in kodi. If they are delayed here as well, it's something in the kerne/lirc area.
so long,
Hias
I'm so glad I finally found this post! In the past (10 years ago or so) you had to use setserial /dev/ttyS0 uart none, but now the correct parameter is unknown. The annoying thing is that the systemlog will tell you the wrong parameter when trying to load serial_ir. And the module still will load without prior correct setserial!
The kernel message in the log isn't wrong, with the setserial program you typically find on Linux installations you have to use the parameter "none".
LibreELEC doesn't use this setserial program but the setserial implementation from busybox and there you have to use "unknown".
so long,
Hias
This is rather odd, serial_ir is nothing you'd be using on RPi.
That module is not included in default RPi kernel config but seems to be coming via the dvb drivers / media tree. Still, it shouldn't be loaded, even on x86 (where that driver is occasionally used) you need to manually load it via modprobe or modules-load.d
Could you check if you have something in /storage/.config/modules-load.d or /storage/config/autostart.sh that would load that driver?
so long,
Hias
Sorry for a rather basic question. I like to go through pages pretty quick, and use time skip often (repeat right arrow) during viewing. But with the setting above, when i click the arrows fast (ie, 4x) some are missed (ie 3x are recognized). what variable and which direction would i go to help resolve this? I have also lowered each of the above, and still has the behavior. Thank you.
ir-ctl timeout is important, but if you use a NEC protocol remote presses quicker than 4 times a second (250ms) won't be recognized as distinct repeats - NEC protocol doesn't have a toggle bit like rc-5 or rc-6/MCE protocols. Use an rc-5 or rc-6/MCE remote if you want better response to quickly repeated button presses.
so long,
Hias
So is it possible to add a udev rule for the ir-keytable settings or does that have to go in autostart.sh ?
Both variants will work but I recommend creating a udev rule.
If you connect another device with an IR receiver, eg a DVB USB stick, autostart.sh may configure the wrong receiver (rc names can change across reboots). With a udev rule you can apply the settings to all receivers, or only meson-ir.
If meson-ir is your only IR receiver then it doesn't really matter, use what's easiest for you.
so long,
Hias
autostart.sh should work, but it' be better to create a udev rule for that. Copy /utsr/lib/udev/rules.d/70-input-repeat.rules to /storage/.config/udev.rules.d, and then add this line at the end (all in a single line, after the LABEL="end" line):
ACTION=="add|change", KERNEL=="lirc*[0-9]", DRIVERS=="meson-ir", RUN+="/usr/bin/ir-ctl -d $devnode -t 50000"
so long,
Hias
bubblegum57 , yes I know. I tested many configurations with repeats and adjusted it little bit . Now is better but still not this same like in older build. I will have to get used to it.
Another knob you can turn to improve remote response is the idle timeout. By default it's set to 200ms on Amlogic / meson-ir, which is quite long - other IR receiver drivers use 125ms.
This value determines how long it takes until Linux recognizes that you released a button. By lowering this value you'll get faster response to very short button presses and also the repeat delay will work more accurately (and you can set it to lower values, if you like).
As a rule of thumb 50-100ms should be safe, you can also try going down to 20-30ms. Low values can be problematic when the system is loaded and timeouts lower than 20ms will most certainly break IR reception completely. I'd start with 50ms and then test and adjust it to your liking.
You can change the timeout with ir-ctl -t , but note that the value is in microseconds. So, for 50ms you have to use a value of 50000:
ir-ctl -t 50000
so long,
Hias
The rc-map-name isn't that important, it defines which keymap the kernel should load (if you leave it out it'll default to rc-rc6-mce). As we'll usually override that via rc-maps.cfg in userspace you can just ignore that.
In the gpio controller block you setup a pin configuration to configure a pin as GPIO.
This GPIO configuration is then referenced in the gpio-ir-receiver block via the pinctrl property and activated when the ir-receiver module loads.
The gpios property in ir-reciever is also important as that will tell the gpio-ir-receiver which gpio to use. It has to match the GPIO referenced in the pinctrl handle.
so long,
Hias
Here's a script that should simplify that task: Install or remove addon from command line
so long,
Hias
Tinkerboard / Rockchip doesn't support device tree overlays like RPi. Also there's no config.txt on these devices.
You'll have to create your own .dtb file, eg by applying the needed changes to the dts/dtsi files in the kernel tree and then compiling your own LibreELEC image or by decompiling/modifying/compiling the existing dtb using the devicetree compiler.
Sorry, I can't help you there, as I don't have a Tinkerboard and am not really familiar with the RK3288 devices.
so long,
Hias