[SOLVED] Has something changed in lirc ? A lot of my remote has stopped working

When I first started using OSMC one of the things I loved about it is that my remote worked very well right out of the box. It continued doing so up until the last few updates. I started having to redo some of my key bindings, which was no big deal. Now it seems that will no longer work, as very few of the buttons on my remote are getting valid signals through to kodi. (I’m sorry, I don’t know the lingo. lirc confuses the hell out of me to be honest.)

So, who can offer some advice to a n00b on the easiest way to get my buttons working again?

It would be helpful if you told us what kind of remote you actually have. :wink:

Please also provide your lircd.conf. Nothing has changed in our lircd/eventlircd configuration in the last several updates with the exception of adding a few new lirc profiles. None of the existing ones have been altered.

Can you explain what you manually edited that you keep losing ?

I’m using: lircd.conf -> /etc/lirc/lircd-full.conf as far as I can tell. pasted here

I can’t recall which one of the remotes in there it was using, though. Something with “kbd” in the name?

The changes I was making were being made with the keymap editor addon. Changing a “Windows” button from taking me to PVR to something that is actually useful to me, and a few other minor changes.

My remote: Gyration GYR3101US Media Center Remote

Sep 14 02:54:16 osmc kernel: input: Gyration Gyration RF Technology Receiver as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:0C16:0002.0001/input/input0
Sep 14 02:54:16 osmc kernel: gyration 0003:0C16:0002.0001: input,hiddev0,hidraw1: USB HID v1.10 Keyboard [Gyration Gyration RF Technology Receiver] on usb-3f980000.usb-1.2/input0
Sep 14 02:54:16 osmc kernel: input: Gyration Gyration RF Technology Receiver as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:0C16:0002.0002/input/input1
Sep 14 02:54:16 osmc kernel: gyration 0003:0C16:0002.0002: input,hiddev0,hidraw2: USB HID v1.20 Mouse [Gyration Gyration RF Technology Receiver] on usb-3f980000.usb-1.2/input1

I tried running irw and pressing every key on my remote. It’s giving me no output at all.

