IR Not Working After October Update

[sam_nazarko]

Yes, the 4.19 kernel does bring new IR drivers for Raspberry Pi.

[stip]

Thanks for this information!
I had the same problem, transmit didn’t work anymore after update. With the latest update, I was able to load the tx module.
I was able to set up the new drivers better with the information from this page:
lirc_rpi got replaced by gpio-ir and gpio-ir-tx, how do I upgrade? · Issue #2993 · raspberrypi/linux · GitHub

But now I suffer from the same problem, the transfer only works sporadically.
Any ideas on what the cause is and how to solve this?

[Quonith]

I’ve dug out a couple of old Pis and made up an extra IR receiver and blaster and been having a bit of a play to see if I can get anywhere. What I’ve found so far is:

1. The type of pi makes no difference, it was just coincidence that I was only having issues with my pi zero based media centre.
2. Even when IR sending doesn’t work it IS still sending something with the IR LED, it’s just that the pulse/space timings are WAY off (e.g. a 7000us pulse when it should be a ~500us)
3. From my limited testing it seems that the IR protocol being sent matters. For me, sending ‘necx’ codes works every time, ‘rc5’ is flaky and only works about 30% of the time, ‘nec’ doesn’t send successfully at all.
4. The issues do seem to be specific to OSMC. I setup Raspbian and was able to successfully and consistently send (with gpio-ir-tx) all the IR codes that were causing issues with OSMC. Were there any changes to gpio-ir-tx between kernel versions 4.19.55 (OSMC) and 4.19.75 (Raspbian)?

I’ll continue playing with it when I have spare time and see if I can find anything else.

[sam_nazarko]

@Quonith

Were there any changes to gpio-ir-tx between kernel versions 4.19.55 (OSMC) and 4.19.75 (Raspbian)?

We can update the kernel if you’re happy to give it some testing

Sam

[Quonith]

Certainly willing to give it a try.

[penfold42]

Me too - I’ve done similar tests and current Raspbian kernel works fine.

I’m using lircd for the deciding - not using the kernels protocol support.

[deomaki]

Hi,

are you using omxplayer?
If you do so, switch to mmal instead - this should solve your problem…

Regards
Markus

[ActionA]

Mmal has nothing to do with ir function. I suspect spam here. Failure to respond will result in account termination and thread cleanup.

[deomaki]

Hello,

first of all, even if you are a moderator, I find it very sad to hear such a reply…

Well, to “justify” my statement regarding omxplayer/mmal:
After the last update I was facing exactly the same problem: loss of ir functionality while using osmc. In my case I wasn’t able any longer to switch programs watching Live TV.
AFTER disabling the omxplayer my IR started working again. That’s just it.
Still suspecting spam?

Regards
Markus

[ActionA]

@deomaki

Still suspecting spam?

No, but I’d be quite surprised if changing the player could make any difference in remote function. As a moderator, I’m here to respond when a new account makes a post in a thread that seems too be wildly out of context. Our automated filters are quite good but not perfect. So maybe op decides to test your theory…

[deomaki]

To be more precise:
After the update I did, for what reason ever, change the settings for the player and experienced problems with
a) the ir
b) stuttering

Searching for a solution regarding the stuttering I stumbled across this and so I just reverted this change and voilà: The stuttering was gone AND the ir issue was also solved…
What maybe of interest as well: Both players were selected in the settings at the same time before I finally switched off omxplayer…

[Quonith]

As ActionA has said, it would be surprising if the player was affecting IR function and, given that the problems persist when nothing is playing, I really don’t expect the choice between OMX and MMAL to make any difference but I have tried anyway and, as expected, the player selection doesn’t make any difference.

[deomaki]

Hi Quonith,

obviously I have experienced a similar symptom caused by some other technical reason…
Anyway, I just wanted to help.

Regards
Markus

[Alcatr4zz]

Thanks for trying to help @deomaki! Unfortunately, there’s no connection to the used player as the problem also persists when no video is played.

Since multiple people say that it’s working for them in Raspbian, I suspect there’s an issue with the used kernel version in combination with the LIRC version in OSMC. I don’t have a Raspbian available. Can someone say which LIRC version is used there? And is it possible to install that one in OSMC?

I heavily rely on the IR transmission for my automations, so I decided to install the OSMC version from July on another RPi 1 that’s doing the actual IR transmission until the problem is fixed. So my RPi 2 with OSMC October tells my RPi 1 to transmit…

[TinyArcade]

Originally within our config.txt - /boot/config.txt - we had:

dtoverlay=lirc-rpi,gpio_in_pin=23,gpio_out_pin=22

This was set years ago from an old guide for setting up LIRC on a Raspberry Pi.

Assigning this to dtoverlay might no longer work with the update of OSMC. But we’ve also read from another thread that OSMC updates do not have any control over changing transmission for LIRC, but a moderator could probably better address that.

We poked around on this thread and also at this thread:

IR Remote Control with lirc

With the latest update, the remote control stopped working. Solution to the problem (by default, instead of pin 23, it was 17) On OSMC, with your keyboard, go through My OSMC → Pi Config → Hardware Support → - gpio_out_pin , (if there is no –gpio_out_pin in Hardware Support, select Enable LIRC GPIO support and press Enter) and press the key left or right arrow to change it to 23. Then press the down arrow key to turn to -gpio_in_pin, also press left or right to change it to 18 Like this: …

and after we followed the advice of going to the OSMC Setting:

On OSMC, with your keyboard, go through My OSMC → Pi Config → Hardware Support →

We set:
gpio_pin(0 for disabled) - to 22 - Might be different verbiage depending on the version of OSMC.

We then restarted.

Later we found that after explicitly setting dtoverlay=gpio-ir-tx,gpio_pin=22 in /boot/config.txt , the transmitter worked once again. - This was also after rebooting.

We are assuming that the more import part of this assignment is the gpio-ir-tx.
We don’t need the receiver, so we don’t know the correct assignment for rx.

Also, we don’t know if it matters (we were trying just about anything at this point) , we replaced /etc/lirc/tv.conf with our config with known working remote codes and chose this as the default remote by simply selecting it in the Remotes section of My OSMC.

Hope this helps somebody else!!

[stip]

So the settings are fixed now, but I still have the issue where the sending only works sometimes, very randomly (apparently as I’ve read due to timing). Is there any way I can do to help to solve this issue?

[nadnerb]

@stip

I still have the issue where the sending only works sometimes

I have the same issue.
Tried the above solution to change /boot/config.txt slightly and the first command I sent worked, but subsequent commands don’t seem to work reliably.
Has there been any further progress in fixing this?

btw, if you don’t have an IR blaster for testing, it’s very easy to make one. Remove an LED from an any old IR remote and wire it to pin 17 and GND.

[sam_nazarko]

Wow.

Long time no see @nadnerb. Hope you’re doing well.
I’ll bump the kernel shortly and post some instructions on how to update. I’m hoping that will do the trick; otherwise we’ll need to investigate further.

Sam

[nadnerb]

haha, cheers for the welcome back Sam, I’m good thanks.
Ok cheers, I’ll look out for the updates.

[Quonith]

I noticed that the kernel version has been bumped in the latest update so have had a quick test with my kitchen TV… Unfortunately it still doesn’t seem to be working. It’s been a while since I last tried IR sending on that Pi/TV so I might just be doing something silly wrong. I’ll try to do some more thorough testing over the weekend.