Isengard on Raspberry Pi will not work properly with an older kernel
Sam
Maybe a solution: in OSMC settings, GPIO - is LIRC enabled? If you don’t need irc, you don’t need the i2c_mux module.
Because i made a install of the previous version of OSMC, i can’t look about this
(sorry about my english)
lirc is enabled by default. In addition to making sure that the gpio lirc settings are disabled, as far as I know the only way to disable lirc completely is to:
sudo systemctl disable eventlircd
Then edit the mediacenter script as:
sudo nano /usr/bin/mediacenter
And change the following content from:
sudo -u osmc $KODI --standalone -fs --lircdev /var/run/lirc/lircd; CODE="$?"
To:
# sudo -u osmc $KODI --standalone -fs --lircdev /var/run/lirc/lircd; CODE="$?"
sudo -u osmc $KODI --standalone -fs; CODE="$?"
Then save and reboot.
Maybe Sam can provide a better way but this is how I’ve done it so far. Of course after each upgrade you will probably have to go through the above process again.
I originally experimented with gpio infrared but found it to be a bit laggy/problematic so I’ve switched to wireless and the performance is much better. So lirc is no longer needed.
This post by DBMandrake in another thread provides a way to roll back the kernel, but while it may restore your dvb-t, it could break other aspects of kodi isengard.
Your Fitipower FCXXXX module is pulling in an i2c module dependency? Can you do an lsmod and see what is listed? Wondering if i2c_dev is there …
Go to My OSMC
Disable ‘Enable LIRC GPIO remote support’ in Pi Config
Sam
It will. There are too many permutations here. Please start a new thread if you are affected by any issues.
Sam
I checked ‘Enable LIRC GPIO remote support’ and it was already disabled.
Same result for me whether enabled or disabled.
lsmod looks the same for me in both cases.
Going back to using Windows as TV tuner provider until resolved … sigh.
Disabling eventlircd does nothing to disable lircd. lircd and eventlircd are not the same thing.
Lircd does not run as a service - it is launched on the fly by udev when a lirc device node is detected.
All you need to do to prevent it using the GPIO lines is turn off LIRC GPIO remote support in Pi Config. If no other connected devices require lircd no lirc device nodes will be created and lircd will not be launched.
Not sure why you’re finding it laggy/problematic. GPIO IR remotes work absolutely perfectly for me on my Pi 2 - fast and responsive, no problems at all. I use an OSMC remote with a TSOP 38238 receiver.
At a guess I’d say the issue is with your chosen TSOP receiver - not all work well with the Raspberry Pi.
Yes I found that lirc is not a service, but eventlircd is a service. The receiver that I used is:
Vishay, 38kHz IR Receiver 950nm, 45m Range, Through Hole, 5 x 4.8 x 6.95mm, TSOP38238
I followed the recommended set-up procedures, including testing with irrecord etc. My personal preference after having gone through all this is to use a wireless remote. There is no need for line of sight, for example, and the kodi log can be used to set up different wireless devices, no need to use irrecord (for some remotes).
While enabling lirc by default is a good basic practice, for those users who use wireless it is unnecessary and consumes a little bit of RPi’s very limited resources. So for those users who do not want to use lirc, they should be able to disable it. As the system is set now, we can’t, because even when eventlircd is disabled with systemctl, as soon as we reboot or restart kodi, as soon as the mediacenter script is invoked, eventlircd is again invoked.
OK, as for me, I am manually disabling it. the only way I know how, which is to (1) disable eventlircd and (2) edit the mediacenter script. But every time an upgrade comes through, at least recently, the mediacenter script is replaced with the new one which invokes the unnecessary (for wireless users) eventlircd again. So I have to go through this process again. Whereas a piece of code, inserted in mediacenter, something like:
LIRCD=
if pgrep -n eventlircd &>/dev/null
then
LIRCD='--lircdev /var/run/lirc/lircd'
fi
sudo -u osmc $KODI --standalone -fs $LIRCD; CODE="$?"
could be a consideration. I was suggesting the addition of that simple code so that when eventlircd is disabled it stays disabled, even after upgrading, rebooting or restarting mediacenter. I cannot see the downside with this modification. But if the user is happy with the default setting, or wants to systemctl enable eventlircd, then fine, the mediacenter script automatically sets the lircdev too. Why the reluctance to consider this?
I will accept a PR on GitHub if this is not invasive
Sam
You still seem to be confusing lircd and eventlircd. They are not the same program, and serve different purposes.
Lircd is a program that decodes raw signals from IR remotes into key codes - it will only load if such a receiver is active. While its true that we enable GPIO IR remote by default in config.txt, (mainly so that an OSMC remote can work out of the box without any configuration) a user can disable it by disabling GPIO IR in Pi config as we have already explained. If you do this and do not have any other remote connected which requires Lircd to decode it will not load. I don’t know how I can be any more clear about this.
Eventlircd runs all the time because it serves a different purpose - it is a uinput aggregator and will take all input devices (aside from plain keyboards and mice) that are sent via the kernel uinput mechanism (including those from lircd) and aggregate them into one virtual remote, remap some keys (via evmap files) and then pass them to Kodi via a lirc socket.
Eventlircd is needed to handle remotes that do not use lircd, as well as those that do. For example I have a Fire TV Stick remote which is a bluetooth device - it does not require or load lircd but it does require eventlircd. In fact all remotes except CEC and IP based remotes will pass through eventlircd.
The problem is you don’t understand how the input system in OSMC works, and keep conflating lircd and eventlircd. It doesn’t work the way you think it does, therefore your suggestion is based on a faulty premise.
BTW if you really do want to disable eventlircd, simply mask the service:
sudo systemctl mask eventlircd.service
The resident set size of eventlircd is 984KB on my system - hardly a resource hog.
I didn’t say they were the same or offered the same function, I simply wanted to let it be known that invoking lircdev in the mediacenter script results in the enabling of eventlircd, even if it has been disabled with systemctl before restarting. So they are linked functionally, I really don’t know why. I only discovered this relationship after looking into all the running processes as a sort of optimization task. I would agree that on its own it’s not a resource hog, but I’ve gone through the process of disabling every unnecessary service and collectively this adds up to a significant benefit in terms of additional resource capacity.
It seems to me that masking eventlircd is not an optimal solution. Why would eventlircd be invoked when the lircdev is set in mediacenter? If one needs the other but the other is not available, could this not lead to undefined behavior? I would have thought it was safer just to ensure that lircdev is not set when eventlircd is not available. That is what I was suggesting. At any rate I’ll take Sam’s advice and explore the Github approach. Unfortunately this thread is going way off subject and perhaps looking into too great a depth; getting into the realm of development and design issues, really.
Oh a quick word of thanks for taking the trouble to explain what eventlircd does. My wireless remote works fine without it, but it is the only device on the Pi, there are no keyboards, mice, joysticks or others. So maybe my situation is the exception, rather than the rule.
But look at the mediacenter script at /usr/bin/mediacenter - do you see any lines that invoke eventlircd ? There are none.
Nor does udev start eventlircd, for example look at /lib/udev/rules.d/98-eventlircd.rules, written in the comment right at the top:
# An example udev rules file for eventlircd.
#
# This rules file does not start eventlircd. Many applications only check for
# the lircd socket at application lauch. Therefore, it is better to start
# eventlircd in an init script so that eventlircd creates the lircd socket
# before any applications that use LIRC launch.
Nor does it use systemd socket activation.
I just stopped the eventlircd service then restarted the mediacenter service - eventlircd did not restart, and there is no reason it should. To put it simply - we enable the eventlircd service to run automatically and there is nothing else that I am aware of that would start it, so disabling it should be enough.
However if you really want to prevent a service ever running (instead of just not automatically running at boot) you mask the service instead of disable it - that is the systemd way to accomplish such a task.
As I described above, it is not. I have no idea why this might be the case on your system, but it is not on mine.
But there is no need to do this because we have designed the system to always have eventlircd running - if you want to disable it that is up to you, but that’s not something we have designed for. It doesn’t hurt Kodi to disable eventlircd without removing the command line option from kodi.bin - it will grumble in the log file that it can’t connect to the lirc socket but it won’t upset Kodi functionality in any way.
If you really want to disable eventlircd simply mask the service as I suggested, then nothing can start it up, not even you manually trying to start it. Upgrades will not override your masking of the service.
I just checked the postinst script for the eventlircd package and it appears we always re-enable the service on eventlircd upgrades - this is partly due to expediency (it’s a lot more scripting to only do so on install and not upgrade) and partly due to the fact that we didn’t anticipate anyone wanting to disable it. So at the moment if you only disabled the service an upgrade might turn it back on again. However if you mask the service and attempt to enable it, it will still not enable the service. (Technically it is enabled and masked, which means if you ever unmasked it it would then be enabled)
I just altered the mediacenter script back to it’s original state and rebooted, you are right, eventlirc did not load. However, I can say with certainty that before this recent series of upgrades (during the last three or four days) the only way I could disable eventlircd between reboots/restarts it was to disable the lircdev in mediacenter. So something has changed I believe. There simply was no other way to do it.
Doesn’t this confirm that they are functionally linked as I suggested? Wouldn’t it be better/safer to disable the lircdev when eventlircd is disabled? And enable it when eventlircd is enabled? Is there not a risk of undefined behaviour, however small? The addition of three or four lines of code would address this issue.
Please understand that I’m not trying to be critical, I’m just trying to provide some ideas and suggestions.