vdr

vdr@linuxtv.org

3 participants
6742 discussions

[ANNOUNCE] VDR version 2.6.4 released
by Klaus Schmidinger 18 Feb '23

18 Feb '23

VDR version 2.6.4 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.4;sf=tbz2 This version fixes a few bugs that came up after the release of version 2.6.3. The changes since version 2.6.3: - Updated the Italian OSD texts (thanks to Diego Pierotto). - Fixed restoring the volume at program start (thanks to Matthias Senzel). - Fixed symmetry of Begin/EndSegmentTransfer() calls in cEIT::cEIT() (thanks to Jörg Wendel). - Added a note to epg.h about not messing with event ids (suggested by Winfried Köhler). - Added a note to vdr.5 about event ids possibly changing when an event moves from one table to another. - Fixed initializing cDvbPlayerControl (was broken in version 2.6.3). - Reverted 'Fixed a possible crash if an editing process is canceled while the edited recording is being replayed' (introduced in version 2.6.2), because it caused a deadlock when moving recordings between volumes. - Fixed a possible crash if an editing process is canceled while the edited recording is being replayed (new solution). - Fixed unnecessary interruption of ongoing recordings if timers avoided the transfer mode receiver device (thanks to Markus Ehrnsperger). - Revised support for kernel based LIRC driver (thanks to Marko Mäkelä). Homepage: http://www.tvdr.de Facebook: https://www.facebook.com/VideoDiskRecorder Have fun! Klaus

1 0

[PATCH] Use cThread::mutex with absolute cCondVar::TimedWait()
by Marko Mäkelä 18 Feb '23

18 Feb '23

