What type of receiver are you using and how is it connected ?
If you are using a GPIO IR receiver it will be going through lircd and the selected profile in Remotes will apply. If you are using a USB based receiver it will not be going through lircd and therefore the Remotes section will not do anything.
In the USB case it either goes directly to Kodi or via eventlircd to Kodi depending on whether any udev rules match the USB receiver.
[ 4.058850] dvb-usb: found a ‘Hauppauge WinTV-NOVA-T usb2’ in warm state.
[ 4.060126] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 4.063905] DVB: registering new adapter (Hauppauge WinTV-NOVA-T usb2)
[ 4.065723] dvb-usb: MAC address: 00:0d:fe:02:dc:3a
[ 4.072229] usb 1-1.2.4: DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)…
So which path will these events take and how to alter the mappings. From a user point of view and the GUI it doesn’t distinguish the very different paths and ways to config. One just sees the remote listed and kinda thinks this is the relevant config.
I understand the same remote might be used by hauppauge on various types of receivers, but are these all usb connected. Someone took the trouble to create a lrcd.conf for this remote so one assumes there is some hw somewhere that uses this remote and lrcd?
It would be so much easier if all such configs were done in the same place. Or is this just a legacy old hw issue?
Maybe would be easier to say this is old hw and not supported. But then this is opensource and thats probably impossible.
So where can i fix the mappings. I do hate having piles of old hw laying around where hw works, but the driver doesn’t…
That looks like a TV tuner to me not a remote receiver.
While we would like to make remote configuration as simple as possible, the simple truth is that behind the scenes remote configuration on Linux (and Kodi for that matter) is a very complicated twisty labyrinth with many layers of indirection/configuration and we can only do so much to simplify it, and only for the more “common” cases. There are many different input methods that use different drivers,software, multiple layers of key translations and mappings, it can get very confusing.
You can tell whether the remote is going through eventlircd or not a couple of ways, probably the easiest is to turn on debug mode in kodi, then tail the log with:
tail -f /home/osmc/.kodi/temp/kodi.log
Then press buttons on your remote. If the debug entries say anything about LIRC they are comming via eventlircd, if they just say they are keys, they are going directly into Kodi. (Usually the case for a device that presents itself as a keyboard for example)
If you use a GPIO IR receiver then the hauppague lircd profile will work just fine. A GPIO IR receiver using lircd can work as a receiver for nearly any remote, that is why there are so many profiles available for it. IMHO a GPIO IR receiver is what I recommend over a USB receiver on the Pi both because it is cheap and because it is so flexible.
USB receivers only tend to work with one remote and while there are ways to customise the button mappings to some degree using remote.xml in Kodi, you don’t have the complete freedom to map any button to any function that you do with a lircd profile.
I have the 950Q version, and it controls both the tuner, as well as Kodi. I also have the HVR-1850 pci-e card version, and that remote is completely compatible with the usb version.
But after all that… I just came across Kore… an Android app that turns your smartphone or tablet into a touchscreen remote, including the keypad. Browse your music and video libraries, and even browse the live tv’s EPG… all without affecting whatever’s on the tv screen. It’s pretty cool. I’m on the hunt for a cheap Android tablet now.