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…
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
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…
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.
obviously I have experienced a similar symptom caused by some other technical reason…
Anyway, I just wanted to help.
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…
Originally within our config.txt - /boot/config.txt - we had:
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:
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 →
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!!
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?
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.
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.
haha, cheers for the welcome back Sam, I’m good thanks.
Ok cheers, I’ll look out for the updates.
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.
Is this a problem on Raspbian?
Last time I tested Raspbian, it worked. But that was around January time, so things may have changed. I’ll dig out my spare Pi and IR blaster later today/tomorrow and test again.
Cheers - would be good to confirm.
Ok, so I’ve tested with a spare Pi 0, GPIO IR blaster and 3 SD cards. 1 SD has a fresh install of Raspbian Buster (image downloaded today), 1 has an older install of Raspbian Stretch and the final card has a fresh install of OSMC.
Both Raspbian installs send IR without issue, OSMC still has issues. As I found before, this only seems to affect certain IR protocols (nec is worst) and monitoring the IR space/pulse sequence shows something is sent, and parts of it look fairly close to what they should be, but other parts the timing is quite far off what it should be and the whole sequence is an inconsistent length. I’ve tried using both ‘irsend’ and ‘ir-ctl’ with the same results.
output of ‘uname -a’ for each install
Raspbian Stretch -
Linux raspberrypi 4.19.66+ #1253 Thu Aug 15 11:37:30 BST 2019 armv6l GNU/Linux
Raspbian Buster -
Linux raspberrypi 4.19.118+ #1311 Mon Apr 27 14:16:15 BST 2020 armv6l GNU/Linux
Linux osmc 4.19.122-1-osmc #1 PREEMPT Wed May 27 04:13:18 UTC 2020 armv6l GNU/Linux
Can you post the output of dpkg -l | grep lirc on Raspbian?
Perhaps they have some special patches for this.
It’s also worth checking config.txt and lsmod for potential differences.
I think it’s something to do with Kodi. Just tried
sudo systemctl stop mediacenter on OSMC and then IR codes sent perfectly, start Kodi again and the problems return.
there is no output, Raspbian doesn’t have lirc installed by default, rc-core and ir-ctl handles IR stuff. (I did install lirc so I could test irsend but uninstalled again after)
That’s an interesting data point.
It’s possible that Kodi is hogging CPU time and causes some signals to be dropped / not handled in a timely enough manner.
Can you check CPU usage?
On my test system Kodi is sitting at around 37% CPU. With irsend repeatedly sending a key press lircd is using ~8.5%.
I have now tried installing Kodi on Raspbian. With Kodi running Raspbian has the same problems as OSMC. So it looks like this is not an OSMC issue and is instead a conflict between the gpio-ir-tx driver and Kodi… No idea where to go with this now, but i guess maybe the Kodi forums and/or contacting someone who knows more about the driver is the best bet. I’m thinking it may be quicker and easier to build an ir blaster from one of the atmega chips I have hiding in a draw somewhere.
Can you try renice the irrecord process and see if that helps?