lircd_helper@ service isn’t running. (Maybe because I don’t use an IR remote?

osmc@osmc:/lib/systemd/system$ sudo systemctl status eventlircd.service 
● eventlircd.service - eventlircd remote support
   Loaded: loaded (/lib/systemd/system/eventlircd.service; enabled)
   Active: active (running) since Sun 2015-09-13 10:42:46 EDT; 16h ago
  Process: 380 ExecStartPost=/bin/sh -c for f in /var/run/lirc/lircd-*.sh; do if [ -e $f ]; then s=$(basename $f .sh | sed 's/lircd-//g'); systemctl start lircd_helper@$s; fi; done (code=exited, status=0/SUCCESS)
  Process: 359 ExecStartPre=/bin/mkdir -p /var/run/lirc (code=exited, status=0/SUCCESS)
 Main PID: 378 (eventlircd)
   CGroup: /system.slice/eventlircd.service
           └─378 /usr/sbin/eventlircd --evmap=/etc/eventlircd.d --socket=/var/run/lirc/lircd --repeat-filter --release=_UP -f


Hi Katze,

Are you using a GPIO receiver? If so, can you double check ‘Enable LIRC GPIO remotes’ is enabled in My OSMC -> Pi Config.


No, it’s a USB dongle. (RF Remote) Nothing hooked up to my GPIO pins.

If it is an RF remote then you will likely not need LIRC for this, and it likely exposes itself as a keyboard.

Unplug the USB dongle

Plug it in after booting and run

dmesg | paste-log


I found an lircd.conf for my remote here. After making a symlink to it and selecting it in MyOSMC my remote seems to be working well again. For some reason I couldn’t browse directly to the file in my home folder. The only 2 options were my external USB drive and an addon repository that I added.

I did the dmesg | paste-log anyway. http://paste.osmc.io/apucemafap

It looks like it is a keyboard…

USB HID v1.10 Keyboard [Gyration Gyration RF Technology Receiver] on usb-3f980000.usb-1.2/input0

But if it’s working, then cool!


I find that I’m having to unplug and replug the usb receiver sometimes to get the remote to start working correctly after a reboot.

Here’s a log after having done that. http://paste.osmc.io/etodijedin

Sorry but there’s no way that’s possible, it can only be a coincidence.

If the device is detected as a USB keyboard then it does not go through the lircd daemon at all, so it won’t make any difference what lircd.conf you select.

Also, all the key namings in your lircd.conf are not valid, for example:

     Home                     0x0066 # AKA "Windows button"
     Up                       0x0067
     Left                     0x0069
     Right                    0x006A
     Down                     0x006C
     Mute                     0x0071
     VolDown                  0x0072
     VolUp                    0x0073

None of the names are valid Linux uinput key names such as KEY_UP, KEY_DOWN and so on, so even if lircd was processing input from your remote the key events would all get filtered out by the kernel.

The lircd.conf file above could be used if you used a GPIO based IR receiver instead of a USB one, but all the key namings would have to be updated to the correct key names before it would work.

As to why it seems intermittent - hard to say, possibly a power related issue with the dongle drawing too much power and your Pi’s power adaptor sagging a bit. There is no software configuration problem that would cause what you describe - a USB keyboard device just goes via the Kernel directly to Kodi without any other processing by other remote control related daemons.

On a Pi B+ or Pi 2 you could also try enabling max_usb_current=1 in config.txt.

osmc@osmc:~$ irw
8b 0 KEY_MENU linux-input-layer
8b 0 KEY_MENU_UP linux-input-layer
172 0 KEY_SUBTITLE linux-input-layer
172 0 KEY_SUBTITLE_UP linux-input-layer
166 0 KEY_INFO linux-input-layer
166 0 KEY_INFO_UP linux-input-layer
1 0 KEY_ESC linux-input-layer
1 0 KEY_ESC_UP linux-input-layer
cf 0 KEY_PLAY linux-input-layer
cf 0 KEY_PLAY_UP linux-input-layer
cf 0 KEY_PLAY linux-input-layer
cf 0 KEY_PLAY_UP linux-input-layer
197 0 KEY_NEXT linux-input-layer
197 0 KEY_NEXT_UP linux-input-layer
d0 0 KEY_FASTFORWARD linux-input-layer
d0 0 KEY_FASTFORWARD_UP linux-input-layer
77 0 KEY_PAUSE linux-input-layer
77 0 KEY_PAUSE_UP linux-input-layer
cf 0 KEY_PLAY linux-input-layer
cf 0 KEY_PLAY_UP linux-input-layer

If irw picks it up, doesn’t that mean it’s going through lirc?

Not necessarily. ‘irw’ with no command line options is the same as ‘irw /var/run/lirc/lircd’, which is reading the output from eventlircd.

Eventlircd is an input event aggregator that takes input from multiple sources including lircd but also other sources, and then sends them to Kodi over a lirc socket.

Generally USB devices will not go through lircd but they will usually go through eventlircd unless they are a standard keyboard or mouse. (In which case no extra translation is needed)

If you run the command 'irw /var/run/lirc/lircd-lirc0` it will show the output from lircd - if you don’t see anything from this command it means your remote does not go through lircd.

osmc@osmc:~/.kodi/userdata/playlists/video$ irw /var/run/lirc/lircd-lirc0
connect: No such file or directory

Well, however it works, the key names ie. KEY_PLAY, KEY STOP, KEY_OK etc have to be coming from somewhere. I’d always assumed they were coming from lircd.conf. Also, I’d like to know why my remote worked so much better out of the box with OSMC than with OpenELEC.

No such file or directory means the lirc socket has not been created due to lircd not being started due to it not being needed. (It is started on demand)

The device probably uses MCE keyboard scan codes which means it will “just work” without any configuration, although the button mappings may not necessary be ideal.

Not sure exactly why OSMC would be mapping your buttons better by default than OpenElec, I haven’t looked at how OpenElec configures lircd/eventlircd. Possibly its due to our decision to send linux-input-layer as the “remote name” to Kodi instead of “dev-input” which would normally be the default. (And probably is for OpenElec, if they even use eventlircd at all)

This causes Kodi to use a different section of the Lircmap.xml for button translation which IMHO provides better compatibility with the remote’s that were tested during the initial development of remote support in OSMC and probably in general.

Well, I’m glad you did. I love my OSMC. :heart:

Copied from another thread, this may also be relevant to your remote buttons not being mapped correctly:

I’ve discovered and fixed a bug that can cause issues with unwanted remote repeats.

The issue was that we were not guaranteeing that eventlircd was always started before Kodi, so depending on what else was going on during bootup, Kodi would sometimes start first. When this happens Kodi directly grabs the input devices, so they no longer pass through eventlircd’s repeat filter, thus unwanted repeats occur.

This has been fixed in the following commit and will be released in a future update:

For anyone that wants to test this fix early it is a very easy change to make. Simply edit the statup service for eventlircd:

sudo nano /lib/systemd/system/eventlircd.service

You will see a file that starts with the following lines:

Description = eventlircd remote support
After = remote-fs.target

Immediately after the After line add the following line:

Before = mediacenter.service

Then save the file and reboot. If this fixes your remote repeat problems please let us know. :smile:

1 Like