OSMC and irrecord

Next issue, long time ago i did this successfully.

I own a Samsung TV and a remote that can handle Samsung TV and Samsung BDm now i wanna record the bd for the raspberry pi.

Pin for the Ir sensor should be set.

What i tried:

osmc@osmc:/etc/lirc$ osmc@osmc:~$ cd /etc/lirc
osmc@osmc:/etc/lirc$ systemctl stop mediacenter
osmc@osmc:/etc/lirc$ systemctl stop eventlircd
osmc@osmc:/etc/lirc$ systemctl stop system-lircd_helper.slice
osmc@osmc:/etc/lirc$ irrecord -f -d /dev/lirc0 samsung2.conf
Using raw access on device /dev/lirc0
Could not open new config file samsung2.conf
Could not init hardware (lircd running ? → close it, check permissions)
osmc@osmc:/etc/lirc$

Any ideas ?

Try run as root and stop LIRC first

Ok that worked, but at the point where i named the first key, i got this:

Now hold down button “KEY_1”.
Segmentation fault

BEFORE i had any chance to press a button on the remote…strange, did this many times, but never had an error like that

Tried different remotes, same problem.

Update, did a reboot, tried stop lirc, what worked before, and again…not working

Maybe try rebooting and then just…

systemctl stop eventlircd
irrecord -d /dev/lirc0 --driver default

while you are sitting in your home folder. If that works you can rename and move the conf after the fact. There is no need to stop mediacenter.

Now we are going to nice holidays in italy, when i have wifi, i gonna try it there, else when we r back.
My old bookmarks of the howtos, that i used before are not working anymore.
Right now i set it up to samsung standard remote.

I’m in a similar situation and would like to record some IR keys using irrecord. I’ve tried different remotes, e.g. an old one from a Philips TV set or a newer Sony BDP remote. irrecord did create an lircd.conf file, but none of its entries worked (or are visible to irw).

My final goal (on the long run) is to replace my current Harmony based remote control system by Sofabaton U3 (I prefer that over X2 because I dislike touch control). And for some automatism I need to SEND some IR commands from my raspberry pi 4 being recorded by irrecord. Sending IR should work using irsend from the lirc environment. Thus I try to get irrecord running …. I guess it’s “only” a software issue, thus any hints are welcome.

I did also try the ir-keytable kernel environment. Here I’d create a toml file using e.g. “ir-keytable -p sony -t” to get scancodes. But it fails completely e.g. for my old Philips remote - no matching protocol.

[Maybe a better/faster solution to my problem is to go with a flirc dongle, being able to send IR.]

Was anybody successful in using irrecord within OSMC?

I remember exactly zero of the details at this point but I have in the past did get some tests to work just trying a few keys to make sure it was working before posting whatever I posted about it on this forum. Don’t remember what thread I posted what but I’m sure it could be sussed out with the forum search. I do remember the process was a pain in the backside. Personally I use Harmony remotes and FLIRC USB dongles on all the TV’s in my house which runs a mix of RPi 4’s and Vero’s. They are a bit more responsive than the IR built into the Vero’s and with a FLIRC attached to a USB extension cord you can put the receiver where it works without having to point the remote in particular direction. Been using them for years and been quite pleased with them.

Although it does technically have this ability, practically speaking, this isn’t really something that is usable for a number of reasons. First the transmitter is low powered and would need to be pretty much pointing at the equipment your trying to send signals to. This is a bit of an issue as this is probably the opposite of where you want it facing to pick up the remote control signals. There is no jack to plug in a stick on external transmitter LED. In addition to that it is limited to one specific frequency so it only works with equipment that happens to operate at that same frequency. On top of that there is no GUI support for implementing it so one would have to go through a complicated process of debug logs to pull hex codes and then scripting up things on a terminal to get it to send commands.

Thanks for your detailed answer. Thus flirc seems not to be a solution for SENDING IR commands.

I have seen some of your articles within this forum, and I’ve used your hints - sadly without much success:

Currently I CAN record with irrecord, but the results are more or less useless. I’ve tried to learn the same button multiple times for different KEY_?? expecting to get the same codes. But they are all different.

Using different drivers also didn’t help:

irrecord -H default -d /dev/lirc0: all keys get code 0x00

irrecord -H devinput -d /dev/lirc0: keys can be learned, but apparent random code values

