[vdr] How to use /dev/lirc0 in VDR?
Hi all, TL;DR: How could I connect VDR to the kernel-provided /dev/lirc0 device? Is there a dummy lircd implementation that would simply open /dev/lirc0 in LIRC_MODE_SCANCODE and relay its contents over a socket? As far as I understand, LIRC was first implemented as a user-space daemon that would decode a bitstream (via various bit-banging interfaces) into scancodes that would then be relayed over a socket to the final application. At some point (before I started to use VDR in 2005 or 2006), support for remote control units was expanded in the Linux kernel, and also a translation into input events was implemented. In VDR, the input event interface can be used via the "remote" plugin (vdr -Premote). I think that this is what I always used with VDR, first using the cx88 driver (Hauppauge Nova-T PCI 90002) and now trying to use a USB stick (rtl82xxu, Astrometa DVB-T2) on a Raspberry Pi. The input event interface is mapping the stream of IR messages to "key-down", "key-up" and "key-repeat" events, which adds some inaccuracy. For the rtl82xxu, the repeat logic is broken: key-repeat or key-down events for long key presses are only being sent intermittently. The fix in https://patchwork.linuxtv.org/project/linux-media/list/?series=7322 improves it a lot. The USB interface for delivering IR events in a 128-byte buffer is prone to race conditions, and that cannot be fixed without changing the device firmware. There is also a kernel-based interface (such as /dev/lirc0) that can provide scan codes to end applications. Both the input event interface and this one would be polled by "ir-keytable -t". I would like to use the /dev/lirc0 interface with VDR, so that VDR has a chance to react to each and every IR message that is sent by the remote control unit. I think that this would minimize the disturbance caused by the broken USB protocol of the rtl82xxu. It is OK if one LIRC scancode of a long keypress (say, browsing a list of recordings) would be lost; another one would be sent in 113ms by the RC5 protocol. With the input event driver, a lost IR message would result in a bogus key-up event, a bogus key-down event, and a long delay before key-repeat events are generated again. My initial attempt at using /dev/lirc0 did not work: vdr -v /var/lib/vdr/video --no-kbd --lirc=/dev/lirc0 -Prpihddevice That is, pressing any buttons on the remote control unit did not have any effect, and VDR did not start in the "learning mode" either, even after I renamed the remote.conf that it is opening at startup. It appeared that a read() on "/dev/lirc0" would block indefinitely, but I did not check that. I noticed that VDR's lirc.c is explicitly opening a Unix domain socket to the LIRC device, while "ir-keytable -t" would invoke open(2) followed by ioctl(lircfd, LIRC_SET_REC_MODE, &mode): https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/keytable.c My goal would be to use the Hauppauge remote control with the Astrometa DVB-T2 stick and for it to be as responsive as it was back in 2006 with my patched cx88 driver. My implementation back then directly mapped IR messages to input events: (1) produced a key-down event for the first IR message (2) discard the first repeated IR message (to have an initial delay) (3) produced key-repeat events for subsequent IR messages (every 113ms) (4) if any key-up events were produced, that would be after a timeout that would be reset in (1),(2),(3). I think that it should be possible to implement this behaviour in a dummy lircd that translates /dev/lirc0 into a socket. Before I implement that from the scratch, I would like to know if something similar already exists. Related to this, I submitted a fix to the kernel to set the "repeat" flag in the LIRC scan codes when appropriate: https://patchwork.linuxtv.org/project/linux-media/list/?series=8338 Without this fix, it should still be possible to detect repeat key events (long key presses) by comparing successive scancodes. For protocols that do not include a toggle flag (like RC5 does), it might be possible to compare timestamps to distinguish long button presses from multiple short presses. Best regards, Marko ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG table 0
On 16.07.22 14:07, Richard F wrote:
>/I've just updated to VDR V2.61 after a long time on V2.2, using
the same config and the epgtableid0 (2.4.0) plug-in. />//>/The issue
I'm seeing is that when VDR is restarted, it doesn't seem to be
reading/respecting the epg.data file. />/... /
Is this the only EPG handler you have installed, or are there others?
If so, make sure this one is installed FIRST.
Klaus
Actually after more testing it seems the table 0 EPG entries are
always being overwritten after EPG scans, not just at startup.
The only EPG handler I have is XMLTV using SVDRP: once a day a script
clears the existing EPG then inserts new entries in table 0
The correct table 0 entries can be seen in VDR for a while, then get
overwritten after automatic scans.
I do need both types, as some channels / programmes don't have
current data in XMLTV, only DVB.
My command line is:
/usr/bin/vdr -c /etc/vdr -E /mnt/lvm0/TV/epg.data -l 2 --no-kbd -P
streamdev-server -P epgsearch -v 1 -l /var/log/epgsearch.log -m
/usr/local/bin/sendEmail.pl -P epgtableid0 -P vnsiserver -P
vdrmanager -P dummydevice -r /usr/local/bin/vdr-auto -u vdr --vfat -v
/mnt/lvm0/TV
There are quotes missing:
/usr/bin/vdr -c /etc/vdr -E /mnt/lvm0/TV/epg.data -l 2 --no-kbd -P
streamdev-server -P "epgsearch -v 1 -l /var/log/epgsearch.log -m
/usr/local/bin/sendEmail.pl" -P epgtableid0 -P vnsiserver -P
vdrmanager -P dummydevice -r /usr/local/bin/vdr-auto -u vdr --vfat -v
/mnt/lvm0/TV
Klaus
I should have explained - earlier I quoted the command line reported by
the kernel. It's actually created by runvdr.extreme.
So the plugins are recognised, the same way they were in 2.20 - here's
an excerpt of the startup
Jul 17 14:39:00 ha-server vdr[8699]: [8699] frontend 0/0 provides DVB-T with
QPSK,QAM16,QAM64 ("Conexant CX22702 DVB-T")
Jul 17 14:39:00 ha-server vdr[8699]: [8699] frontend 1/0 provides DVB-T,DVB-T2,DVB-C with
QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Silicon Labs Si2168")
Jul 17 14:39:00 ha-server vdr[8699]: [8699] found 2 DVB devices
Jul 17 14:39:00 ha-server vdr[8699]: [8699] initializing plugin:
streamdev-server (0.6.3): VDR Streaming Server
Jul 17 14:39:00 ha-server vdr[8699]: [8699] initializing plugin: epgsearch
(2.4.1): search the EPG for repeats and more
Jul 17 14:39:00 ha-server vdr[8699]: [8699] initializing plugin: epgtableid0
(2.4.0): EPG handler for events with table id 0x00
Jul 17 14:39:00 ha-server vdr[8699]: [8699] initializing plugin: vnsiserver
(1.8.0): VDR-Network-Streaming-Interface (VNSI) Server
Jul 17 14:39:00 ha-server vdr[8699]: [8699] initializing plugin: vdrmanager
(0.15): VDR-Manager plugin
Jul 17 14:39:00 ha-server vdr[8699]: [8699] initializing plugin: dummydevice
(2.0.0): Output device that does nothing
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG table 0
On 17.07.22 13:23, Richard F wrote: On 16.07.22 14:07, Richard F wrote: >/I've just updated to VDR V2.61 after a long time on V2.2, using the same config and the epgtableid0 (2.4.0) plug-in. />//>/The issue I'm seeing is that when VDR is restarted, it doesn't seem to be reading/respecting the epg.data file. />/... / Is this the only EPG handler you have installed, or are there others? If so, make sure this one is installed FIRST. Klaus Actually after more testing it seems the table 0 EPG entries are always being overwritten after EPG scans, not just at startup. The only EPG handler I have is XMLTV using SVDRP: once a day a script clears the existing EPG then inserts new entries in table 0 The correct table 0 entries can be seen in VDR for a while, then get overwritten after automatic scans. I do need both types, as some channels / programmes don't have current data in XMLTV, only DVB. My command line is: /usr/bin/vdr -c /etc/vdr -E /mnt/lvm0/TV/epg.data -l 2 --no-kbd -P streamdev-server -P epgsearch -v 1 -l /var/log/epgsearch.log -m /usr/local/bin/sendEmail.pl -P epgtableid0 -P vnsiserver -P vdrmanager -P dummydevice -r /usr/local/bin/vdr-auto -u vdr --vfat -v /mnt/lvm0/TV There are quotes missing: /usr/bin/vdr -c /etc/vdr -E /mnt/lvm0/TV/epg.data -l 2 --no-kbd -P streamdev-server -P "epgsearch -v 1 -l /var/log/epgsearch.log -m /usr/local/bin/sendEmail.pl" -P epgtableid0 -P vnsiserver -P vdrmanager -P dummydevice -r /usr/local/bin/vdr-auto -u vdr --vfat -v /mnt/lvm0/TV Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG table 0
On 16.07.22 14:07, Richard F wrote: >/I've just updated to VDR V2.61 after a long time on V2.2, using the same config and the epgtableid0 (2.4.0) plug-in. />//>/The issue I'm seeing is that when VDR is restarted, it doesn't seem to be reading/respecting the epg.data file. />/... / Is this the only EPG handler you have installed, or are there others? If so, make sure this one is installed FIRST. Klaus Actually after more testing it seems the table 0 EPG entries are always being overwritten after EPG scans, not just at startup. The only EPG handler I have is XMLTV using SVDRP: once a day a script clears the existing EPG then inserts new entries in table 0 The correct table 0 entries can be seen in VDR for a while, then get overwritten after automatic scans. I do need both types, as some channels / programmes don't have current data in XMLTV, only DVB. My command line is: /usr/bin/vdr -c /etc/vdr -E /mnt/lvm0/TV/epg.data -l 2 --no-kbd -P streamdev-server -P epgsearch -v 1 -l /var/log/epgsearch.log -m /usr/local/bin/sendEmail.pl -P epgtableid0 -P vnsiserver -P vdrmanager -P dummydevice -r /usr/local/bin/vdr-auto -u vdr --vfat -v /mnt/lvm0/TV (same as V2.20) Thx/Richard ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG table 0
On 16.07.22 14:07, Richard F wrote: I've just updated to VDR V2.61 after a long time on V2.2, using the same config and the epgtableid0 (2.4.0) plug-in. The issue I'm seeing is that when VDR is restarted, it doesn't seem to be reading/respecting the epg.data file. ... Is this the only EPG handler you have installed, or are there others? If so, make sure this one is installed FIRST. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
