vdr November 2022

vdr@linuxtv.org

5 participants
5 discussions

[ANNOUNCE] VDR version 2.6.2 released
by Klaus Schmidinger 03 Dec '22

03 Dec '22

VDR version 2.6.2 is now available at the official VDR GIT archive git://git.tvdr.de You can also get the latest stable version with git clone --branch stable/2.6 git://git.tvdr.de/vdr.git or as a tar archive with http://git.tvdr.de/?p=vdr.git;a=snapshot;h=refs/tags/2.6.2;sf=tbz2 This version fixes a few bugs that came up after the release of version 2.6.1. The changes since version 2.6.1: - Added UPDATE-2.6.0, which was missing in the official 2.6.0 release. - … [View More]Fixed unexpected calls of the '-r' script when a recording is interrupted and the timer has not yet finished. - Now dropping capabilities after opening terminal. - Now assuming the lock when removing deleted recordings even if the disk is full (reported by Claus Muus). - When checking whether a recording is still active, VDR no longer checks whether the index file is being written, but rather checks for the presence of a '.timer' file. The cutter now writes a dummy '.timer' file with timer ID '0' to make this work for recordings that are currently being edited. - Fixed a possible crash if an editing process is canceled while the edited recording is being replayed. - Added a warning if an attempt is made to obtain a write lock twice from the same thread. - Fixed default values for DVB-T (thanks to Winfried Köhler and Jose Angel). - Removed some unnecessary locks from SVDRPClientHandler. - Fixed a possible deadlock in case two SVDRP clients send each other POLL commands at the same time. - Added a missing 'const' to cTimers::GetTimerForEvent() (reported by Markus Ehrnsperger). - Added a chapter about locking to PLUGINS.html (suggested by Markus Ehrnsperger). - Implemented parsing frame rate and image size for MPEG2, H.264 and H.265 (thanks to Christoph Haubrich). - Using the frame rate parsed from the stream, with fall back to determining it from PTS values. - Fixed printing/scanning values for systems where %ld doesn't work for time_t. - Added support for kernel based LIRC driver (thanks to Marko Mäkelä). Use the command line option '--lirc=/dev/lirc0' to use this. Requires kernel version 5.10 or above. - Added periodic calls to malloc_trim(0) to reduce memory consumption (thanks to Onur Sentürk). - Fixed regenerating the index file of a recording in case it is present, but empty (reported by Stefan Herdler). - Added missing rounding when dividing frequencies in processing the NIT (thanks to Winfried Köhler). Homepage: http://www.tvdr.de Facebook: https://www.facebook.com/VideoDiskRecorder Have fun! [View Less]

2 1

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

irc/matrix/mastodon
by Mikko Tuumanen 16 Nov '22

16 Nov '22

Hello Are there any vdr-related irc channels or matrix rooms? Which hashtag we should use when mentioning VDR on Mastodon?

2 2

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2022