Hi, I would propose the following patch, or some equivalent interface that would allow cThread::mutex to be used with some cCondVar in derived classes: diff --git a/thread.h b/thread.h index 16c4bd75..cd1d98ab 100644 --- a/thread.h +++ b/thread.h @@ -83,7 +83,9 @@ private: bool running; pthread_t childTid; tThreadId childThreadId; +protected: cMutex mutex; +private: char *description; bool lowPriority; static tThreadId mainThreadId; Because cThread::mutx is declared private and there is no helper member function, derived classes that wish to use condition variables have to instantiate a separate cMutex for that. Here is an example from the rpihddevice plugin that illustrates my point: diff --git a/omx.c b/omx.c --- a/omx.c +++ b/omx.c @@ -119,17 +119,17 @@ const char* cOmx::errStr(int err) void cOmx::Action(void) { cTimeMs timer; - m_mutex.Lock(); + Lock(); while (Running()) { while (m_portEvents.empty()) - if (m_portEventsAdded.TimedWait(m_mutex, 10)) + if (!m_portEventsAdded.TimedWait(mutex, 10)) goto timeout; { const Event event = m_portEvents.front(); m_portEvents.pop(); - m_mutex.Unlock(); + Unlock(); switch (event.event) { Actually, there is a bug above: the condition for the TimedWait() call was inverted. This code illustrates another limitation: There is no way to pass an absolute time to cCondVar::TimedWait(). On each call, a relative wake-up time (milliseconds from the current time) will be converted into an absolute time. If there was a way, we would be able to remove the "cTimeMs timer" and some related system calls, and have this loop both wake up every 100 milliseconds, and process events as soon as they arrive. Here is the VDR part of the patch: diff --git a/thread.c b/thread.c index 93eb8c0d..3dcb44d4 100644 --- a/thread.c +++ b/thread.c @@ -36,7 +36,7 @@ #define dbglocking(a...) #endif -static bool GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow) +bool cCondVar::GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow) { struct timeval now; if (gettimeofday(&now, NULL) == 0) { // get current time @@ -81,7 +81,7 @@ bool cCondWait::Wait(int TimeoutMs) if (!signaled) { if (TimeoutMs) { struct timespec abstime; - if (GetAbsTime(&abstime, TimeoutMs)) { + if (cCondVar::GetAbsTime(&abstime, TimeoutMs)) { while (!signaled) { if (pthread_cond_timedwait(&cond, &mutex, &abstime) == ETIMEDOUT) break; @@ -129,20 +129,27 @@ void cCondVar::Wait(cMutex &Mutex) } } +bool cCondVar::TimedWait(cMutex &Mutex, const timespec &abstime) +{ + int err = 0; + + if (int locked = Mutex.locked) { + Mutex.locked = 0; // have to clear the locked count here, as pthread_cond_timedwait + // does an implicit unlock of the mutex. + err = pthread_cond_timedwait(&cond, &Mutex.mutex, &abstime); + Mutex.locked = locked; + } + return err != ETIMEDOUT; +} + bool cCondVar::TimedWait(cMutex &Mutex, int TimeoutMs) { bool r = true; // true = condition signaled, false = timeout if (Mutex.locked) { struct timespec abstime; - if (GetAbsTime(&abstime, TimeoutMs)) { - int locked = Mutex.locked; - Mutex.locked = 0; // have to clear the locked count here, as pthread_cond_timedwait - // does an implicit unlock of the mutex. - if (pthread_cond_timedwait(&cond, &Mutex.mutex, &abstime) == ETIMEDOUT) - r = false; - Mutex.locked = locked; - } + if (GetAbsTime(&abstime, TimeoutMs)) + r = TimedWait(Mutex, abstime); } return r; } @@ -174,7 +181,7 @@ bool cRwLock::Lock(bool Write, int TimeoutMs) int Result = 0; struct timespec abstime; if (TimeoutMs) { - if (!GetAbsTime(&abstime, TimeoutMs)) + if (!cCondVar::GetAbsTime(&abstime, TimeoutMs)) TimeoutMs = 0; } if (Write) { diff --git a/thread.h b/thread.h index 16c4bd75..04bb4cc5 100644 --- a/thread.h +++ b/thread.h @@ -49,7 +49,9 @@ public: ~cCondVar(); void Wait(cMutex &Mutex); bool TimedWait(cMutex &Mutex, int TimeoutMs); + bool TimedWait(cMutex &Mutex, const timespec &abstime); void Broadcast(void); + static bool GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow); }; class cRwLock { I did not complete the change to rpihddevice cOmx::Action() yet. We may be forced to retain two mutexes after all, because OMX_EmptyThisBuffer() as well as one of the functions called from cOmx::StopAudio() would hang indefinitely, while holding the cOmx::mutex, blocking the cOmx::Action() thread. According to https://forums.raspberrypi.com/viewtopic.php?t=313170 the interface is largely deprecated. I will try to figure out something. Best regards, Marko

2 3

Running VDR from systemd on Raspberry Pi OS
by Marko Mäkelä 29 Dec '22

29 Dec '22

Yesterday, I finally bought external storage for my Raspberry Pi based VDR setup, a Samsung Portable SSD T7. It supports USB 3, but it also works on the Raspberry Pi 2's USB 2.0 and does not consume too much power. My old tower PC case based system that I had set up in 2004 has now been replaced with something that is better in every thinkable respect: power consumption, noise (passive cooling, no HDDs), speed, and size (not much larger than the remote control unit). Hardware: * Raspberry Pi 2 * Pi TV hat * TV hat case * an IR receiver attached via soldered wires to the TV hat, at GPIO pin 18 * a remote control unit (from an old Hauppauge Nova-T PCI card) * Samsung Portable SSD T7 (1 TB) Software: * Raspberry OS Legacy installed on a MicroSD card, with no GUI * sudo apt install ir-keytable * VDR 2.6.3 (or 2.6.2) compiled from source * https://github.com/reufer/rpihddevice/ compiled from source * "make install" to /usr/local My /boot/config.txt includes the following lines: dtoverlay=gpio-ir,gpio_pin=18 dtparam=audio=on gpu_mem=256 In /etc/rc_maps.cfg (the configuration file of ir-keytable), ensure that there is a line like the following that will match the remote control unit that you are using: * * hauppauge.toml The above works for several RC5 based Hauppauge remote control units. To prevent the Power button on the remote control unit from shutting down the entire system, add the following to the [Login] section of /etc/systemd/logind.conf: HandlePowerKey=ignore The default is HandlePowerKey=poweroff. Use mkfs.ext4 to replace the FAT file system of the only partition of the T7. There is no need to change the partitioning or specify a block size or alignment, because the physical block size is reported as 512 bytes. Optionally, you may set a label by executing something like this: tune2fs -L VDR /dev/sda1 You may create a mount point: sudo mkdir -m 000 /video Then, add a line like this to /etc/fstab to have the storage mounted automatically: LABEL=VDR /video ext4 defaults,noatime,nofail 0 1 You may replace the LABEL=VDR with whatever symbolic link you have in /dev/disk/by-label (see also tune2fs above). On my system, I actually wrote PARTUUID=33d32895-01 because there is a symbolic link /dev/disk/by-partuuid/33d32895-01 that identifies the partition. Once the storage is mounted, execute the following: sudo mkdir /video/video sudo chown pi:pi /video/video The next step is to configure VDR to start up correctly. I have some configuration files in /var/lib/vdr. For testing, I used to start VDR manually from the command line, and shut it down by choosing "restart" from the OSD menu. Now I want it to restart automatically, but only if suitable USB storage has been plugged in: sudo tee /etc/systemd/system/vdr.service << EOF [Unit] After=systemd-user-sessions.service plymouth-quit-wait.service After=rc-local.service After=getty(a)tty1.service After=video.mount Conflicts=getty(a)tty1.service ConditionPathExists=/video/video [Service] User=pi ExecStart=/usr/local/bin/vdr --no-kbd --lirc=/dev/lirc0 -Prpihddevice -v /video/video -s /var/lib/vdr/vdr-shutdown.sh TimeoutStartSec=infinity Type=idle Restart=on-failure RestartSec=1s TTYVTDisallocate=yes [Install] Alias=display-manager.service EOF This will replace the getty process on virtual terminal 1 (tty1). If the storage is not plugged within 90 seconds from startup (I do not know how to configure that timeout), then an error message will appear on the console. No getty will be started on tty1 in any case; you can always log in from tty2 by pressing Alt+F2. The shutdown script /var/lib/vdr/vdr-shutdown.sh does not work as intended yet: #!/bin/sh if [ "$5" = 1 ] then sudo service vdr stop sudo umount /video sudo udisksctl power-off -b /dev/sda fi The first step appears to terminate the shell script, because the shell is a subprocess of VDR. So, the storage will remain mounted and powered on. I guess that we need to launch a separate "vdr-shutdown" service that would take care of the remaining steps. Has someone already implemented something like this? After the "umount" and "udisksctl" commands are executed, it is safe to unplug the storage. The LED of the SSD will shortly change color and then turn off during the execution of the "udisksctl" command. What I am also missing is a udev rule that would automatically mount the storage and attempt to start up VDR as soon as the storage is plugged in. Currently, I have to manually execute the following if I plug in the drive to an already running system: sudo mount /video sudo service vdr start This configuration provides a rather simple user interface for VDR. No keyboard or mouse is needed, just the remote control unit, a display, and optionally the USB cable, if the system has other uses that are independent of VDR. For timed recordings, I think that on the Raspberry Pi, it is easiest to let the VDR process run all the time. Starting up the Pi based on timer would require additional hardware. One thing that I'd like to improve in that regard is to let VDR shut down all tuners when the system is idle. This could be based on an inactivity timer or an explicit user action, such as pressing a button on the remote control. The video output would shut off, and the tuner would be powered off, except when needed for something (EPG scan, recording). As soon as a button is pressed on the remote control unit, the user interface would spring back to life. Happy holidays, Marko

3 8

[ANNOUNCE] VDR version 2.6.3 released
by Klaus Schmidinger 14 Dec '22

14 Dec '22

VDR version 2.6.3 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.3;sf=tbz2 This version fixes a few bugs that came up after the release of version 2.6.2. The changes since version 2.6.2: - Fixed a compiler warning. - Fixed generating the index file in the cutter (reported by Christoph Haubrich). - Fixed a faulty 'Timer still recording' query when canceling an editing job. - Added code for the 'qks' audio track (thanks to Johann Friedrichs). - Fixed a possible heap-use-after-free in cDvbTuner::Action() (reported by Marko Mäkelä). - Fixed initializing cDvbPlayerControl and cTransferControl (reported by Marko Mäkelä). - Now avoiding calling poll() in cSectionHandler::Action() if there are no filters (reported by Marko Mäkelä). - Now avoiding the memcpy() call in cGlyph::cGlyph() if the bitmap is empty (thanks to Marko Mäkelä). - Now avoiding unnecessary processing in cDvbSubtitleConverter::FinishPage() if there are no areas (thanks to Marko Mäkelä). - Avoiding a zero sized array in cDevice::GetDevice() (thanks to Marko Mäkelä). - Now checking the video directory after setting the user id. Homepage: http://www.tvdr.de Facebook: https://www.facebook.com/VideoDiskRecorder Have fun! Klaus

1 0

[PATCH] ThreadSanitizer warnings for cThread
by Marko Mäkelä 14 Dec '22

14 Dec '22

Because of the heap-use-after-free race condition that was rather easily reproducible with AddressSanitizer (-fsanitize=address), I thought that I should finally try to learn to use ThreadSanitizer (TSAN, -fsanitize=thread in GCC and clang). https://clang.llvm.org/docs/ThreadSanitizer.html Because VDR makes use of POSIX thread synchronization primitives, no additional instrumentation via <sanitizer/tsan_interface.h> should be necessary. Before C++11 defined a memory model for multi-threaded applications, semantics around shared data structures were rather unclear, and I would guess that most multi-threaded pre-C++11 code bases would trip ThreadSanitizer. Also, multi-threaded CPUs were rare in the early days, and the Total Store Order of the x86 is very forgiving, compared to the weak memory model of ARM (see https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html for some examples). To silence one prominent source of TSAN warnings in the cThread destructor, I applied the attached patch. It is not ideal, because std::atomic defaults to std::memory_order_seq_cst while std::memory_order_relaxed would likely suffice here. Even after applying the first patch, a simple test with no DVB receiver device and no valid data directory would still produce a couple of data race reports (see the end of this message). I recorded a trace of such a run with "rr record" (https://rr-project.org) and debugged it in "rr replay". Unsurprisingly, I did not find actual evidence of a race condition. Finally, I figured out what is causing the first report: cThread::description is not protected by cThread::mutex. Possibly, most cThread data members (including cThread::active) should be protected by cThread::mutex? With both attached patches applied, the report of the first race will disappear. The second race is apparently about some memory that is allocated inside opendir(). I did not figure it out yet. Related to this, cThread::Cancel() especially when invoked with WaitSeconds=-1 looks problematic to me, and I see that VDR is invoking pthread_detach() and never invoking pthread_join(). The second patch includes an attempt to clean this up as well. Both patches are just a proof of concept; I did not test them beyond the simple failing-to-start VDR run under TSAN. Unfortunately, TSAN is not available for my primary VDR hardware, running on 32-bit ARM. With best regards, Marko vdr: error while reading '/var/lib/vdr/sources.conf' vdr: error while reading '/var/lib/vdr/channels.conf' vdr: no primary device found - using first device! ================== WARNING: ThreadSanitizer: data race on vptr (ctor/dtor vs virtual call) (pid=96847) Write of size 8 at 0x7ffc7f773e60 by main thread: #0 cThread::~cThread() /dev/shm/vdr/thread.c:249 (vdr+0x1d72b8) #1 cEpgDataReader::~cEpgDataReader() /dev/shm/vdr/epg.h:236 (vdr+0xa956b) #2 main /dev/shm/vdr/vdr.c:731 (vdr+0xa956b) Previous read of size 8 at 0x7ffc7f773e60 by thread T2: #0 cThread::StartThread(cThread*) /dev/shm/vdr/thread.c:293 (vdr+0x1d76d9) Location is stack of main thread. Location is global '<null>' at 0x000000000000 ([stack]+0x1fe60) Thread T2 'epg data reader' (tid=96855, finished) created by main thread at: #0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001 (libtsan.so.2+0x5e686) #1 cThread::Start() /dev/shm/vdr/thread.c:316 (vdr+0x1d6fe0) #2 main /dev/shm/vdr/vdr.c:804 (vdr+0xaa477) SUMMARY: ThreadSanitizer: data race on vptr (ctor/dtor vs virtual call) /dev/shm/vdr/thread.c:249 in cThread::~cThread() ================== ================== WARNING: ThreadSanitizer: data race (pid=96847) Write of size 8 at 0x7b04000005a0 by main thread: #0 free ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:706 (libtsan.so.2+0x47e82) #1 cString::~cString() /dev/shm/vdr/tools.c:1097 (vdr+0x1e52df) #2 cxa_at_exit_wrapper ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:389 (libtsan.so.2+0x2dee3) Previous read of size 8 at 0x7b04000005a0 by thread T1: #0 opendir ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3271 (libtsan.so.2+0x4c641) #1 cReadDir::cReadDir(char const*) /dev/shm/vdr/tools.c:1553 (vdr+0x1ea8bd) #2 cVideoDirectoryScannerThread::ScanVideoDir(char const*, int, int) /dev/shm/vdr/recording.c:1439 (vdr+0x180620) #3 cVideoDirectoryScannerThread::Action() /dev/shm/vdr/recording.c:1433 (vdr+0x180bfc) #4 cThread::StartThread(cThread*) /dev/shm/vdr/thread.c:293 (vdr+0x1d76ea) Thread T1 'video directory' (tid=96854, running) created by main thread at: #0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001 (libtsan.so.2+0x5e686) #1 cThread::Start() /dev/shm/vdr/thread.c:316 (vdr+0x1d6fe0) #2 cRecordings::Update(bool) /dev/shm/vdr/recording.c:1554 (vdr+0x175387) #3 main /dev/shm/vdr/vdr.c:788 (vdr+0xaa3f8) SUMMARY: ThreadSanitizer: data race /dev/shm/vdr/tools.c:1097 in cString::~cString() ================== ThreadSanitizer: reported 2 warnings

2 4

[PATCH] Fix undefined behaviour
by Marko Mäkelä 06 Dec '22

06 Dec '22

Another day, another sanitizer. After fixing issues reported by -fsanitize=address yesterday, I gave -fsanitize=undefined a try. The GCC documentation points to the clang documentation: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html The issues related to cControl::player were tricky. In the end, I figured it out after setting UBSAN_OPTIONS=print_stacktrace=1 and setting a breakpoint on _Unwind_Backtrace(). The name of the reporting function in my system was __ubsan_handle_dynamic_type_cache_miss(), nothing about "vptr". Also, the diagnostics was misleadingly pointing to the body of the constructor, and not the initializer list where a data member was being assigned to before the base class had been initialized. The -fsanitize=undefined in clang might report more things. Next I may give -fsanitize=thread a try. GCC does not implement -fsanitize=memory (checking for the use of uninitialized memory) at all. It will require clang and libc++ (not libstdc++) and that all libraries except libc are built with -fsanitize=memory. If you are familiar with Valgrind's default memcheck tool, it is roughly comparable to the combination of -fsanitize=address and -fsanitize=memory. Marko

3 9

[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. - 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!

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-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

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 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

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

← Newer
1
2
3
4
5
6
7
...
675
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr