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.
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 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.
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"
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:~/.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.
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.