Remote "Double-Clicks" Following April 2019 Update

Have just applied the update from stretch-devel and did a short test.

I’m using Flirc 2 with a One For All URC-7962 remote. Had experienced repeated presses before. Now all seems fine.

Relevant lsusb output is:

Bus 001 Device 005: ID 20a0:0006 Clay Logic 

Noticed the following in the systemd journal though:

systemd-udevd[309]: failed to execute '/usr/bin/ir-keytable' '/usr/bin/ir-keytable --delay=500 --period=33 --device=/dev/input/event0': No such file or directory
systemd-udevd[195]: Process '/usr/bin/ir-keytable --delay=500 --period=33 --device=/dev/input/event0' failed with exit code 2.

I tried the same, I got Bluetooth connected and the keyboard works but the directional button and other remote control functions don’t seem to respond, I obviously did something wrong when I tried, any idea?

I still use flirc but want to remove flirc and just use harmony via bluetooth, that’s what you did right?

This is still being worked on.

Yes, you would want to delete /etc/udev/rules.d/70-input-repeat.rules because the final released fix will have this file in /lib/udev/rules.d/

By dev version do you mean you are on the osmc stretch-devel repo ? If so try updating again, I’ve pushed a further version of the eventlircd package (1.3.8) not long after you posted with further tweaks which I hope are final now.

As above if you have previously created the file in /etc/udev/rules.d/ you will need to delete it or it will override the one in the updated package.

You might want to update again as well as I’ve tweaked it a bit further since your post. Don’t worry about the ir-keytable errors in the log - they occur because it tries to adjust the delay and period setting of all libinput devices, and not all of them will accept such settings. (So they harmlessly ignore it, but an error is logged)

I think this is new behaviour with Kodi 18.

yes I meant stretch-devel.

I removed the file I created, updated to new stretch-devel update rebooted and I can confirm the issue is now fixed for me.

I suppose this is not a big deal now that the repeat speed issue is gone. It was very annoying before because instead of play and pause I used to get info screen while playing videos, that no longer happens now that the repeat speed is back to normal slower speed.

I’ve installed the latest update and still received the log messages failed to execute '/usr/bin/ir-keytable'. Tried the invocation from a root shell and noticed that ir-keytable was not installed. Corrected this via apt install ir-keytable, rebooted and got rid of the error messages. You might want to update your package dependencies.

The interesting stuff is that I have noticed an improvement even without a working ir-keytable invocation. Now I’ve checked again, and it seems even more reliable in avoiding repeated key presses.

Thank’s that’s what I was wondering about. As after I applied the dev update, it didn’t change that file.

There is already a package dependency for ir-keytable:

So if you somehow managed to install the eventlircd package without ir-keytable being installed there is a problem with your system. Can you post your APT logs using grab-logs -a so we can see what went wrong on your system ?

That’s because we’ve made three changes - one is to adjust the repeat delay and period using ir-keytable:

(Lircd gets a 700ms delay vs 500ms for other remotes)

The second is to disable the built in repeat filter in eventlircd which was previously handling repeat suppression for lircd remotes, but also causing many USB remotes to be unnecessarily slow:

The third change was to remove the synthesis of key up events in eventlircd, which was preventing suspend mode working on the vero4k: (as the second event synthesised when the button was released would wake it up again)

Only the first of these three changes relies on ir-keytable.

By the way, anyone wanting to override the specific delay and period we chose for lircd and other remotes in the future, you can copy the rules file to /etc/udev/rules.d/ and then edit it there - it will then always take priority over any versions provided by the package even after updates. (As the /etc version of system files always takes priority over the system supplied /lib versions)

I’m hoping that the values I’ve chosen work well for everyone though - it’s quite a balancing act trying to find values that suppress repeats correctly on troublesome remotes but don’t make other remotes unnecessarily slow. The most difficult to deal with are lircd remotes hence a little bit of extra delay was found necessary there. (Originally with eventlircd’s repeat filter it was effectively 1000ms!)

1 Like

