vdr

vdr@linuxtv.org

3 participants
6747 discussions

Wake-on-timer rtcwake experiments on various PC hardware
by Marko Mäkelä 18 Apr '23

18 Apr '23

Today, I tested rtcwake on several x86 or x86-64 based computers. The outcome: (1) Suspend to RAM (say, "rtcwake -m mem -s 10"): * Success: Every system. (2) Wake-on-timer ("rtcwake -m no -s 120 && shutdown -h now" or "rtcwake -m off -s 120"): * Success: Lenovo Thinkpad X220 (2012?), and a 5-year-old desktop system * Fail: IBM Thinkpad X60 (Core Duo from 2006), a HP Zbook from 2016. (3) Suspend to disk ("rtcwake -m disk -s 120") had no chance of working, because I never configure … [View More]

3 5

Integartion with systemd and rtcwake
by Marko Mäkelä 15 Apr '23

15 Apr '23

Some time ago, I created the wiki page https://www.linuxtv.org/vdrwiki/index.php/Systemd that describes much of my VDR installation. On my Raspberry Pi, there is no real-time-clock. My low-tech solution for waking up VDR for recordings is that I set an alarm on my phone, to remind me to turn on VDR when needed. Today, I refined that a little by implementing an idle timeout shutdown when no further recording timers exist, or when they are in the distant enough future. I learned that … [View More]

4 9

Trying to run satip w/ Geniatech EyeTV Netstream 4Sat
by Harald Milz 30 Mar '23

30 Mar '23

