Logitech Harmony IR Remote repeating commands since May update (Update: Issue was wi-fi interference)

Thanks for the updated info. Yes, I do tend to take the brute force approach with the kill command. You are also correct on key mapping. This keymap was for a Harmony 650 and I had to make a couple of overrides for it but overall it’s been rock solid. There’s also the Kodi Keymap addon which works great for context specific and global changes.

Well, I gave it a try on my raspberry pi.

When I got to the point of:

/usr/bin/ir-keytable -p rc5,lirc --delay=500 -s rc0–period=125 -c -w /etc/rc_keymaps/rc6_mce
The result was:
Couldn’t find any node at /sys/class/rc/rc*.

Poking around a bit, I ended up needing to put the location:
/usr/bin/ir-keytable -p rc5,lirc -d /dev/lirc0 --delay=500 --period=125 -c -w /etc/rc_keymaps/rc6_mce

This result was:
Unable to query evdev protocol version: Inappropriate ioctl for device

Apparently you need version 1.14 of ir-keytable to fix this one. Stretch, the current osmc version, has 1.12. Buster has 1.16.

It’s working OK here on a Vero which also uses Stretch.

I don’t have experience with pi devices, so I can’t say exactly what the issue is, but there are a few things that look odd about those two commands that you may want to rectify, just to ensure they’re not causing trouble:

  • You’ll want to change the -p rc5,lirc to -p rc6,lirc (or just -p rc6) if you’re using an rc6 keymap like rc6_mce.
  • It looks like you got a couple of parameters blended with -s rc0–period=125 in that first command, which I’m guessing was supposed to be -s rc0 and --period=125 as separate parameters? If so, you might want to try adding the -s rc0 to the second command, to see if it was just the failure to select the rc0 device that was causing the ioctl error.

Also, super dumb question, but did you verify that the /etc/rc_keymaps/rc6_mce file exists and is non-empty? I’ve definitely battled with commands in the past only to find that a file that I expected to be present by default was conspicuously missing.

The cut and paste on this Android ssh client leaves a lot to be desired… I believe the commands were entered correctly but I will verify.

Anyway, I upgraded the box to buster and tried a few basic things like playing media and all seems to be functioning properly. As it is getting late I will try the ir-keytable stuff tomorrow.

The commands input were correct. Any irregularities were due to the cut and paste.

I have updated the kernel to 4.19 and changed the dti_overlay to gpio_ir and the remote functions correctly. If I understand correctly I am now using the kernel ir stuff. Ir-keytable now functions correctly. This is likely due to the kernel upgrade, not the buster upgrade.

Mode2 still shows noise however when connected to 5ghz. I suspect the key repeats will continue.

What did you change in config.txt? You may still be using LIRC

Here’s my config.txt

gpu_mem_1024=256
hdmi_ignore_cec_init=1
disable_overscan=1
start_x=1
disable_splash=1
gpu_mem_256=112
sdtv_aspect=1
dtoverlay=gpio-ir
dtparam=gpio_in_pin=18
gpu_mem_512=144
dtparam=gpio_out_pin=17
config.txt (END)

My remote didn’t work until I changed dtoverlay. Yes, I’m still getting repeats.

Did you know buster ships with over 100 different remotes pre-configured?

What do you mean by this?
Not sure why you have repeats – your TSOP may be sensitive.

Here’s the pre-configured rc6 remote:

root@osmc133:/lib/udev/rc_keymaps# cat rc-rc6-mce

table rc-rc6-mce, type: RC6

0x800f041e KEY_UP
0x800f041f KEY_DOWN
0x800f040d KEY_MENU
0x800f0422 KEY_OK
0x800f0423 KEY_ESC
0x800f0420 KEY_LEFT
0x800f0421 KEY_RIGHT
0x800f045b KEY_RED
0x800f045c KEY_GREEN
0x800f045d KEY_YELLOW
0x800f045e KEY_BLUE
0x800f0400 KEY_0
0x800f0401 KEY_1
0x800f0402 KEY_2
0x800f0403 KEY_3
0x800f0404 KEY_4
0x800f0405 KEY_5
0x800f0406 KEY_6
0x800f0407 KEY_7
0x800f0408 KEY_8
0x800f0409 KEY_9
0x800f040f KEY_INFO
0x800f0416 KEY_PLAY
0x800f0418 KEY_PAUSE
0x800f0419 KEY_STOP
0x800f0417 KEY_RECORD
0x800f0414 KEY_FASTFORWARD # FASTFWD
0x800f0415 KEY_REWIND # FASTREW
0x800f041a KEY_NEXT
0x800f041b KEY_BACK # PREV
0x800f040c KEY_POWER2 # POWER
0x800f0412 KEY_CHANNELUP # CHANNEL+
0x800f0413 KEY_CHANNELDOWN # CHANNEL-
0x800f0410 KEY_VOLUMEUP # VOLUME+
0x800f0411 KEY_VOLUMEDOWN # VOLUME-
0x800f040e KEY_MUTE
0x800f0425 KEY_SUBTITLE # SUBTITLES (LiveTV)
0x800f0426 KEY_EPG # SCHEDULE (EPG)
0x800f0424 KEY_CHANNEL # CHANNELS (DVD Menu)
0x800f041c KEY_FAVORITES # COMMANDS (#)
0x800f041d KEY_MODE # AUDIO (*)
0x800f0448 KEY_PVR # RECORDINGS (RecordedTV)
0x800f044a KEY_VIDEO # Videos
0x800f0449 KEY_IMAGES # Pictures
0x800f0447 KEY_AUDIO # Music
0x800f0450 KEY_FN # RADIO
0x800f045a KEY_TEXT # USER0 (Videotext)
0x800f040a KEY_PROG1 # USER1 (Delete)
0x800f040b KEY_PROG2 # USER2 (Enter)