Thinking about this a little further, I don’t suppose you used apt-get upgrade instead of apt-get dist-upgrade when you upgraded on stretch-devel ? If so, don’t do that… :wink:

If you use apt-get upgrade it will not install any new package dependencies whereas apt-get dist-upgrade will. It’s why we always tell people not to use plain apt-get upgrade. We rely a lot on new package dependencies in OSMC particularly with the way we install the kernel.

If you did in fact use dist-upgrade then please post your APT logs as per my previous post so we can see what happened. It’s important that everyone does automatically get ir-keytable installed during the update otherwise lircd remote users would start to get unwanted repeats as the update would remove eventlircd’s repeat filter but not implement the new ir-keytable repeat delay which is supposed to replace it…

We don’t allow that anymore with our wrapper.

I have installed using commands copied from your earlier post: sudo apt-get update && sudo apt-get dist-upgrade && reboot. I was also aware of the dist-upgrade vs. upgrade implications.

eventlircd-osmc is not installed on my system:

# dpkg-query -l event\*
dpkg-query: no packages found matching event*

Actually installed is armv7-eventlircd-osmc, but this has no dependency on eventlircd-osmc.

# apt-cache depends armv7-eventlircd-osmc
  Depends: armv7-lirc-osmc
  Depends: udev

Requested logs (grab-logs -a) available at

In case you wonder about /etc/apt/apt.conf.d/90-oliver-fixes, this is its content:

# Run post-upgrade fixes
DPkg::Post-Invoke { "/home/osmc/Fixes/run-post-dpkg-invoke"; };

Via the attached scripts, this hook tries to patch one Kodi file to prevent the TV recordings list from overlapping header and footer information. (The patch is currently ineffective as it needs to be updated for Leia).


Looks like you didn’t enable the devel repro (unless you switched already back to the non devel one when you ran grab-logs.

> =================== ZZz2wrJ1
> deb stretch main contrib non-free
> deb stretch-updates main contrib non-free
> deb stretch/updates main contrib non-free
> deb stretch main

I have switched back. See here:

====================== APT sources.list.d =================== KjLq37hD
total 12
drwxr-xr-x 2 root root 4096 May  5 01:10 .
drwxr-xr-x 6 root root 4096 Jan  1  1970 ..
-rw-r--r-- 1 root root   42 May  4 16:50 osmc-stretch-devel.list.disabled

---------------------- APT sources.list.d END --------------- KjLq37hD

Good catch on the missing dependency. I see what the problem is and will fix it when I get home. :slight_smile:

Excellent. I’ll wait for the update. I could then test this on my other RPi, which has a GPIO-connected IR receiver so I have both, a Flirc and non-Flirc scenario to test.

Should be fixed now, version 1.3.9 of the eventlircd packages:

Still only in stretch-devel at the moment for testing.

Have tested the latest update on both, Flirc and GPIO-IR RPi. (Made sure to manually uninstall ir-keytable first.)

Everything installed fine. Results of testing with One For All URC-7962 remote:

  • GPIO-IR response was fast and precise, noticed neither drop-outs nor repeated key presses,
  • Flirc response was fast, felt a little less precise than GPIO-IR, noticed rare drop-outs, no repeated key presses.

The method I’ve used for testing was playing a video, then using repeated key presses to obtain 1 min., 3 min. and 5 min. skip steps. Did several iterations on each RPi.

So from my point of view, all seems fine now. Same performance level as before.

For those who may wonder why I’m using Flirc at all given the positive GPIO-IR results: Before installing the Flirc on one of my RPis, a GPIO-IR was installed on that device. However, once or twice a day the IR function ceased to respond for about one minute or so. I could not resolve this (even switching the IR components did not improve the situation) until I installed Flirc.

Have tested with my Flirc and Pronto TSU9400 (custom IR codes) and can confirm delay=500 and repeat=50 works perfectly for me. Thanks!

I’ve got the latest dev version, and I’ve removed the manual file, can confirm that all working well for me now with my Harmony Elite connected as a Bluetooth Keyboard.