irrecord -d /dev/lirc0 RC-5.lircd.conf: using pre-crafted generic Philips conf from lircd database - again random code values
Enforcing raw mode by option -f fails with segmentation fault.

Contrary mode2: -H default works fine, while -H devinput fails after some pulses.

Luckily my Harmony remote environment works fine, thus I’ve some time to search for a solution.

Any further hints of course are welcome.

Have you tried the Philips remote profile in the My OSMC addon to see if that one works with your Philips remote? If that at least partially works you could just make a copy from /etc/lirc/ into your home folder and manually tweak with a text editor from there. If your missing codes you could try grabbing conf files from…

and just select the one you want to try in my My OSMC. These large electronic companies generally reuse most of the same IR signals so a bit of trial and error I would think would get you to the same place.

Thanks for that hint - but I’ve tried that without success.

BUT - I was successful in locating working lircd.conf files for 3 of my remotes within the big lircd.conf https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes including my philips remote! The working one is philips/26PFL5604H.lircd.conf. And I can control my Epson beamer using epson/12807990.lircd.conf. And my Sony BDP with sony/RMT-VB201U.lircd.conf

Finally I even have now an idea howto “save” the crucial IR commands (discrete on/off, discrete input selection) of my Hisense TV set from Logitech harmony. As expected I could not find any lircd.conf for Hisense, but since Hisense uses the nec protocol I can capture them by “ir-keytable -p nec -t” for use within a toml file.

Concluding, I did NOT succeed in capturing IR codes with irrecord. But I’ve a solution to get all IR keys as needed for my planned Harmony migration.

There is one final (related) question. What are the supported keynames within osmc’s lircd? “irrecord -l” reports 603 different keys, but many of them are invisible to irw, e.g. BTN_TRIGGER_HAPPY4 or KEY_MACRO29. From lirc documentation the set of keys is defined within /usr/include/linux/input.h
resp. input-event-codes.h Both files are missing within osmc (clear, it does intentionally not install the kernel build environment). Those “missing” buttons are included within corresponding files from my tumbleweed linux. Can you please provide those files from osmc (I want to avoid to install a full Debian kernel development environment on my raspberry pi 4)?

Thanks a lot, Michael

Probabely not my last question within that context:

To send IR codes one can use irsend or ir-ctl. The latter one is missing within current osmc. Is it OK if I install the debian package v4l-utils? Of course my ”experiments” should not disturb osmc/kodi files. The advantage of ir-ctl should be that it can send scancodes directly.

You have already driven farther down into this system than I ever had but I may be able to give a little clarity. The input-event-codes.h file your looking for can be pulled from Linux source as that is what OSMC is using. The restriction you found is not there though as that is coming from filtering from eventlircd. OSMC doesn’t customize eventlircd so the list of passed keys is all in their source code, which is on github, but isn’t (AFAICT) listed out anywhere in a clean list. From what I understand is in its unmodified form it limits to mostly standard keyboard keys. If you were looking to get all the way into Kodi it passes from eventlircd to /usr/share/kodi/system/Lircmap.xml where it gets processed using the “linux-input-layer” mappings, which it then passes on to keymaps as a keyboard type device.

Since your seeming to not actually be trying to do this but rather just get some work done on the terminal you should be able to just temporarily stop the eventlircd service so your buttons pass as you expect. Along these same lines you are playing with ir-keytable which is, absent some special configurations, incompatible being used alongside lirc. If you wanted to go down that path for this project you would probably have an easier time just sticking Raspberry Pi OS on an SD card and using that as it already uses ir-keytable.

In regards to installing v4l-utils I’m not aware of any known issues having it installed but ir-ctl is likely not going to work while eventlircd is running.

With your hint I made further progress: Now I can map arbritrary scancodes from different(!) remotes to arbritrary keypresses including e.g. BTN_TRIGGER_HAPPY40 Thus eventlircd is the “bad boy” eating some keynames. Sadly eventlircd eats up ANY key mapping done with ir-keytable, e.g. even KEY_1 is not seen.

I’ll dig deeper …

1 Like

In the meanwhile I can see scancodes from all my remotes and can decode them using toml files into keypresses, as long as eventlircd is NOT running. [I had a minor issue - I couldn’t load rc6 protocol kernel driver - because I had disabled rc6 within kodi’s GUI, thus now re-enabled.] When starting eventlircd all kernel keytables become invisible - now irw has taken over.

