I have two lirc devices on my system (Arch Linux). Devices is working properly, but the logs Errors occur frequently after starting Kodi(XBMC) application with --lircdev /dev/lircd1 parameter.
Looking at lircd:pd3.service: I don't understand what's going on here. What kind of device is /var/run/lircd1? Is arch creating the regular kernel devices in /var/run?
Why a symlink instead of just giving the device to lircd?
"Confused"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kodi (XBMC) app use /dev/lircd by default. I have multiseat system on Arch, and 3 running instances of Kodi (with command line parameters, --lircdev...). 1st instance use /dev/lircd by default with devinput driver on HP Media Remote, 2nd instance with USB-CEC adapter without lirc and 3rd instance with Bluetooth PS3 BD remote (bdremote-ng+lirc) (/dev/lircd1). All worked, but the logs errors occur frequently. On older versions of lirc`s all worked fine, without errors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm really lost here. In a sane setup /dev/lirc* devices are read by lircd which then provides data which applications such as Kodi can read on /var/run/lircd. When using multiple lircd instances, the usual setup is to create more output sockets in /var/run/lirc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tend to think that this is not really a lircd bug. When you run lircd without kodi there's really no problem. right?
To make any conclusion here, we need to reproduce the problem without running Kodi. Can you do that, using the /dev/lirc* devices as as input and sane output socket devices in /var/run/lirc?
EDIT: Raising the debug level to 'debug' to get some more info in the logs is also helpful
Last edit: Alec Leamas 2015-01-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, from lircds' perspective this is as expected. It needs to have exclusive access to the /dev/lircd* devices, and when Kodi accesses these as well there is conflicts.
What I really can't understand is why Kodi should access /dev/lircd1. This is raw timing or driver data, not decoded button press events. Why should Kodi read this? I don't know kodi thouroghly, but lirc-enabled applications normally read the button events lircd makes available on (in this case) /var/run/lircd1.
And if Kodi really needs to access /dev/lirc1, then you can't have a lircd instance reading from that device. It's as simple as that.
EDIT: A simple google shows that the kodi option should indeed be --lircdev /var/run/lircd1.
Also this search revealed "advices" that users should do what you did: 'ln -s /var/run/lircd /dev/lirc0' or so. However, as this actually is to link the output device to the input one this advice makes no sense, and in those cases it has worked it's a lircd bug. It shouldn't, really.
There is strange stuff floating around out there, for sure.
Last edit: Alec Leamas 2015-01-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, if this configuration worked, that was a bug. Which is now fixed, since lircd now writes proper warning messages :) Your setup just isn't sane.
As of now, there is no UI to completely disable the logging.
You should not have these messages, and as I understand it you will get rid of them by giving kodi the correct device option --lircdev /var/run/lirc/lircd1. Having conflicts on the input device as you have just isn't supported.
Closing as NOTABUG. If you have more problems, please use the mailing list (which more folks are reading) until we can agree upon that there is a lircd bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I`m starting Kodi with --lircdev /var/run/lirc/lircd1 and disable "device" option in /etc/lirc/lirc_ps3.conf. Remote working, lircd send:
янв 31 09:18:10 KODI lircd-0.9.2[28365]: Info: initializing '/dev/lirc0'
янв 31 09:18:10 KODI lircd-0.9.2[28365]: Error: unable to open '/dev/lirc0'
янв 31 09:18:11 KODI lircd-0.9.2[28365]: Info: initializing '/dev/lirc0'
etc...
Why does he do it? It is not clear ...
Thanks for help :))
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A lircd instance reads raw driver data from a kernel device such as /dev/lirc1 and writes decoded button-press events to a socket, in your case /var/run/lirc/lircd1.
lirc-enabled applications such as kodi reads the decoded button-press events from the socket.
The kodi setup looks OK (fingers crossed, don't really know kodi).
But: lircd always needs an input device. If you disable the
'device' option (why?) it will fall back to a driver-dependent default. Using the devinput driver it will then use /dev/lirc0. But I presume that your setup have the kernel data on /dev/lircd1, right?.
So: why did come up with this idea to disable the 'device' argument?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is an insane configuration. The results when symlinking the output device /var/run/lirc/lircd1 to the input device /dev/lirc1 are undefined.
Besides that, what processes listens to the output sockets /var/run/lirc/lircd (default, used by lircd_hp.service) and /var/run/lirc/lircd1? Have you verified that these sockets works as intended using irw(1)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that lirc is shipped with systemd service and socket files.
The general approach to two independent services for two remotes w different drivers:
Configure the first driver as described in the Configuration Guide. This will
end up in /etc/lirc/lircd.conf and /etc/lirc/lirc_options.conf. It will use the
default services in /lib/systemd/system/{lircd.socket, lircd.service}
Edit lircd_2.service by adding at least --device, --output, --driver + a
lircd.conf file to ExecStart. Also change the Description to something sane.
The --output socket should match lircd_2.socket.
At this point you should have two services lircd.service and lircd_2.service, one for each remote. They must not use the same input device or output socket. When everything is fine, use systemctl enable lircd.socket to make autostart work as intended.
Also note that this approach means that applications can connect to either of the two remotes, but not both. This is a basic design problem with current lirc, see [#37]
I will not answer anything more in this bug, which is closed.
Looking at lircd:pd3.service: I don't understand what's going on here. What kind of device is /var/run/lircd1? Is arch creating the regular kernel devices in /var/run?
Why a symlink instead of just giving the device to lircd?
"Confused"
Kodi (XBMC) app use /dev/lircd by default. I have multiseat system on Arch, and 3 running instances of Kodi (with command line parameters, --lircdev...). 1st instance use /dev/lircd by default with devinput driver on HP Media Remote, 2nd instance with USB-CEC adapter without lirc and 3rd instance with Bluetooth PS3 BD remote (bdremote-ng+lirc) (/dev/lircd1). All worked, but the logs errors occur frequently. On older versions of lirc`s all worked fine, without errors.
For what? What does Kodi expect on this device?
I'm really lost here. In a sane setup /dev/lirc* devices are read by lircd which then provides data which applications such as Kodi can read on /var/run/lircd. When using multiple lircd instances, the usual setup is to create more output sockets in /var/run/lirc
Nope, it does not: current kodi 14.0 uses /var/run/lirc/lircd:
All logs, with running Kodi, after shutdown Kodi, started lircd without Kodi.
ExecStartPre=/usr/bin/ln -sf /var/run/lirc/lircd1 /dev/lircd1 not needed, removed.
I tend to think that this is not really a lircd bug. When you run lircd without kodi there's really no problem. right?
To make any conclusion here, we need to reproduce the problem without running Kodi. Can you do that, using the /dev/lirc* devices as as input and sane output socket devices in /var/run/lirc?
EDIT: Raising the debug level to 'debug' to get some more info in the logs is also helpful
Last edit: Alec Leamas 2015-01-30
I understand, lirсd trying to connect to a device /dev/lircd1 that is already occupied by KODI, but why?
The scheme is:
1.Starting Lirc...and all is super fine :)
янв 30 14:58:07 KODI lircd-0.9.2[13501]: Notice: Running as user vis2
янв 30 14:58:07 KODI lircd-0.9.2[13501]: Info: Using remote: devinput.
янв 30 14:58:07 KODI lircd-0.9.2[13501]: Info: Using remote: devinput.
янв 30 14:58:07 KODI lircd-0.9.2[13503]: Notice: lircd(devinput) ready, using /var/run/lirc/lircd1
янв 30 14:58:07 KODI lircd-0.9.2[13503]: Notice: connected to 127.0.0.1
2.Waiting... hour...two...no errors
2.Starting Kodi
$ DISPLAY=:2 /usr/local/bin/kodi2 --lircdev /dev/lircd1
....Started...Remote working...
3.Lircd sends greetings with errors:
янв 30 15:16:16 KODI lircd-0.9.2[13503]: Error: unable to open '/dev/lircd1'
янв 30 15:16:17 KODI lircd-0.9.2[13503]: Info: initializing '/dev/lircd1'
янв 30 15:16:17 KODI lircd-0.9.2[13503]: Error: unable to open '/dev/lircd1'
янв 30 15:16:18 KODI lircd-0.9.2[13503]: Info: initializing '/dev/lircd1'
Well, from lircds' perspective this is as expected. It needs to have exclusive access to the /dev/lircd* devices, and when Kodi accesses these as well there is conflicts.
What I really can't understand is why Kodi should access /dev/lircd1. This is raw timing or driver data, not decoded button press events. Why should Kodi read this? I don't know kodi thouroghly, but lirc-enabled applications normally read the button events lircd makes available on (in this case) /var/run/lircd1.
And if Kodi really needs to access /dev/lirc1, then you can't have a lircd instance reading from that device. It's as simple as that.
EDIT: A simple google shows that the kodi option should indeed be --lircdev /var/run/lircd1.
Also this search revealed "advices" that users should do what you did: 'ln -s /var/run/lircd /dev/lirc0' or so. However, as this actually is to link the output device to the input one this advice makes no sense, and in those cases it has worked it's a lircd bug. It shouldn't, really.
There is strange stuff floating around out there, for sure.
Last edit: Alec Leamas 2015-01-30
Frankly, this just looks like a messed up installation. Unless there is more input I will close this as NOTABUG.
On the previous versions of lircd i never had a problems. :)
e.g.:
lirc-1:0.9.1.a-12-x86_64.pkg.tar.xz
lirc-utils-1:0.9.1.a-9-x86_64
How can I completely disable lircd logs? Сonstantly writes to the journalctl log these errors ^_^
Well, if this configuration worked, that was a bug. Which is now fixed, since lircd now writes proper warning messages :) Your setup just isn't sane.
As of now, there is no UI to completely disable the logging.
You should not have these messages, and as I understand it you will get rid of them by giving kodi the correct device option --lircdev /var/run/lirc/lircd1. Having conflicts on the input device as you have just isn't supported.
Closing as NOTABUG. If you have more problems, please use the mailing list (which more folks are reading) until we can agree upon that there is a lircd bug.
I`m starting Kodi with --lircdev /var/run/lirc/lircd1 and disable "device" option in /etc/lirc/lirc_ps3.conf. Remote working, lircd send:
янв 31 09:18:10 KODI lircd-0.9.2[28365]: Info: initializing '/dev/lirc0'
янв 31 09:18:10 KODI lircd-0.9.2[28365]: Error: unable to open '/dev/lirc0'
янв 31 09:18:11 KODI lircd-0.9.2[28365]: Info: initializing '/dev/lirc0'
etc...
Why does he do it? It is not clear ...
Thanks for help :))
You still don't get it.
A lircd instance reads raw driver data from a kernel device such as /dev/lirc1 and writes decoded button-press events to a socket, in your case /var/run/lirc/lircd1.
lirc-enabled applications such as kodi reads the decoded button-press events from the socket.
The kodi setup looks OK (fingers crossed, don't really know kodi).
But: lircd always needs an input device. If you disable the
'device' option (why?) it will fall back to a driver-dependent default. Using the devinput driver it will then use /dev/lirc0. But I presume that your setup have the kernel data on /dev/lircd1, right?.
So: why did come up with this idea to disable the 'device' argument?
I did a rollback to a previous version of a package
lirc-1:0.9.1.a-12-x86_64.pkg.tar.xz
lirc-utils-1:0.9.1.a-9-x86_64.pkg.tar.xz
No errors at all.
This is an insane configuration. The results when symlinking the output device /var/run/lirc/lircd1 to the input device /dev/lirc1 are undefined.
Besides that, what processes listens to the output sockets /var/run/lirc/lircd (default, used by lircd_hp.service) and /var/run/lirc/lircd1? Have you verified that these sockets works as intended using irw(1)?
Then please tell me how to organize the work of two remote controls simultaneously. ;)
However, at this moment all worked fine.
All information about configuring these remotes was taken
here: IR Remote
and here: PS3 BD Remote
Thanks for help. :)
Frankly, no. This bug is closed, and the ticket system is not a help forum. This is partly my bad, I should have stopped this when the bug was closed.
The support forum is the mailing list.
Before that, please look at the Configuration Guide.
Note that lirc is shipped with systemd service and socket files.
The general approach to two independent services for two remotes w different drivers:
end up in /etc/lirc/lircd.conf and /etc/lirc/lirc_options.conf. It will use the
default services in /lib/systemd/system/{lircd.socket, lircd.service}
Create a new socket definition
Edit lircd_2.socket so it uses a new socket, update the Description.
Create a new service definition
Edit lircd_2.service by adding at least --device, --output, --driver + a
lircd.conf file to ExecStart. Also change the Description to something sane.
The --output socket should match lircd_2.socket.
At this point you should have two services lircd.service and lircd_2.service, one for each remote. They must not use the same input device or output socket. When everything is fine, use
systemctl enable lircd.socketto make autostart work as intended.Also note that this approach means that applications can connect to either of the two remotes, but not both. This is a basic design problem with current lirc, see [#37]
I will not answer anything more in this bug, which is closed.
Related
Tickets: #37
Last edit: Alec Leamas 2015-02-03
Ok! Thanks for all! :)