Can anyone else reproduce this? It seems a very significant result, but surprising, so more confirmation would be good.
I'm confused. The current Rasbian 'official' Jesse image uses a 4.4 kernel. not 4.9.24. (Download Raspbian for Raspberry Pi)
I'm guessing this is a more recent kernel downloaded using rpi-update. I'm giving this a go to see what happens.
OK - I've compiled the most recent version of 4.8.y from GitHub - raspberrypi/linux: Kernel source tree for Raspberry Pi Foundation-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://www.raspberrypi.org/forum (4.8.16).
Can't seem to reproduce the problem and I now have a more up-to-date kernel :-).
The problem is when I try and find the 1st version of 4.9.y with the problem I can't get any earlier than 4.9.10 as it doesn't have the necessary rpi specific patches (arch/arm/configs/bcm2709_defconfig) to compile.
I'm trying a compile starting at 28cad4892910 (the earliest point in the rpi-4.9.y branch with this file) to see what happens, but it doesn't seem that much earlier than the 4.9.10-v7+ build I first tried which I already know has the issue.
I did wonder about applying rpi patches to base 4.9 (69973b830859bc6529a) or maybe an earlier version, but that's beyond my git skills at present :-(.
More than happy to add another remote to my git repo and give it a go if someone can publish a link...
I just found this thread googling very similar symptoms I've been seeing since attempting to upgrade from a 4.6.0 based kernel to 4.9 based kernels in march this year on my RPI2 which runs gentoo as a mythtv backend (i.e. the reported artifacts in video recordings).
I use a Geniatech T230 DVB-T2 TV Stick for recordings, two USB hard disks for the data and a USB stick for the mysql database/swap. The root partition is on an 8gb sd card.
I am similarly convinced the problem lies in the kernel's USB subsystem. Not only do I see video artifacts in mythtv recordings, but sporadic corruption of the mythtv mysql database (hosted on USB key). Since switching back to the 4.6 kernel a couple of months ago all my problems magically vanished - video artifacts in recordings was the most visible symptom and the way I confirmed I'd found the culprit.
I'm also a libreelec user (on my RPI-B / B+ boxes) which mount 'storage' via nfs (over ethernet) to one of the USB hard disks hosted on the PI2. When I first set this up regular upgrades of my test system always worked, but recently I see MD5 errors when libreelec unpacks the tar file on upgrade (less often now I have the RPI2 reverted to 4.6). If I use a decompressed .img file rather than a .tar which seems to stress the network less it works 1st time.
I understand ethernet on the PI is also via USB, which is yet another finger pointing at the kernel's 'USB stack' for me.
I've convinced myself it's a kernel thing rather than a bcm firmware thing as using exactly the same 2016 firmware switching from 4.6.0-rc5-v7+ to 4.9.10-v7+ kernel (both compiled myself using bcm2709_defconfig) the problem is either there or not.
Given that x86 / x86_64 users with usb sticks are reporting similar things on this thread, my next step will be to try compiling the very latest 4.8 based RPi kernel to see if I get the problem or not (I'm using an rpi github kernel).
This is my production system, compiling kernels on the RPi2 takes a while and I also have a rather busy day job, but I will report back what I find; assuming I manage to localize the 4.8 to 4.9 change which introduced this before someone else here does...
I've investigated a bit further with one of the current LibreElec Millhouse 18.0 builds. (#0422)
It seems that Kodi occationally duplicates the previous keypress, i.e. pressing left, down, left results in left, down, downleft.
(the audio 'click' which kodi plays confirms that it is actioning two keypresses then two more in quick succession even though I've only pressed a key on the remote three times)
Running irw in one screen, tail -f kodi.log | grep KEY in another and tail -f kodi.log | grep action in a third,
I can see held keypresses detected by irw (3 of), one 'KEY' event per selection on the remote (3 of), but four 'actions'.
This smacks of a kodi bug rather than a libreElec issue, so I thought I'd try to work arround the problem uisng 'advancedsettings'
I added the following to my advancedsettings.xml file
<advancedsettings>
<remotedelay>10</remotedelay>
<remoterepeat>800</remoterepeat>
</advancedsettings>
And it seems to have worked arround the problem, both on the millhouse build and LibreElec 8.0.1
Since upgrading my RPi to 8.0.0 from 7.95.3, I get occasional (1/10) double or tripple keypresses.
I'm using lirc-rpi and a home-wired IR receiver chip.
Alternating between left and down keys I see the following for example:
irw:
6c 0 KEY_DOWN devinput
69 0 KEY_LEFT devinput
6c 0 KEY_DOWN devinput
69 0 KEY_LEFT devinput
6c 0 KEY_DOWN devinput
69 0 KEY_LEFT devinput
69 1 KEY_LEFT devinput
69 2 KEY_LEFT devinput
6c 0 KEY_DOWN devinput
tail -f kodi.log | grep i- Key:
14:35:22.123 T:1961427712 DEBUG: LIRC: Update - NEW at 1185302:6c 0 KEY_DOWN devinput (KEY_DOWN)
14:35:22.124 T:1961427712 DEBUG: OnKey: 167 (0xa7, obc88) pressed, action is Down
14:35:22.705 T:1961427712 DEBUG: LIRC: Update - NEW at 1185884:69 0 KEY_LEFT devinput (KEY_LEFT)
14:35:22.706 T:1961427712 DEBUG: OnKey: 169 (0xa9, obc86) pressed, action is Left
14:35:23.338 T:1961427712 DEBUG: LIRC: Update - NEW at 1186516:6c 0 KEY_DOWN devinput (KEY_DOWN)
14:35:23.338 T:1961427712 DEBUG: OnKey: 167 (0xa7, obc88) pressed, action is Down
14:35:23.877 T:1961427712 DEBUG: LIRC: Update - NEW at 1187055:69 0 KEY_LEFT devinput (KEY_LEFT)
14:35:23.877 T:1961427712 DEBUG: OnKey: 169 (0xa9, obc86) pressed, action is Left
14:35:24.457 T:1961427712 DEBUG: OnKey: 169 (0xa9, obc86) pressed, action is Left
14:35:24.522 T:1961427712 DEBUG: LIRC: Update - NEW at 1187701:6c 0 KEY_DOWN devinput (KEY_DOWN)
14:35:24.522 T:1961427712 DEBUG: OnKey: 167 (0xa7, obc88) pressed, action is Down
It seems that sometimes (not always) I'm hitting a key-repeat event.
The odd thing is that I don't see the key repeat until I press the next key in the sequence (i.e. I got a left repeat immediately after pressing down in the example above).
If I press and hold a key, it starts repeating as I would expect it to.
I haven't touched my Lirc.conf file, but I do note that the 8.0.0 changelog says a 'fix' for key repeats was included in 8.0.0.
Is this likely to be a 'bug' in 8.0.0, or something wrong with my config which 8.0.0 is now exposing.
Anyone got an idea what I should do to stop these random key repeat events with 8.0.0? (Other than reverting to 7.95.3 
[hr]
OK I've partially answered my own question with some digging.
When I revert to 7.95.3 irw doesn't show any key repeats until I press and hold - which is what I want.
The offending changes are:
v4l-utils: add 70-input-repeat.rules · LibreELEC/LibreELEC.tv@194f304 · GitHub (udev 1000ms > 500ms key repeat)
kodi: process all lirc repeat events · LibreELEC/LibreELEC.tv@ae5a167 · GitHub (kodi now actions all key repeats)
The main problem seems to be the change of default key repeat delay from 1000ms to 500ms in udev
I guess my Sky IR remote (configured as RAW codes) is that little bit more sensitive.
Now, assuming that some people need a 500ms repeat rate (Kwiboo for example) and I need a longer one to work with my remote...
Maybe this should be added to the LibreElec settings addon in some way?
[hr]
I'm not convinced that the gpio_ir_recv device is honouring the ir-keytable --delay commands. Setting this to 5000ms (5 sec) via the command line I still start getting rapid key repeats after about a second...
There's also this from running dmesg:
[ 16.743612] rc_core: loading out-of-tree module taints kernel.
[ 16.744874] WARNING: You are using an experimental version of the media stack.
[ 16.744874] As the driver is backported to an older kernel, it doesn't offer
[ 16.744874] enough quality for its usage in production.
[ 16.744874] Use it with care.
[ 16.744874] Latest git patches (needed if you report a bug to [email protected]
[ 16.744874] a02ff2e02bee64e9955dbfd8811874c3f3880f58 cx231xx: Fix TBS MAC reading.
[ 17.028884] Registered IR keymap rc-rc6-mce
[ 17.029645] input: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0/input0
[ 17.031957] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[ 17.218055] gpiomem-bcm2835 20200000.gpiomem: Initialised: Registers at 0x20200000
[ 17.321113] lirc_dev: IR Remote Control driver registered, major 243
[ 17.391295] rc rc0: lirc_dev: driver ir-lirc-codec (gpio-rc-recv) registered at minor = 0
[ 17.391309] IR LIRC bridge handler initialized
[ 19.842960] 8021q: 802.1Q VLAN Support v1.8
[ 20.173087] IR NEC protocol handler initialized
[ 20.268798] IR RC6 protocol handler initialized
[ 21.334897] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 22.640208] input: lircd-uinput as /devices/virtual/input/input2
[ 22.743397] input: eventlircd as /devices/virtual/input/input3
Not quite ready for LibreElec 'stable' ?
