vdr October 2022

vdr@linuxtv.org

3 participants
4 discussions

Making VDR run under Systemd
by Marko Mäkelä 28 Nov '22

28 Nov '22

Hi all, I was an active VDR user from about 2004 to 2010 when my children were younger and there was a need to record TV programs for them. The old setup was more or less abandoned when I got a smart TV and the family started to use video streaming services. Some years ago, I got a Raspberry Pi 2 B and an Astrometa DVB-T2 USB stick that also includes an infrared receiver. Because its bundled remote control unit (RCU) has much fewer buttons than the one that I got with the Hauppauge Nova-… [View More]T PCI 90002 years ago, I configured lircd to translate the RC5 codes from the old RCU. For output, I am using rpihddevice. Yesterday, I upgraded to VDR 2.5.6 and rpihddevice 1.0.4 from git://projects.vdr-developer.org/vdr-plugin-rpihddevice.git while keeping the rest of the Raspbian 9.13 mostly intact. I installed the self-built software simply by replacing the original /usr/bin/vdr that was part of the distribution's vdr 2.2.0 package, and copying the plugin to /usr/lib/vdr/plugins/. It might not be the cleanest solution, but it worked for me. I had some trouble with Systemd, which I resolved by creating a configuration file: # cat > /etc/systemd/system/vdr.service << EOF [Service] Restart=on-failure RestartSec=1s ExecStart=/usr/bin/vdr TimeoutStartSec=infinity EOF # systemctl daemon-reload # service lightdm stop # service vdr start I did not double-check it, but I understood that this could entirely bypass the /etc/init.d/vdr script, which would invoke the runvdr script (which normally runs vdr in a loop). If I choose Restart from the VDR menu, systemd will restart it nicely. I did not configure the Power button yet. Currently, VDR complains that no -s parameter is given when I press the Power button on the RCU. Ideally, I think that VDR should suspend the live video output and somehow inform Systemd that the entire system may be suspended, as far as VDR is concerned. (Of course, only if there are no recordings or remote connections active to VDR.) Then, if nothing else prevents the system from being shut down or suspended, Systemd would do it based on its configuration. Years ago, I developed some patches and configuration at https://iki.fi/msmakela/software/vdr/ to achieve something like this on my old system, and I would now like to revive this somehow. Ideally, the Power button would shut down the DVB receiver and display some indication on the OSD or the video frame buffer that the output has been suspended. If my Raspberry Pi were not an "always-on server" that runs some other services as well, I might want to reimplement the "wake-on-RCU" hardware that is generating a wake-on-LAN signal via the Nova-T PCI card, possibly by extending https://spellfoundry.com/product/sleepy-pi-2-usb-c/ or a similar product that would implement a wake-on-timer for the Raspberry Pi. Then, the system would power up nicely either by RCU or by a recording timer. Integrating the wake-on-timer logic with Systemd could be another challenge. I might try this on PC hardware, which already supports wake-on-timer out of the box. A quick search turned up a promising starting point: https://www.freedesktop.org/software/systemd/man/systemd.timer.html The motivation of this exercise is to have a stand-alone VDR front/back end installation that plays nicely with Systemd, without reinventing any logic around scheduling, startup, and shutdown. Maybe one day, once some more progress has been made with Wayland and when using a Raspberry Pi model with more GPU memory, one could press the Power button on the RCU and have the live TV pop up either fullscreen or in a window, on top of the graphical desktop (which would be available for generic use). Best regards, Marko [View Less]

5 16

Re: [vdr] EPG table 0
by Richard F 23 Nov '22

23 Nov '22

> 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 … [View More]

2 4

How to use /dev/lirc0 in VDR?
by Marko Mäkelä 06 Nov '22

06 Nov '22

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 … [View More]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 [View Less]

1 3

Getting started with Pi TV HAT and gpio-ir
by Marko Mäkelä 23 Oct '22

23 Oct '22