Hi all, I'm trying to consolidate my stuff a bit and got a 4Sat these days. I'm trying to run VDR-2.6.0 with the satip plugin connecting to the Satip device. 4 receivers, 2x S19.2E, 2x S13.0E. So far, the LNB ran on a DD Cine PCI-E card just fine. (but I want to get rid of the server). (Tuner #4 is a Fritzbox cable receiver). Initially, all seems to look good: Mar 29 15:20:55 seneca vdr: [4921] initializing plugin: satip (2.4.1): SAT>IP Geräte Mar 29 15:20:55 seneca vdr: [4924] SATIP … [View More]poller thread started (pid=4921, tid=4924, prio=high) Mar 29 15:20:55 seneca vdr: [4921] cTimeMs: using monotonic clock (resolution is 1 ns) Mar 29 15:20:55 seneca vdr: [4921] new device number 1 (card index 1) Mar 29 15:20:55 seneca vdr: [4925] SATIP discover thread started (pid=4921, tid=4925, prio=high) Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=0 DeviceNumber=0 [device 0] Mar 29 15:20:55 seneca vdr: [4927] SATIP#0 section handler thread started (pid=4921, tid=4927, prio=high) Mar 29 15:20:55 seneca vdr: [4921] new device number 2 (card index 2) Mar 29 15:20:55 seneca vdr: [4928] device 1 section handler thread started (pid=4921, tid=4928, prio=low) Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=1 DeviceNumber=1 [device 1] Mar 29 15:20:55 seneca vdr: [4929] SATIP#1 tuner thread started (pid=4921, tid=4929, prio=high) Mar 29 15:20:55 seneca vdr: [4930] SATIP#1 section handler thread started (pid=4921, tid=4930, prio=high) Mar 29 15:20:55 seneca vdr: [4926] SATIP#0 tuner thread started (pid=4921, tid=4926, prio=high) Mar 29 15:20:55 seneca vdr: [4931] device 2 section handler thread started (pid=4921, tid=4931, prio=low) Mar 29 15:20:55 seneca vdr: [4921] new device number 3 (card index 3) Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=2 DeviceNumber=2 [device 2] Mar 29 15:20:55 seneca vdr: [4932] SATIP#2 tuner thread started (pid=4921, tid=4932, prio=high) Mar 29 15:20:55 seneca vdr: [4921] new device number 4 (card index 4) Mar 29 15:20:55 seneca vdr: [4934] device 3 section handler thread started (pid=4921, tid=4934, prio=low) Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=3 DeviceNumber=3 [device 3] Mar 29 15:20:55 seneca vdr: [4935] SATIP#3 tuner thread started (pid=4921, tid=4935, prio=high) Mar 29 15:20:55 seneca vdr: [4936] SATIP#3 section handler thread started (pid=4921, tid=4936, prio=high) Mar 29 15:20:55 seneca vdr: [4937] device 4 section handler thread started (pid=4921, tid=4937, prio=low) Mar 29 15:20:55 seneca vdr: [4921] new device number 5 (card index 5) Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=4 DeviceNumber=4 [device 4] Mar 29 15:20:55 seneca vdr: [4938] SATIP#4 tuner thread started (pid=4921, tid=4938, prio=high) Mar 29 15:20:55 seneca vdr: [4939] SATIP#4 section handler thread started (pid=4921, tid=4939, prio=high) ... Mar 29 15:20:56 seneca vdr: [4921] switching to channel 1 S19.2E-1-1107-17503 (WELT) Mar 29 15:20:58 seneca vdr: [4957] device 1 receiver thread started (pid=4921, tid=4957, prio=high) ... Mar 29 15:21:01 seneca vdr: [4928] creating new channel 'SAT.1,;ProSiebenSat.1' on S19.2E transponder 112544 with id 1-1107-17500-0 Mar 29 15:21:01 seneca vdr: [4928] creating new channel 'ProSieben,;ProSiebenSat.1' on S19.2E transponder 112544 with id 1-1107-17501-0 Mar 29 15:21:01 seneca vdr: [4928] creating new channel 'kabel eins,;ProSiebenSat.1' on S19.2E transponder 112544 with id 1-1107-17502-0 Mar 29 15:21:01 seneca vdr: [4928] creating new channel 'SAT.1 Gold,;ProSiebenSat.1' on S19.2E transponder 112544 with id 1-1107-17504-0 ... (plus a handful more) but a minute later, Mar 29 15:21:59 seneca vdr: [4929] curl_easy_perform() [rtsp.c,369] failed: Timeout was reached (28) Mar 29 15:21:59 seneca vdr: [4929] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.20.7/ [device 1] Mar 29 15:21:59 seneca vdr: [4929] SATIP-ERROR: Pid update failed - retuning [device 1] Mar 29 15:21:59 seneca vdr: [4932] curl_easy_perform() [rtsp.c,340] failed: Timeout was reached (28) Mar 29 15:21:59 seneca vdr: [4932] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.20.7/ [device 2] Mar 29 15:21:59 seneca vdr: [4935] curl_easy_perform() [rtsp.c,244] failed: Timeout was reached (28) Mar 29 15:21:59 seneca vdr: [4935] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.20.7/ [device 3] Mar 29 15:21:59 seneca vdr: [4935] SATIP-ERROR: Connect failed [device 3] ... and Mar 29 15:22:03 seneca vdr: [4935] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.20.7/ [device 3] Mar 29 15:22:03 seneca vdr: [4935] SATIP-ERROR: Connect failed [device 3] Mar 29 15:22:04 seneca vdr: [4929] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.20.7/ [device 1] Mar 29 15:22:04 seneca vdr: [4929] SATIP-ERROR: Connect failed [device 1] etc. etc. endlessly, and with netstat I see a lot of attempted rtsp connects: tcp 0 0 192.168.20.1:42764 192.168.20.7:554 ESTABLISHED 5219/vdr tcp 0 0 192.168.20.1:53584 192.168.20.7:554 TIME_WAIT - What might be wrong? Any experience that you can share? Should I return this device because it is known not to work with the satip plugin? (Not that I didn't google this before, to no avail.) I would have preferred an Octopus Net S2, but these devices were withdrawn and are hard to find. TIA! Cheers, hm -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain [View Less]

2 2

[PATCH] Add thread safety to cRingBufferLinear
by Patrick Lerda 25 Feb '23

25 Feb '23

Beside preventing crashes with vdr-2.6.3 this is required to get vdr to work properly with the gcc thread sanitizer. --- ringbuffer.c | 18 +++++++++++++++++- ringbuffer.h | 3 +++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/ringbuffer.c b/ringbuffer.c index 902c887..1c24df2 100644 --- a/ringbuffer.c +++ b/ringbuffer.c @@ -210,12 +210,16 @@ int cRingBufferLinear::DataReady(const uchar *Data, int Count) int cRingBufferLinear::Available(void) { + Lock(); int diff = … [View More]head - tail; - return (diff >= 0) ? diff : Size() + diff - margin; + int available = (diff >= 0) ? diff : Size() + diff - margin; + Unlock(); + return available; } void cRingBufferLinear::Clear(void) { + Lock(); int Head = head; tail = Head; #ifdef DEBUGRINGBUFFERS @@ -224,11 +228,13 @@ void cRingBufferLinear::Clear(void) lastPut = lastGet = -1; #endif maxFill = 0; + Unlock(); EnablePut(); } int cRingBufferLinear::Read(int FileHandle, int Max) { + Lock(); int Tail = tail; int diff = Tail - head; int free = (diff > 0) ? diff - 1 : Size() - head; @@ -259,6 +265,7 @@ int cRingBufferLinear::Read(int FileHandle, int Max) lastHead = head; lastPut = Count; #endif + Unlock(); EnableGet(); if (free == 0) WaitForPut(); @@ -267,6 +274,7 @@ int cRingBufferLinear::Read(int FileHandle, int Max) int cRingBufferLinear::Read(cUnbufferedFile *File, int Max) { + Lock(); int Tail = tail; int diff = Tail - head; int free = (diff > 0) ? diff - 1 : Size() - head; @@ -297,6 +305,7 @@ int cRingBufferLinear::Read(cUnbufferedFile *File, int Max) lastHead = head; lastPut = Count; #endif + Unlock(); EnableGet(); if (free == 0) WaitForPut(); @@ -306,6 +315,7 @@ int cRingBufferLinear::Read(cUnbufferedFile *File, int Max) int cRingBufferLinear::Put(const uchar *Data, int Count) { if (Count > 0) { + Lock(); int Tail = tail; int rest = Size() - head; int diff = Tail - head; @@ -336,6 +346,7 @@ int cRingBufferLinear::Put(const uchar *Data, int Count) lastHead = head; lastPut = Count; #endif + Unlock(); EnableGet(); if (Count == 0) WaitForPut(); @@ -345,6 +356,7 @@ int cRingBufferLinear::Put(const uchar *Data, int Count) uchar *cRingBufferLinear::Get(int &Count) { + Lock(); int Head = head; if (getThreadTid <= 0) getThreadTid = cThread::ThreadId(); @@ -362,14 +374,17 @@ uchar *cRingBufferLinear::Get(int &Count) uchar *p = buffer + tail; if ((cont = DataReady(p, cont)) > 0) { Count = gotten = cont; + Unlock(); return p; } + Unlock(); WaitForGet(); return NULL; } void cRingBufferLinear::Del(int Count) { + Lock(); if (Count > gotten) { esyslog("ERROR: invalid Count in cRingBufferLinear::Del: %d (limited to %d)", Count, gotten); Count = gotten; @@ -387,6 +402,7 @@ void cRingBufferLinear::Del(int Count) lastTail = tail; lastGet = Count; #endif + Unlock(); } // --- cFrame ---------------------------------------------------------------- diff --git a/ringbuffer.h b/ringbuffer.h index 746fc51..cbaa12c 100644 --- a/ringbuffer.h +++ b/ringbuffer.h @@ -58,10 +58,13 @@ public: static void PrintDebugRBL(void); #endif private: + cMutex mutex; int margin, head, tail; int gotten; uchar *buffer; char *description; + void Lock(void) { mutex.Lock(); } + void Unlock(void) { mutex.Unlock(); } protected: virtual int DataReady(const uchar *Data, int Count); ///< By default a ring buffer has data ready as soon as there are at least -- 2.39.1 [View Less]

5 12

[PATCH] Fix cThread related race conditions
by Patrick Lerda 19 Feb '23

19 Feb '23

This change fixes the following issue: ==15457==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000002d0 (pc 0x7fd2f4301710 bp 0x7fd2b5552a30 sp 0x7fd2b5552988 T228) ==15457==The signal is caused by a READ memory access. ==15457==Hint: address points to the zero page. #0 0x7fd2f4301710 in pthread_detach (/lib64/libc.so.6+0x8b710) #1 0xdb4430 in cThread::Start() vdr-2.6.3/thread.c:317 #2 0x7fd2e5ea8fc4 in cIptvStreamer::Open() vdr-2.6.3/PLUGINS/src/iptv/streamer.c:66 #3 … [View More]0x7fd2e5e1e8c2 in cIptvDevice::OpenDvr() vdr-2.6.3/PLUGINS/src/iptv/device.c:342 #4 0x634903 in cDevice::Action() vdr-2.6.3/device.c:1714 #5 0xdb644a in cThread::StartThread(cThread*) vdr-2.6.3/thread.c:293 #6 0x7fd2f4300729 (/lib64/libc.so.6+0x8a729) #7 0x7fd2f437d0bb (/lib64/libc.so.6+0x1070bb) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x8b710) in pthread_detach Thread T228 (device 5 receiv) created by T222 (cLiveStreamer s) here: #0 0x7fd2f52d4716 in pthread_create (/usr/lib64/libasan.so.6+0x59716) #1 0xdb437b in cThread::Start() vdr-2.6.3/thread.c:316 #2 0x63a3ad in cDevice::AttachReceiver(cReceiver*) vdr-2.6.3/device.c:1844 #3 0x7fd2e8162c56 in cDummyReceiver::Create(cDevice*) vdr-2.6.3/PLUGINS/src/vnsiserver/videoinput.c:472 #4 0x7fd2e816dbc2 in cVideoInput::Open(cChannel const*, int, cVideoBuffer*) vdr-2.6.3/PLUGINS/src/vnsiserver/videoinput.c:530 #5 0x7fd2e80d78d3 in cLiveStreamer::Action() vdr-2.6.3/PLUGINS/src/vnsiserver/streamer.c:318 #6 0xdb644a in cThread::StartThread(cThread*) vdr-2.6.3/thread.c:293 #7 0x7fd2f4300729 (/lib64/libc.so.6+0x8a729) --- thread.c | 25 +++++++++++++++---------- thread.h | 11 +++++++---- 2 files changed, 22 insertions(+), 14 deletions(-) diff --git a/thread.c b/thread.c index 93eb8c0..21be7a4 100644 --- a/thread.c +++ b/thread.c @@ -312,13 +312,16 @@ bool cThread::Start(void) cCondWait::SleepMs(THREAD_STOP_SLEEP); } if (!active) { - active = running = true; - if (pthread_create(&childTid, NULL, (void *(*) (void *))&StartThread, (void *)this) == 0) { - pthread_detach(childTid); // auto-reap + pthread_t localTid; + running = true; + if (pthread_create(&localTid, NULL, (void *(*) (void *))&StartThread, (void *)this) == 0) { + pthread_detach(localTid); // auto-reap + childTid = localTid; + active = true; } else { LOG_ERROR; - active = running = false; + running = false; return false; } } @@ -339,11 +342,12 @@ bool cThread::Active(void) // performed but no signal is actually sent. // int err; - if ((err = pthread_kill(childTid, 0)) != 0) { + const pthread_t localTid = childTid; + if ((err = pthread_kill(localTid, 0)) != 0) { if (err != ESRCH) LOG_ERROR; - childTid = 0; - active = running = false; + if (active && childTid == localTid) + active = running = false; } else return true; @@ -355,6 +359,7 @@ void cThread::Cancel(int WaitSeconds) { running = false; if (active && WaitSeconds > -1) { + const pthread_t localTid = childTid; if (WaitSeconds > 0) { for (time_t t0 = time(NULL) + WaitSeconds; time(NULL) < t0; ) { if (!Active()) @@ -363,9 +368,9 @@ void cThread::Cancel(int WaitSeconds) } esyslog("ERROR: %s thread %d won't end (waited %d seconds) - canceling it...", description ? description : "", childThreadId, WaitSeconds); } - pthread_cancel(childTid); - childTid = 0; - active = false; + pthread_cancel(localTid); + if (active && childTid == localTid) + active = false; } } diff --git a/thread.h b/thread.h index 16c4bd7..06046ea 100644 --- a/thread.h +++ b/thread.h @@ -13,6 +13,7 @@ #include <pthread.h> #include <stdio.h> #include <sys/types.h> +#include <atomic> typedef pid_t tThreadId; @@ -56,7 +57,7 @@ class cRwLock { private: pthread_rwlock_t rwlock; int locked; - tThreadId writeLockThreadId; + std::atomic<tThreadId> writeLockThreadId; public: cRwLock(bool PreferWriter = false); ~cRwLock(); @@ -79,9 +80,11 @@ public: class cThread { friend class cThreadLock; private: - bool active; - bool running; - pthread_t childTid; + std::atomic_bool active; + std::atomic_bool running; + std::atomic<pthread_t> childTid; + ///< Assume that the content of childTid is valid when the class member + ///< active is set to true and undefined otherwise. tThreadId childThreadId; cMutex mutex; char *description; -- 2.39.1 [View Less]

3 4

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

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

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

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

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

2 4

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr