LIRC not working on Pi3 after October 2020 update

Hi
I’m using osmc on 2 RPi3 with separate TVHeadEnd client and server Pis.
After updating to osmc 2020-10 build my IR remote control no longer works. I can access using an HDMI remote, but this does not allow be to access all functions.

In the Pi Config page there is no longer an options to enable LIRC. Instead there is a warning:
“Warning: GPIO remote support with default pins incompatible with HiFiBerry and I……”

After the update my /boot/config.txt had the entry:
dtoverlay=gpio-ir,gpio_pin=18

I tried changing the pin to 23 and moving the IR reveiver pin accordingly, but the warning message was the same and the remote still does not work.

Any ideas?
Thanks

To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.

Depending on the used skin you have to set the settings-level to standard or higher, in summary:

  • enable debug logging at settings->system->logging

  • reboot the OSMC device twice(!)

  • reproduce the issue

  • upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A

  • publish the provided URL from the log set upload, here

Thanks for your understanding. We hope that we can help you get up and running again shortly.

OSMC skin screenshot:

Sam

As requested enabled logging and rebooted twice as requested.

To recreate the problem I simply tried to use the IR remote (which didn’t work), so I’m not sure that will show anything directly. I proceeded to use my HDMI remote to carry out the log upload.

Uploaded logs to https://paste.osmc.tv/penenazofa

Regards

Andy

Hi,

Did you learn the lircd.conf profile yourself using irrecord ? I notice it is using raw codes, instead of normal protocol decoders, and I wonder if that is the issue. What kind of remote is it ?

Lircd seems to be loading normally so my suspicion is the profile with raw codes is not working with this newer version of lirc. I’ve never used the raw codes syntax myself as irrecord usually tries to detect the protocol in use and use protocol specific button codes.

It looks like it’s possible to convert a raw profile to a normal configuration file using the -a option in irrecord:

https://manpages.debian.org/stretch/lirc/irrecord.1.en.html

-a --analyse
Analyse a raw_codes config file, trying to convert it to a regular configuration.

That might be worth trying.

It’s a few years since I create the conf file. I did indeed create it ‘from scratch’ and it uses a WD TV Live remote control. I can’t remember how exactly I created it - presumably using irrecord or something similar.

Using irrecord -1 I was able to create much simplified conf file (see below). However, the remote still does not work. I’ve reverted back to pin 18 that I used originally.

I’m still a bit confused as to what’s happened to the ‘Enable LIRC’ option. Is this not required any more?

Is there an easy way to make sure the IR hardware is working?

Thanks

begin remote

name /home/pi/lircd.conf
bits 32
flags SPACE_ENC|CONST_LENGTH
eps 30
aeps 100

header 8988 4429
one 599 1652
zero 599 556
ptrail 599
gap 107435
toggle_bit_mask 0x0
frequency 38000

  begin codes
      KEY_POWER                0x219E48B7
      KEY_HOME                 0x219E609F
      KEY_SUBTITLE             0x219E30CF
      KEY_AUDIO                0x219EB04F
      KEY_PREVIOUSSONG         0x219E40BF
      KEY_STOP                 0x219E20DF
      KEY_NEXTSONG             0x219E807F
      KEY_REWIND               0x219EF807
      KEY_PLAYPAUSE            0x219E50AF
      KEY_FASTFORWARD          0x219E7887
      KEY_BACK                 0x219ED827
      KEY_UP                   0x219EA05F
      KEY_MENU                 0x219E58A7
      KEY_LEFT                 0x219EE01F
      KEY_OK                   0x219E10EF
      KEY_RIGHT                0x219E906F
      KEY_PREVIOUS             0x219E32CD
      KEY_DOWN                 0x219E00FF
      KEY_NEXT                 0x219EC03F
      KEY_MUTE                 0x219EB24D
      KEY_SETUP                0x219E827D
      KEY_GREEN                0x219E28D7
      KEY_RED                  0x219EA857
      KEY_YELLOW               0x219E6897
      KEY_BLUE                 0x219EE817
      KEY_1                    0x219E18E7
      KEY_2                    0x219E9867
      KEY_3                    0x219E708F
      KEY_4                    0x219E38C7
      KEY_5                    0x219EB847
      KEY_6                    0x219E7A85
      KEY_7                    0x219EBA45
      KEY_8                    0x219E3AC5
      KEY_9                    0x219EFA05
      KEY_SEARCH               0x219EF00F
      KEY_0                    0x219E8877
      KEY_EJECTCD              0x219E08F7
  end codes

end remote

You can test the IR hardware and receiver using mode2 - before using mode2 or irrecord you need to stop lircd which can be done like this:

sudo systemctl stop lircd_helper@lirc0

Then run mode2 -d /dev/lirc0

When you press buttons on any remote at all you should see mark space lines scrolling by. If you do the IR receiver is working and the /dev/lirc0 device driver which lircd connects to is working. This also confirms you have the correct GPIO pin, as if you don’t you will get nothing.

To restart lircd when you’re finished using irrecord or mode 2 just run sudo systemctl restart lircd_helper@lirc0 or reboot.

If you still can’t get it working I would be inclined to try learning the remote again with irrecord.

I got mode2 to work as suggested. I had to install a new remote IR receiver, so something happened to the old one. It seems odd that it failed coincident with software upgrade, but nevertheless the new one works using pin 18 (some as original pin).

I used irrecord to re-learn remote. It is different to that analyzed from the old learned conf file.

However, still no joy getting it to work with osmc.

I’ve created a new debug log in case there’s anything I’ve messed up whilst trying to get it working. This of course also shows the new remote config : https://paste.osmc.tv/kusedeneda

Thanks for your continued help!

Is there anything else I can try to my IR remote working as my HDMI remote control has limited functionality?

Thanks

Just to let you know this isn’t forgotten, but we’re not sure what the issue could be at this time.

What do you see if you run irw /var/run/lirc/lircd and press buttons on the remote ?

Are you sure that irrecord recorded the remote properly, and that you used the correct key names when you named each key ?

I notice this error in your log:

Oct 21 14:56:17 osmc-james lircd-0.9.4c[275]: Notice: /etc/lirc/lircd.conf: wd-tv-live: Multiple values for same code: KEY_8
Oct 21 14:56:17 osmc-james lircd-0.9.4c[275]: Notice: /etc/lirc/lircd.conf: wd-tv-live: Multiple values for same code: KEY_SEARCH
Oct 21 14:56:17 osmc-james lircd-0.9.4c[275]: Notice: /etc/lirc/lircd.conf: wd-tv-live: Multiple values for same code: KEY_0

This may suggest that the remote has not been learnt properly although I don’t see anything visually wrong with your lircd.conf file. Clearly lircd is not happy with it though.

Another thing I’ve noticed is your config file has a line saying “driver devinput”. We don’t use the devinput driver on lircd, we use the “default” driver when we launch lircd.

Did you manually specify the “devinput” driver when using irrecord perhaps ? It might be worth removing that line from the conf and see what happens. I have a hunch that might fix it for you.

Thanks for the new ideas.

Running irw /var/run/lirc/lircd gives no response at all to key presses!

The driver devinput was inserted automatically when I used “irrecord -d /dev/lirc0” to record the remote.

Removing the line made no difference to the result

I re-recorded just the offending keys mentioned in the error message and updated the conf file. There are now no error messages see - https://paste.osmc.tv/sidetororo
decode value. That made me a bit concerned as I cannot see how it would work if there was no consistent output!

Despite your great efforts to help me I feel like I’m going backwards!

Unfortunately I’m out of ideas for the moment. The IR receiver is clearly working and able to record valid looking codes with irrecord, so I don’t understand why lircd will not decode them.

I may not have a solution yet, but you’ve been a great help and encouragement, so thank you.

I think I will have a go with another remote! I don’t have one of the ‘pre-packaged’ types, so will have to record another one from scratch.

Cheers

When using irrecord I had been using the command:
irrecord --device /dev/lirc0
This is why I was getting devinput.

I then tried
irrecord --device /dev/lirc0 --driver default

However, this then would not complete properly, reporting that it could not find the gap:

`
It is very important that you press many different buttons randomly
and hold them down for approximately one second. Each button should
generate at least one dot but never more than ten dots of output.
Don’t stop pressing buttons until two lines of dots (2x80) have
been generated.

Press RETURN now to start recording.

Got gap (107387 us)}

Please keep on pressing buttons like described above.
…Cannot find any gap, using an arbitrary 50 ms one. If you have a
regular remote for e. g., a TV or such this is probably a point
where you hit control-C. However, technical hardware like air
condition gear often works without any gap. If you think it’s
reasonable that your remote lacks gap you can proceed.
Press RETURN to continue.

`
This post on the pi forum - [LIRC: irrecord wont record, (Buster), mode2 works - Raspberry Pi Stack Exchange] seems to indicate that irrecord is not compatible with Buster. The solution suggested looks quite complex, and beyond my understanding.

The post is from over a year ago. Is it still relevant?

I remember seeing this before, but wasn’t sure why this was unique to Pi.
If it is – it’s going to be a pain to fix it. There may be a better solution.