Hi all, Much of this message would probably belong to some wiki page, along with some photographs that I made. Before starting to write this, I checked https://vdr-projects.github.io and did not find any hardware projects. The hardware section of the VDR wiki at https://www.linuxtv.org does not seem to have been updated for years; it does not mention Raspberry Pi at all, despite it being a viable alternative for more than 10 years. I was an active VDR user from 2004 or 2005, when I … [View More]built a PC based setup, using a "budget" DVB-T card (Hauppauge Nova-T PCI). That system was never upgraded to DVB-T2; instead, we got a flat screen TV with a built-in tuner. Gradually, as our children got older, recordings were made and watched less often. We mostly stopped using VDR about 10 years ago. Since then, I have made some attempts to "come back", initially, using a Raspberry Pi 2 B and an Astrometa USB DVB-T/T2 stick. This month, I purchased a TV HAT case and the DVB-T/T2 uHAT for my Raspberry Pi 2 B. As far as I understand, the plexiglass TV HAT case should fit the Raspberry Pi 2, 3, and 4. The LED holes next to the MicroSD card slot are on the wrong side for the Pi 2, but everything fits perfectly. I regret that I did not buy the Pi TV HAT earlier. The USB stick is simply garbage compared to it. The Astrometa USB stick switches channels very slowly and the tuner very frequently produces errors in the bit stream, when using a good outdoor aerial that other devices have no trouble with. By design, its infrared receiver will lose messages when a button is being held down, because a 128-byte buffer of the microcontroller would overflow, and there is no way to use it as a ring buffer (I tried). A kernel maintainer came up with some experimental patches that significantly improved the situation, but every few of seconds some key-repeat events were still being lost. Out of that effort, a tiny patch from me was included in the Linux kernel, to have the kernel's LIRC interface set the "repeat" flag for all IR protocols: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… The Pi TV HAT is missing an infrared receiver out of the box. I soldered an IR receiver module to some thin wires, isolating the legs with heat shrink tube. The other ends of the thin wires I soldered to some pads next to the connector: 3.3V at pin 1, ground at pin 6 (or 9), and the signal output to GPIO 18 (pin 12). GPIO 17 at pin 11 would have worked as well. I made the IR receiver module stick out from a vent hole on the top, because my initial attempt of keeping the module inside the transparent lid of the case did not work that well. The module can pick up IR signal some 8 meters away. The software configuration was easy: (1) Add the following line to /boot/config.txt: dtoverlay=gpio-ir,gpio_pin=18 (2) Execute "sudo apt install ir-keytable" (3) Edit /etc/rc_maps.cfg to load a suitable table for your remote control unit. To reuse the old remote control unit that I had, I wrote an entry * * hauppauge.toml (4) Reboot for the config.txt change to take effect. For me, the remote control unit appeared in /dev/input/event0 as well as /dev/lirc0 and some buttons (such as the number keys) would directly work in the /dev/tty1 textual login prompt. For starting up VDR, I used a command like this: vdr -v /var/lib/vdr/video --no-kbd -Prpihddevice -P'remote -i /dev/input/event0' Yes, the Pi TV HAT was detected automatically; I did not have to do anything special. I had previously used the same VDR configuration with an Astrometa USB stick. This is with a copy of https://github.com/reufer/rpihddevice with some critical patches applied. (The issues and a pull request that I opened in January 2022 are still unattended.) The experience with the Pi TV HAT is simply great. The Sony tuner in the Pi TV HAT produces an error-free bit stream and switches transponders very quickly. The kernel GPIO IR driver is rock solid. I think that the user experience is at least as good as with my old PC setup. Some buttons on my remote control unit were unreliable. Using an expired debit card, I was able to pry open the grey Hauppauge remote control unit, starting next to the IR LED. I guess I should upload pictures of the internals somewhere, to help others open theirs. Next, I plan to attach some external storage for recordings. A USB 3.0 NVMe drive would allow faster backups (when detached from the Raspberry Pi 2) and an upgrade to a Pi 3 or 4. On the software side, I am thinking to apply my kernel patch and to write a "kernel LIRC plugin" for VDR that would allow me to use /dev/lirc0 for the input. I would prefer to use the lower-level interface where each IR message corresponds to an event. I do not like the key-repeat timer logic of the kernel's input event driver. And I never liked the user-space lircd. With best regards, Marko [View Less]

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr October 2022