table hp_mediasmart, type: RC6

0x80115258 KEY_UP
0x80115259 KEY_DOWN
0x801152a1 KEY_MENU
0x8011525c KEY_OK
0x80115255 KEY_ESC
0x8011525a KEY_LEFT
0x8011525b KEY_RIGHT
0x801152e4 KEY_RED
0x801152e5 KEY_GREEN
0x801152e6 KEY_YELLOW
0x801152e7 KEY_BLUE
0x80115200 KEY_0
0x80115201 KEY_1
0x80115202 KEY_2
0x80115203 KEY_3
0x80115204 KEY_4
0x80115205 KEY_5
0x80115206 KEY_6
0x80115207 KEY_7
0x80115208 KEY_8
0x80115209 KEY_9
0x80115281 KEY_INFO
0x8011522c KEY_PLAY
0x80115230 KEY_PAUSE
0x80115231 KEY_STOP
0x80115237 KEY_RECORD
0x80115228 KEY_FASTFORWARD # FASTFWD
0x80115229 KEY_REWIND # FASTREW
0x80115220 KEY_NEXT
0x80115221 KEY_BACK # PREV
0x8011520c KEY_POWER2 # POWER
0x8011521e KEY_CHANNELUP # CHANNEL+
0x8011521f KEY_CHANNELDOWN # CHANNEL-
0x8011520a KEY_PREVIOUS # PREVCHANNEL (Last)
0x80111210 KEY_VOLUMEUP # VOLUME+
0x80111211 KEY_VOLUMEDOWN # VOLUME-
0x8011120d KEY_MUTE
0x80115292 KEY_SUBTITLE # SUBTITLES (LiveTV)
0x801152cc KEY_EPG # SCHEDULE (Guide)
0x8011520b KEY_CHANNEL # CHANNELS (Media)
0x801152ab KEY_FAVORITES # COMMANDS (Favorites)
0x8011528b KEY_MODE # AUDIO (Source)
0x80115293 KEY_TIME # TIMERS (Search)
0x801152a0 KEY_PVR # RECORDINGS (RecordedTV)
0x80115254 KEY_SETUP # (Menu/Settings)
0x801152d5 KEY_TEXT # USER0 (Menu/Target)
0x80115256 KEY_PROG1 # USER1 (Clear)
0x801152e1 KEY_PROG2 # USER2 (Enter)
0x801152ac KEY_PROG3 # USER3 (*)
0x801152a2 KEY_PROG4 # USER4 (#)
root@osmc133:/lib/udev/rc_keymaps#

There are over 100 others in that directory.

That’s good to know. We still need a front-end to manage the selection however.

@dbmandrake and I have discussed it and we have some good ideas on how to move over to ir-keytable, but it won’t be for a while.

Looks to me like it comes free with buster. 1 line change to config.txt and its plug and play.

I don’t think it’s acceptable to go from providing a GUI to configure remotes to requiring users to edit a text file manually.

Further: config.txt doesn’t exist on some devices, such as the Vero. So this isn’t an appropriate configuration mechanism.

There isn’t a lot of demand for ir-keytable at the moment. So while it’s something that will be done, it is a while off.

That’s very odd. When I switched over to the ir-keytable commands, they went through correctly even with an insane amount of interference (testing with my router sitting on a shelf three inches below the Vero). Have you confirmed that lirc is fully disabled when you’re running the test? It makes me wonder if lirc is somehow still getting looped in.

Indeed. Lircd can run simulataneously with the kernel decoders and this will result in repeats even if there is no interference as each button press is being decoded by two different mechanisms (lircd daemon, and kernel driver) and then merged by eventlircd.

So make sure that my osmc remotes is set to a remote you don’t have, as a way to ensure that it is not still trying to decode the remote as well.

It’s possible to disable lircd entirely from the command line but it’s easier just to set it to a profile of a remote you don’t have, certainly as a quick test.

The problem with the bundled rc_keymaps is they are probably not written with Kodi in mind, nor with our use of the “linux-input-layer” mapping in Lircmap.xml in Kodi, while most other Kodi distro’s use the “dev-input” mapping, or don’t use a lirc socket at all, both of which result in different key mappings for some buttons.

As a result certain buttons like the OK button may not work using those bundled rc_keymaps. Unfortunately I don’t have any of the remotes supported by those bundled profiles to test with but if you do please do so and check that all the buttons are appropriately mapped and working. This would be useful to know.

Even if they aren’t quite mapped properly, if there are only a few consistent mapping problems like the OK button we could create a sed script to automatically parse the bundled rc_keymaps and modify them slightly to work well in OSMC/Kodi, and save those modified versions in a local directory. That way when that bundled library of rc_keymaps is updated in future we can reprocess them automatically perhaps using something like an apt trigger.

1 Like

Part of the reason I used the kill command with pgrep was to ensure lirc wasn’t somehow running when I didn’t want it to. Again a bit of brute force but effective.

LIRC is a service, so you would need to stop lircd_helper.

I’m using the buster rc6 config file(as above) and have noticed no issues.

sudo /usr/bin/ir-keytable -p rc6,lirc --delay=500 --period=125 -c -w /lib/udev/rc_keymaps/rc-rc6-mce

Yes indeed, it looks like some of the lirc stuff was still active. It has been disabled and I’ll advise as to the status of the repeats.

BTW, in poking around in this stuff, it looks like Linus himself did the kernel and key map work…