Tried running irw, but says no such file or directory. /usr/var/run/lircd folder is empty.
I am using an USB IR receiver. I have both Vero4k and RPI’s and neither work.
Could this be your issue?
No. I use custom lircd.conf files and they are all there and intact.
After my cup of coffee, I read the statement again. Yes, putting all of the conf files into one (lircd.conf) instead of include statements now allows the receiver to work. Now my problem is that any key press repeats for a long time (not forever, though). I seem to remember that that was a problem in the past. More digging…
There are some subtle syntax differences between the old and newer version of lirc which means some profiles may not work without slight tweaking. It looks like include is one example.
Silly question, but did you reboot after combining your .conf files ?
We rely on eventlircd for repeat filtering however its sometimes possible to get into a situation when fiddling around where eventlircd is not actually running and the uinput events sent from lircd go directly to Kodi and therefore don’t have repeat filtering.
The best way to check is to reboot and see if you still have an issue with excess repeats.
If that doesn’t help what do you see when you press buttons while running
irw /var/run/lirc/lircd
?
/var/run/lirc/lircd-lirc0 is the output directly from lircd (before repeat filtering) and /var/run/lirc/lircd is the output from eventlircd which is filtered and this is what Kodi normally uses.
1 Like
Yes, I rebooted. I don’t think that it would have reread the lircd.conf file without doing so. When I run irw, I get this:
67 0 KEY_UP linux-input-layer
67 1 KEY_UP linux-input-layer
67 2 KEY_UP linux-input-layer
…
It repeated until it reached a4 on the count. Sometimes only a3. Interestingly, it ignores the next key press after letting it repeat until it stops. The second key press then auto-repeats.
Using lircd-lirc0, it doesn’t show repeats. It still ignores the first key press after the repeating stops.
What key are you testing with ? Up ?
On lircd-lirc0 you should see KEY_something when you press and hold and then KEY_something_UP when you release ?
Yes, the up arrow. Here is what lircd-lirc0 reports:
0000000000000013 00 KEY_UP DIRECTV2-RC66
Sorry, incomplete answer…
I don’t see any new line when I release. When I press and hold, I see the line above and that is it.
I am not sure if I should be trying some of the “fixes” that I see posted for older kernels?
I can’t get irexec to work either.
I’ve just done some testing and it seems that LIRC is now treating all include paths as relative (to /etc/lirc), so for me changing from statments like include "/home/osmc/lircd/RC1800.conf"
to include "../../home/osmc/lircd/RC1800.conf"
fixes my remotes.
I’ve had issues with repeats like that a few times but never really looked into it as I assumed it was some kind of light interference… partially covering the IR sensor with blue tack has always fixed it. Maybe it’s time to remove the blue tack from the bedroom tv and find a proper fix. 
That’s a curious “feature”, but adding the …/… made the includes work.
So, a little more on the repeats:
It seems like the built-in IR receiver (on the vero 4k) is enabled. If I cover up the USB receiver, the built-in one works without repeat. If I cover up the built-in the USB one still repeats. This sounds vaguely familiar, but I can’t find the old case. Maybe it was different.
irexec still doesn’t work. I didn’t think that it was related to the receiver.
OK, a little more (a correction of sorts). Now that I realize that there were two receivers enabled, I covered up the built-in receiver. Now, when I run irw /var/run/lirc/lircd-lirc0, I get NO response from the USB receiver key presses. So the USB path is not going through lircd-lirc0?
By the way, even when using the built-in receiver, I don’t get the KEY_something_UP when I release after a long key press. I only get one line of output.
I found the earlier problem. It was with build 2018.12-1. With that build, the problem was the reverse. That is, the built-in receiver would go into auto-repeat, but the USB receiver would work OK. I switched everything over to USB at that time to deal with it. Now, it seems like the problem is reversed.
Should I start another thread for the irexec issue? I don’t think that it is related to the IR receiver issue.
I added the relative path to the lircd.conf file on the RPI3 and that works OK without repeats with the same USB IR receiver. irexec does not work on the RPI3 either.
OSMC supports multiple remotes and multiple receivers being active at once, whether lirc based, USB etc, and the event streams of each receiver are mixed together by eventlircd before being sent to Kodi. So if you have two different receivers that are both configured to receive the exact same remote you will get repeats, and you may actually get stuck down repeats as well.
So don’t do that. 
Only one receiver should be configured for any given remote.
That is correct - USB connected remotes do not go through lircd therefore you will not see output from them at /var/run/lirc/lircd-lirc0. Only remotes being received and decoded by lircd will show output at this socket.
A USB remote may show output at /var/run/lirc/lircd which is the output of eventlircd. This will happen if eventlircd has been configured to handle this type of USB receiver. (This is done in udev rules)
If there are no udev rules that match the USB receiver then Kodi will directly receive the uinput events from the device and bypass eventlircd altogether, in this case you won’t see any output at /var/run/lirc/lircd. One such example would be a regular keyboard.
Just to be clear, the repeats are all coming from the USB receiver. This happens even when the built-in is blocked.
Can you give me an example of how to deal with this in udev rules? I wouldn’t know how to do this myself.