As far as I know, eventlircd collects different /dev/input/events* into one /var/run/lirc/lircd socket. And that’s a functionality I’m probabely using, too, because sometimes I use a wireless keboard to input more complex data into kodi.

Do you have any idea, howto unify eventlircd with ir-keytable? I’ve seen another topic here to load ir-keytables just before starting the lircd helper service from within eventlircd.service. I did not try that, should I?

My understanding is keyboards are excluded from running through lircd so their input just gets directly interpreted by Kodi. I don’t think there is any proper way to run lircd and ir-keytable alongside each other, and I don’t know that it would make any sense to even try to do so. Lircd is the older userland way to translate these types of signals, and ir-keytable is a newer kernel implementation to provide this functionality.

You are right, my keyboard is directly communicating with kodi (no ir).

But I did find a solution inspired by another thread here - instead of starting eventlircd by systemctl (with the additional sideeffect of starting lircd) I start eventlircd manually after setting up ir-keytable:

First I stopped all lirc processes by “systemctl stop eventlircd“. Next I

ir-keytable -c -p rc-6 -w /usr/lib/udev/rc_keymaps/rc6_mce.toml
/usr/sbin/eventlircd --evmap=/etc/eventlircd.d --socket=/var/run/lirc/lircd -f &
systemctl start irexec

And now all my “private” enhancements of IR handling by irexec AND kodi can be controlled by my IR remote as intended.

Next step will be to make those changes permanent across reboots and to adapt my smathome routines. My plan is that raspberry’s IR receiver will forward any poweron/off signals towards my smarthome (simply by detecting poweron/off intended for e.g. my BDP player).

Then I’ll have to solder my IR sender and test that. I do expect (as @darwindesign already wrote) that ir-ctl will fail as ir-keytable fails when eventlircd is running. But gemini AI suggested to use /dev/lirc? directly like

ir-ctl -d /dev/lirc1 -S nec:0x835590

because SENDING might work in parallel. Also unknown if the transmitter is using the same special device, probabely it’s another one like /dev/lirc1.

Now my ir-keytable based raspberry setup seems to be stable across re-boot. I mainly had to adapt eventlircd.service & irexec.service. And I had to disable the udev rule 98-lircd.rules by renaming it (only files with extension .rules are used, BTW there existed already an .disabled original lircd rule). Sadly one cannot upload files thus I can only roughly describe what I did.

One bigger hurdle was to load multiple toml files into ir-keytable. It works ONLY if one uses the double star pattern within /etc/rc_maps.cfg

In the meantime I did solder the circuit to power an IR led. The IR sender is activated by “dtoverlay=pwm-ir-tx,gpio_pin=18” within config-user.txt After reboot the additional device /dev/lirc1 is created automatically.

Installation of v4l-utils will provide the command ir-ctl. And “ir-ctl -d /dev/lirc1 -S nec:0x472“ sends some IR code. ir-ctl can be used independently from eventlircd. The blinking of the IR led is visible by a digital camera. Sadly my code is not detected by my AV device, but that’s not to be discussed herein.

Additional remark: Only ir-keytable is blocked when eventlircd is running. irw, irexec,and kodi can all READ keypresses in parallel. Call irw with the input socket /var/run/lirc/lircd provided by eventlircd to see keypresses.

My final conclusion: Receiving and sending IR in parallel is possible when using in kernel IR handling, but I was not able to use irrecord.

Regards, Michael

Addendum: Now sending of IR works - one has to send each scancode TWICE. And my IR transmitter only works for some 10cm distance.

Addendum2: After last reboot linux renumbered /dev/lirc{0,1} - afterwards /dev/lirc1 was the IR receiver and /dev/lirc0 the transmitter. Sadly that exchange was not handled properly by eventlircd - it didn’t see the corresponding /dev/input/event?. As a solution I have added an additional udev rule with the help from gemini:

SUBSYSTEM==“input”, KERNELS==“rc*”,
ENV{eventlircd_enable}=“true”,
ENV{eventlircd_evmap}=“default.evmap”

Addendum3: The driver pwm-ir-tx often fails to send the scancode for standard kernel settings. If one sets the raspberry pi 4 to performance mode, IR sending works reliable. But running continuously at max cpu frequency is not a good solution.

There is another IR driver gpio-ir-tx which does generate the 38kHz carrier signal in software. And that works fine!

My conclusion: If you want to sent IR signals go with gpio-ir-tx (for pi 4 and newer).

1 Like