[vdr] [ANNOUNCE] VDR version 2.6.7 released
VDR version 2.6.7 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.7;sf=tbz2 The changes since version 2.6.6: - Fixed the move assignment operator to check for self-assignment (suggested by Stefan Herdler). - Added missing initialization of cChannel::nameSourceMode (thanks to Winfried Köhler). - Modified handling channel names with source to make it thread safe (thanks to Stefan Herdler). - Adapted "Setup/Miscellaneous/Show channel names with source" to the new handling in cChannel. - Added a 15 second grace period before actually stopping a VPS timer (thanks to Markus Ehrnsperger). - The primary device no longer starts unnecessary threads if it doesn't have a decoder (thanks to Markus Ehrnsperger). - The info file of a recording is now re-read if an update of the video directory is triggered, to make sure modifications from other VDRs are adopted. - Updated the Hungarian OSD texts (thanks to István Füley). - The new setup parameters "EPG scan max. channel number" and "EPG pause after scan" can be used to tune the behavior of the EPG scan (see MANUAL for details). - Improved handling present/following data for VPS timers (thanks to Markus Ehrnsperger). - Logging event status changes now also shows the previous status (thanks to Markus Ehrnsperger). - Fixed logging when a timer has entered the VPS margin. - The EIT scan no longer deletes the scanList if no device was switched in this pass. - The EIT scan now skips scanList entries if a device is already tuned to that transponder. - The EIT scan is no longer inhibited if a timer is in VPS margin or needs the transponder. - If the current channel is no longer available because of a VPS timer entering the VPS margin, live view now switches to the channel of that timer. - A device is now always kept occupied if a timer is in VPS margin or needs the transponder (thanks to Markus Ehrnsperger). Homepage: http://www.tvdr.de Facebook: https://www.facebook.com/VideoDiskRecorder Have fun! Klaus
[vdr] [ANNOUNCE] VDR version 2.6.6 released
VDR version 2.6.6 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.6;sf=tbz2 The changes since version 2.6.5: - Changed installing config files to handle potentially broken 'cp -n'. - Fixed height calculation in progress display (thanks to Matthias Senzel). - Fixed a possible crash in cDevice::StopSectionHandler() (thanks to Markus Ehrnsperger). - Using a dummy OSD if no OSD provider is available is not considered an error any more (thanks to Markus Ehrnsperger). - Implemented scaling images (thanks to Andreas Baierl). - Removed syslog calls in child process after fork() (thanks to Markus Ehrnsperger). - Fixed an unnecessary double display of the current menu item in page up/down (thanks to Matthias Senzel). - Fixed an unnecessary double display of menu items in the Recordings menu (thanks to Matthias Senzel). - Added the move constructor to cString for better performance (thanks to Markus Ehrnsperger). - Added the total number of errors when logging new recording errors. - Added '/' to the list of fuzzy characters for pattern timers. - Fixed handling primary device on headless systems (thanks to Markus Ehrnsperger). - Workaround in detecting frame height for channels with wrong crop parameters (thanks to Christoph Haubrich). - Fixed possible duplicate component entries in the info of an ongoing recording (reported by Christoph Haubrich). Homepage: http://www.tvdr.de Facebook: https://www.facebook.com/VideoDiskRecorder Have fun! Klaus ___ vdr mailing list -- vdr@linuxtv.org To unsubscribe send an email to vdr-le...@linuxtv.org
[vdr] [ANNOUNCE] VDR version 2.6.5 released
VDR version 2.6.5 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.5;sf=tbz2 The changes since version 2.6.4: - Fixed broken video data streams on systems without output device when switching live channel to a different transponder while recording (reported by Markus Ehrnsperger). - The frame width, height, scan type and apect ratio of a recording are now stored in the 'info' file under the 'F' tag (thanks to Christoph Haubrich). - Added the function cRecordingInfo::FrameParams(), which can be used to get a nicely formatted string with all the available frame data. - The recording info of the default skins now shows the frame parameters of the recording at the end of the description (if such information is available). Homepage: http://www.tvdr.de Facebook: https://www.facebook.com/VideoDiskRecorder Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Add thread safety to cRingBufferLinear
On 19.02.23 18:29, Patrick Lerda wrote: ... I had definitively a few crashes related to this class. Thread safety issues are often not easily reproducible. Is your environment 100% reliable? My VDR runs for weeks, even months 24/7 without problems. I only restart it when I have a new version. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 2.6.4 released
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 ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Use cThread::mutex with absolute cCondVar::TimedWait()
On 22.01.23 13:52, Marko Mäkelä wrote:
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;
I don't like the idea of exposing that mutex.
If you really need such functionality, please suggest a function that does this
without
exposing the mutex.
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(, NULL) == 0) { // get current time
What is the rationale behind this change, other than having to call it with
cCondVar::GetAbsTime()?
@@ -81,7 +81,7 @@ bool cCondWait::Wait(int TimeoutMs)
if (!signaled) {
if (TimeoutMs) {
struct timespec abstime;
- if (GetAbsTime(, TimeoutMs)) {
+ if (cCondVar::GetAbsTime(, TimeoutMs)) {
while (!signaled) {
if (pthread_cond_timedwait(, , ) ==
ETIMEDOUT)
break;
@@ -129,20 +129,27 @@ void cCondVar::Wait(cMutex )
}
}
+bool cCondVar::TimedWait(cMutex , const timespec )
+{
+ 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(, , );
+ Mutex.locked = locked;
+ }
+ return err != ETIMEDOUT;
+}
+
bool cCondVar::TimedWait(cMutex , int TimeoutMs)
{
bool r = true; // true = condition signaled, false = timeout
if (Mutex.locked) {
struct timespec abstime;
- if (GetAbsTime(, 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(, , ) == ETIMEDOUT)
- r = false;
- Mutex.locked = locked;
- }
+ if (GetAbsTime(, 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(, TimeoutMs))
+ if (!cCondVar::GetAbsTime(, 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 );
bool TimedWait(cMutex , int TimeoutMs);
+ bool TimedWait(cMutex , const timespec );
void Broadcast(void);
+ static bool GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow);
};
class cRwLock {
So where and how would you be using this new function?
I did not complete the change to rpihddevice cOmx::Action() yet. We may be
forced to retain two mutexes after all
You want to expose the cThread::mutex in order to avoid an additional mutex in
the derived class, but
may be forced to retain two
Re: [vdr] [PATCH] Fix cThread related race conditions
On 02.02.23 21:56, Patrick Lerda wrote:
...
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(, NULL, (void *(*) (void *)),
(void *)this) == 0) {
- pthread_detach(childTid); // auto-reap
+pthread_t localTid;
+running = true;
+if (pthread_create(, NULL, (void *(*) (void *)),
(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)
localTid was initialized to childTid 4 lines earlier, so what's with the "childTid
== localTid" check here? Isn't this always true?
+ 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)
Same here?
I see this happens with "address sanitizer". Is there an actual, reproducible,
real world problem that this patch fixes?
+ 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
#include
#include
+#include
typedef pid_t tThreadId;
@@ -56,7 +57,7 @@ class cRwLock {
private:
pthread_rwlock_t rwlock;
int locked;
- tThreadId writeLockThreadId;
+ std::atomic 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 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;
Are the "atomics" really necessary?
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Add thread safety to cRingBufferLinear
On 09.02.23 23:31, Patrick Lerda wrote: ... This is really related to the C++ thread safety model, the patch below fixes the main cRingBufferLinear issue: diff --git a/ringbuffer.h b/ringbuffer.h index 746fc51..a3fa499 100644 --- a/ringbuffer.h +++ b/ringbuffer.h @@ -10,6 +10,7 @@ #ifndef __RINGBUFFER_H #define __RINGBUFFER_H +#include #include "thread.h" #include "tools.h" @@ -58,7 +59,8 @@ public: static void PrintDebugRBL(void); #endif private: - int margin, head, tail; + int margin; + std::atomic_int head, tail; int gotten; uchar *buffer; char *description; Is there an actual, reproducable, real world problem that makes this necessary? I mean without any "thread sanitizer" etc. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Add thread safety to cRingBufferLinear
On 06.02.23 21:11, Patrick Lerda wrote: On 03/02/2023 10:36, Klaus Schmidinger wrote: On 02.02.23 23:47, patrick9...@free.fr wrote: On 02/02/2023 23:27, Klaus Schmidinger wrote: On 02.02.23 23:16, Patrick Lerda wrote: Beside preventing crashes with vdr-2.6.3 this is required to get vdr to work properly with the gcc thread sanitizer. cRingBufferLinear was designed to be thread safe without locking. What "crashes with vdr-2.6.3" are you referring to? Klaus With a -fsanitize=thread compiled version of vdr, I had some crashes that happened quickly, for instance: ... Before making such deep changes to code that has been running flawlessly for years (or even decades) I need to be convinced that this is absolutely necessary. Is there a problem that occurs if you run VDR *without* -fsanitize=thread? Klaus I had in the past a crash from time to time, with vdr-2.6.3 this seems to be worse. Anyway, I was checking with vdr-2.4.7 and the problem is the same. This class is shared by at least 2 threads It is supposed to be shared by *exactly* two threads. One only writing 'head', the other only writing 'tail'. The concept was taken from the original DVB driver, which also implemented the ring buffer without locking. with more than one shared object; this means that without a mutex, the behavior is undefined from a C++ perspective. With -fsanitize=thread the compiler could add some jitter and that seems to trigger quickly a crash. You should check in your environment with -fsanitize=thread, this is fastest way to check for thread safety. If there really were such a big problem, I would expect it would happen a lot more often. However, this is the first time I hear of a problem that might stem from the implmentation of the ring buffer. What exactly is it that you're doing that causes this? Does it also happen if you don't do that? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Add thread safety to cRingBufferLinear
On 02.02.23 23:47, patrick9...@free.fr wrote: On 02/02/2023 23:27, Klaus Schmidinger wrote: On 02.02.23 23:16, Patrick Lerda wrote: Beside preventing crashes with vdr-2.6.3 this is required to get vdr to work properly with the gcc thread sanitizer. cRingBufferLinear was designed to be thread safe without locking. What "crashes with vdr-2.6.3" are you referring to? Klaus With a -fsanitize=thread compiled version of vdr, I had some crashes that happened quickly, for instance: ... Before making such deep changes to code that has been running flawlessly for years (or even decades) I need to be convinced that this is absolutely necessary. Is there a problem that occurs if you run VDR *without* -fsanitize=thread? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Add thread safety to cRingBufferLinear
On 02.02.23 23:16, Patrick Lerda wrote: Beside preventing crashes with vdr-2.6.3 this is required to get vdr to work properly with the gcc thread sanitizer. cRingBufferLinear was designed to be thread safe without locking. What "crashes with vdr-2.6.3" are you referring to? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 2.6.3 released
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 ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] ThreadSanitizer warnings for cThread
On 10.12.22 18:30, Marko Mäkelä wrote: ... 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? Unless I'm missing something, cThread::description is never accessed while the thread is actually running, locking isn't necessary here. ... 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. Is there an actual problem that requires this? It has been that way for many, many years, so I'd like to see more than "looks problematic to me" before I dare touch this ;-). Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Fix undefined behaviour
On 06.12.22 14:25, Marko Mäkelä wrote:
...
Maybe the simplest way to silence the warning would be to bloat the
variable-length array with 1 extra element, wasting sizeof(int) bytes of stack
space:
int SlotPriority[NumCamSlots + 1];
OK, so this is it:
--- device.c2022/01/24 16:53:45 5.5
+++ device.c2022/12/06 17:01:41
@@ -249,7 +249,7 @@
{
// Collect the current priorities of all CAM slots that can decrypt the
channel:
int NumCamSlots = CamSlots.Count();
- int SlotPriority[NumCamSlots];
+ int SlotPriority[NumCamSlots + 1]; // +1 to keep the compiler from doing crazy
"optimizations" if NumCamSlots==0
int NumUsableSlots = 0;
bool InternalCamNeeded = false;
if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Fix undefined behaviour
On 06.12.22 12:24, Marko Mäkelä wrote:
...
diff --git a/dvbsubtitle.c b/dvbsubtitle.c
index c1dfef4d..2d22d963 100644
--- a/dvbsubtitle.c
+++ b/dvbsubtitle.c
@@ -1770,6 +1770,8 @@ void cDvbSubtitleConverter::FinishPage(cDvbSubtitlePage
*Page)
return;
int NumAreas;
tArea *Areas = Page->GetAreas(NumAreas);
+ if (!Areas)
+ return;
tArea AreaCombined = Page->CombineAreas(NumAreas, Areas);
tArea AreaOsd = Page->ScaleArea(AreaCombined, osdFactorX, osdFactorY);
int Bpp = 8;
OK, let's settle for this (if there are no areas, the check for 'NumAreas > 0'
is obsolete):
--- dvbsubtitle.c 2021/03/17 15:24:34 5.1
+++ dvbsubtitle.c 2022/12/06 16:44:02
@@ -1770,11 +1770,13 @@
return;
int NumAreas;
tArea *Areas = Page->GetAreas(NumAreas);
+ if (!Areas)
+ return;
tArea AreaCombined = Page->CombineAreas(NumAreas, Areas);
tArea AreaOsd = Page->ScaleArea(AreaCombined, osdFactorX, osdFactorY);
int Bpp = 8;
bool Reduced = false;
- if (osd && NumAreas > 0) {
+ if (osd) {
while (osd->CanHandleAreas(, 1) != oeOk) {
dbgoutput("CanHandleAreas: %d\n", osd->CanHandleAreas(,
1));
int HalfBpp = Bpp / 2;
... > @@ -74,7 +74,8 @@ cGlyph::cGlyph(uint CharCode, FT_GlyphSlotRec_
*GlyphData)
rows = GlyphData->bitmap.rows;
pitch = GlyphData->bitmap.pitch;
bitmap = MALLOC(uchar, rows * pitch);
- memcpy(bitmap, GlyphData->bitmap.buffer, rows * pitch);
+ if (int bytes = rows * pitch)
+ memcpy(bitmap, GlyphData->bitmap.buffer, bytes);
}
cGlyph::~cGlyph()
OK, 'man malloc' says "If size is 0, then malloc() returns either NULL, or a
unique pointer value that can later
be successfully passed to free()". Since memcpy() must not be called with a
NULL pointer, you win.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Fix undefined behaviour
On 05.12.22 16:54, Marko Mäkelä wrote:
Hi Klaus,
Mon, Dec 05, 2022 at 04:08:45PM +0100, Klaus Schmidinger wrote:
If NumCamSlots is 0, SlotPriority[] is never accessed.
So why allocate memory for it if it is never used?
Allocating a variable-length array of length 0 is undefined behaviour. The
compiler is allowed to assume NumCamSlots>0 and optimize something based on
that assumption.
In cDevice::GetDevice() SlotPriority[] is never touched if NumCamSlots is 0.
So the compiler may assume whatever it wants in that case, it won't matter.
Or can you show a case where it actually misbehaves?
You are right, it would be better to treat NumCamSlots==0 as a special case. I only tried
adding a "return NULL", which resulted in an error message that a channel is
unavailable, for a free-to-view channel.
Doing this would never select a device for FTA channels.
...
Related question: Do we need to duplicate cControl::player in
cDvbPlayerControl::player? Perhaps there could be a member function that
returns the protected data member of the base class:
class cDvbPlayerControl {
...
private:
cDvbPlayer *GetPlayer() const { return static_cast(player); }
...
};
cDvbPlayerControl is the class that creates and deletes the player.
cControl is only given the player to control it in an abstract manner.
If (rows * pitch) is 0, nothing is copied.
Why the extra check?
Because invoking memcpy() with null pointers is undefined behaviour, the
compiler is allowed to assume that both pointers are nonnull, and allowed to
optimize subsequent checks based on that assumption. Because this member
function is inlined, the assumption could propagate to lots of other code.
Basically, for code like this:
void copy_and_set(char *a, const char *b, size_t size)
{
memcpy(a, b, size);
if (a)
*a = 1;
}
the compiler is allowed to optimize away the "if (a)" check.
Some years ago, I witnessed this in another codebase, when it was compiled with
a new enough GCC and -O2. It was quite a head-scratcher, because the memcpy()
or memset() call was located far away from the place where the surprising
optimization took place.
Well, IMHO whoever implemented such an "optimization" should be banned from
programming for life!
This is not an optimization, it's an insidious TRAP!
The man page on memcpy() doesn't say that the size can't be 0.
...
If NumFilters is 0, pfd[] is never accessed.
So why allocate memory for it if it is never used?
Could "if (NumFilters == 0)" be added to skip the allocation and the subsequent code? On
a quick read of "man 2 poll", I did not find any mention on what it should do if the
array is empty, nor did I check what it would actually do: Wait for the timeout, or return
immediately?
Sorry, my bad. I missed that pfd is passed to poll()
Please try this:
--- ./sections.c2022/01/31 21:21:42 5.3
+++ ./sections.c2022/12/05 22:46:24
@@ -180,6 +180,11 @@
startFilters = false;
}
int NumFilters = filterHandles.Count();
+if (NumFilters == 0) {
+ Unlock();
+ cCondWait::SleepMs(100);
+ continue;
+ }
pollfd pfd[NumFilters];
for (cFilterHandle *fh = filterHandles.First(); fh; fh =
filterHandles.Next(fh)) {
int i = fh->Index();
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Fix undefined behaviour
On 04.12.22 13:19, Marko Mäkelä wrote:
...
0001-Fix-GCC-8.3.0-fsanitize-undefined.patch
From b69ff7105d4bb8d933f0214f34b103fda8e8b155 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marko=20M=C3=A4kel=C3=A4?=
Date: Sun, 4 Dec 2022 13:42:57 +0200
Subject: [PATCH] Fix GCC 8.3.0 -fsanitize=undefined
...
device.c:251:31: runtime error: variable length array bound evaluates to
non-positive value 0
...
diff --git a/device.c b/device.c
index 4e987389..a770aa90 100644
--- a/device.c
+++ b/device.c
@@ -248,7 +248,7 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int
Priority, bool LiveView
{
// Collect the current priorities of all CAM slots that can decrypt the
channel:
int NumCamSlots = CamSlots.Count();
- int SlotPriority[NumCamSlots];
+ int SlotPriority[std::max(NumCamSlots, 1)];
int NumUsableSlots = 0;
bool InternalCamNeeded = false;
if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
If NumCamSlots is 0, SlotPriority[] is never accessed.
So why allocate memory for it if it is never used?
dvbplayer.c:984:11: runtime error: member access within address 0x02a388d0
which does not point to an object of type 'cDvbPlayerControl'
...
diff --git a/dvbplayer.c b/dvbplayer.c
index 2ee846b6..72bc46ad 100644
--- a/dvbplayer.c
+++ b/dvbplayer.c
@@ -981,8 +981,9 @@ bool cDvbPlayer::GetReplayMode(bool , bool , int
)
// --- cDvbPlayerControl -
cDvbPlayerControl::cDvbPlayerControl(const char *FileName, bool PauseLive)
-:cControl(player = new cDvbPlayer(FileName, PauseLive))
+:cControl(new cDvbPlayer(FileName, PauseLive))
{
+ player = static_cast(cControl::player);
}
cDvbPlayerControl::~cDvbPlayerControl()
...
transfer.c:71:11: runtime error: member access within address 0x020f0428 which
does not point to an object of type 'cTransferControl'
diff --git a/transfer.c b/transfer.c
index 88931e58..b888910a 100644
--- a/transfer.c
+++ b/transfer.c
@@ -68,8 +68,9 @@ void cTransfer::Receive(const uchar *Data, int Length)
cDevice *cTransferControl::receiverDevice = NULL;
cTransferControl::cTransferControl(cDevice *ReceiverDevice, const cChannel *Channel)
-:cControl(transfer = new cTransfer(Channel), true)
+:cControl(new cTransfer(Channel), true)
{
+ transfer = static_cast(player);
ReceiverDevice->AttachReceiver(transfer);
receiverDevice = ReceiverDevice;
}
Instead if typecasting I guess I'll rather do it this way:
--- ./dvbplayer.c 2022/01/13 21:41:41 5.1
+++ ./dvbplayer.c 2022/12/05 14:29:50
@@ -981,8 +981,10 @@
// --- cDvbPlayerControl -
cDvbPlayerControl::cDvbPlayerControl(const char *FileName, bool PauseLive)
-:cControl(player = new cDvbPlayer(FileName, PauseLive))
+:cControl(NULL, PauseLive)
{
+ player = new cDvbPlayer(FileName, PauseLive);
+ SetPlayer(player);
}
cDvbPlayerControl::~cDvbPlayerControl()
--- ./player.h 2020/05/18 16:47:29 5.0
+++ ./player.h 2022/12/05 14:30:24
@@ -107,6 +107,7 @@
///< Deletion of the marks themselves is handled separately, calling
///< this function merely tells the player to no longer display the
///< marks, if it has any.
+ void SetPlayer(cPlayer *Player) { player = Player; }
double FramesPerSecond(void) const { return player ?
player->FramesPerSecond() : DEFAULTFRAMESPERSECOND; }
bool GetIndex(int , int , bool SnapToIFrame = false) const {
return player ? player->GetIndex(Current, Total, SnapToIFrame) : false; }
bool GetFrameNumber(int , int ) const { return player ?
player->GetFrameNumber(Current, Total) : false; }
--- ./transfer.c2017/12/07 15:00:33 5.0
+++ ./transfer.c2022/12/05 14:36:39
@@ -68,8 +68,10 @@
cDevice *cTransferControl::receiverDevice = NULL;
cTransferControl::cTransferControl(cDevice *ReceiverDevice, const cChannel
*Channel)
-:cControl(transfer = new cTransfer(Channel), true)
+:cControl(NULL, true)
{
+ transfer = new cTransfer(Channel);
+ SetPlayer(transfer);
ReceiverDevice->AttachReceiver(transfer);
receiverDevice = ReceiverDevice;
}
diff --git a/font.c b/font.c
index 8b37798c..c78b1a15 100644
--- a/font.c
+++ b/font.c
@@ -74,7 +74,8 @@ cGlyph::cGlyph(uint CharCode, FT_GlyphSlotRec_ *GlyphData)
rows = GlyphData->bitmap.rows;
pitch = GlyphData->bitmap.pitch;
bitmap = MALLOC(uchar, rows * pitch);
- memcpy(bitmap, GlyphData->bitmap.buffer, rows * pitch);
+ if (int bytes = rows * pitch)
+memcpy(bitmap, GlyphData->bitmap.buffer, bytes);
}
cGlyph::~cGlyph()
If (rows * pitch) is 0, nothing is copied.
Why the extra check?
osd.h:301:37: runtime error: signed integer overflow: -2147483647 - 2147483647
cannot be represented in type 'int'
...
diff --git a/osd.h b/osd.h
index 77722662..7a293321 100644
--- a/osd.h
+++ b/osd.h
@@ -298,8 +298,8 @@ public:
struct tArea {
int x1, y1, x2, y2;
int bpp;
- int Width(void) const { return x2 - x1 + 1; }
- int Height(void) const
[vdr] [ANNOUNCE] VDR version 2.6.2 released
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! ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG table 0
I just dug up this old message.
@Richard: do you still have this problem?
If so, could you try VDR versions between 2.2.0 and 2.6.1 to narrow down when
the problem appeared?
Klaus
On 17.07.22 18:09, 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
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 ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Termination of ftp.tvdr.de
On 02.03.22 11:34, Narcis Garcia wrote: What is the total weight of published data there? (I'm thinking in deploying a mirror of this HTTP site) The total amount of data on ftp.tvdr.de is 221 MB. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Termination of ftp.tvdr.de
Since all versions of VDR are now available at git.tvdr.de, new versions will be distributed exclusively through the GIT, and FTP in general is considered "legacy" and frowned upon (Firefox, for instance, doesn't even support it any more), I intend to shut down ftp.tvdr.de. If you still need something from there, please download it now. If you are mirroring this server you may want to stop doing so, to prevent your local copy from disappearing when files vanish from the server. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 2.6.1 released
VDR version 2.6.1 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.1;sf=tbz2 This version fixes a few bugs that came up after the release of version 2.6.0. The changes since version 2.6.0: - Replaced strncpy() with memcpy() in strreplace() to avoid a compiler warning (reported by Marco Mäkelä). - Fixed starting replay after jumping to an editing mark. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Added some missing "AUTO" values to vdr.5 (thanks to Winfried Köhler). - Fixed handling zero bytes in cH264Parser (thanks to Christoph Haubrich). - Fixed handling error conditions in the index file (reported by Markus Ehrnsperger). - Fixed a possible deadlock in cDevice::DetachAllReceivers() (thanks to Helmut Binder). - Clarified some potentially mistakable code in cSectionHandler::SetStatus() (pointed out by Onur Sentürk). - Official release. Homepage: http://www.tvdr.de Facebook: https://www.facebook.com/VideoDiskRecorder Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 2.6.0 released
VDR version 2.6.0 is now available at the official VDR GIT archive git://git.tvdr.de You can get the latest stable version with git clone --branch stable/2.6 git://git.tvdr.de/vdr.git If you want to download the source as a tar archive, use http://git.tvdr.de/?p=vdr.git;a=snapshot;h=refs/tags/2.6.0;sf=tbz2 A summary of all the major changes since the last stable version can be found at http://www.tvdr.de/changelog.htm There is also a new version with important fixes in the stable/2.4 branch, for those who don't want to or can't switch to version 2.6 at this time: http://git.tvdr.de/?p=vdr.git;a=snapshot;h=refs/tags/2.4.8;sf=tbz2 When updating from an earlier version of VDR please make sure you read the INSTALL and MANUAL files that come with the VDR source _before_ doing so! Please make sure you have backup copies of all your configuration files, and verify carefully that your timers will be set to the correct channels after switching to this new version. Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR, and also to all users who just enjoy VDR! Please also visit the VDR homepage at http://www.tvdr.de and VDR's facebook page at https://www.facebook.com/VideoDiskRecorder Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 2.4.6 released
VDR version 2.4.6 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.4.6.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.4.4-2.4.6.diff MD5 checksums: aa91614159ae2db45655d35918e2c24e vdr-2.4.6.tar.bz2 b75cc737a5ea5fc059c2264b7ed21fa9 vdr-2.4.4-2.4.6.diff You can also get the latest stable version at the official VDR GIT archive with git clone --branch stable/2.4 git://git.tvdr.de/vdr.git This version fixes a few bugs that came up after the release of version 2.4.4. The changes since version 2.4.4: - Updated the Italian OSD texts (thanks to Diego Pierotto). - Fixed handling newline characters in ci.c's CopyString() (reported by Winfried Köhler). - Fixed checking the return value of the Open() call in cFileName::SetOffset() (reported by Winfried Köhler). - Fixed a possible invalid lock sequence in cMenuTimers::OnOff(). - Fixed several typos (reported by Jens Schleusener). - Implemented anti-aliasing for cPixmap::DrawSlope() and cPixmap::DrawEllipse() (thanks to Christoph Haubrich). The version numbers (both VDRVERSNUM and APIVERSNUM) have been bumped to 2.4.5 to indicate this change. - Fixed alignment of semi-circles in case of odd sizes. - Increased the size of the TS buffer to 16MB, to have more reserve when recording several HD programmes. - Added checking the symbol rate to cDvbTuner::IsTunedTo(), which apparently got lost in version 1.7.13 (thanks to Helmut Binder). - Now checking for an empty command in cDvbTuner::GetSignalStats() to avoid a possible error message (thanks to Helmut Binder). - Now initializing the status variable in cDvbTuner::GetFrontendStatus() and cDvbTuner::GetSignalStats() to avoid problems with drivers that don't do this (thanks to Helmut Binder). - Fixed multiple recording entries in case a recording is started during the initial reading of the video directory (reported by Claus Muus). - Fixed an unnecessary double call to Display() in cMenuRecording::RefreshRecording() (reported by Christoph Haubrich). - Fixed a crash in case an error occurs when setting a remote timer. - Fixed allocating memory for cImage (reported by Christoph Haubrich). - Fixed parsing the '-l' command line option (reported by Harald Milz). - Fixed possible compilation errors with libjpeg (thanks to Bernd Kuhls). - Fixed "read incomplete section" errors (thanks to Helmut Binder). - Fixed generating the HashId in cEIT::cEIT() (thanks to Helmut Binder). - Added initialization of cDvbFrontend::frontendInfo (thanks to Winfried Köhler). - Fixed a bug in handling shared PMTs, where after the first pass not all SIDs of a PMT pid were checked any more (thanks to Helmut Binder). - Fixed PMT handling in case locking the Channels list times out (reported by Helmut Binder). - Avoiding a lengthy lock on the Channels list when starting a recording (thanks to Helmut Binder). - Fixed error handling when loading a plugin (reported by Markus Ehrnsperger). - Improved handling missing VDRPluginDestroyer() (thanks to Winfried Köhler). - Fixed initializing tmpbuf in ExtendedEventDescriptors::getText() (thanks to Helmut Binder). - Fixed a compiler warning (thanks to Winfried Köhler). - Fixed convertCharacterTable() in case iconv_open() fails (thanks to Helmut Binder). - Official release. Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr not working in Raspbian 10
On 29.11.20 11:33, Narcis Garcia wrote: ... de nov. 29 11:29:53 raspberrypi vdr[11391]: [11391] ERROR (dvbdevice.c,1650): /dev/dvb/adapter0/frontend1: El dispositiu o recurs es troba ocupat If this error message was given in English I might be able to interpret it. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr not working in Raspbian 10
On 28.11.20 17:55, Narcis Garcia wrote: ... de nov. 28 17:33:12 raspberrypi vdr[30508]: [30514] frontend 0/0 lost lock on channel 23 (Telecinco), tp 586 de nov. 28 17:33:13 raspberrypi vdr[30508]: [30514] frontend 0/0 regained lock on channel 23 (Telecinco), tp 586 Maybe a bad cable/connector? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr not working in Raspbian 10
On 28.11.20 17:30, Narcis Garcia wrote: Hello, I've installed vdr from Raspbian packages, to use it with Kodi. I've updated channels.conf by using w_scan2 for a DVB-T2 dongle. TV channels are found. But I try to watch some channel and I get no data. Does the user id under which you run VDR have access to the DVB devices? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR do not show HD channels.
On 22.11.20 13:42, Richard F wrote: ... I'll see if I can rebuild with latest. I already can't rebuild a couple of plugins on SuSe 15.2/gcc 7 (bug logged for smartvweb a long time back), I'm concerned more things might break, which is why I'm still on 2.20. But I'll try. You don't need any plugins (except for output) to test this. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR do not show HD channels.
On 21.11.20 17:11, Richard F wrote: Klaus - thanks for your reply. 2 problems - the first is my own - I don't like all the rubbish shopping channels filling up my channel list and I sort it manually to keep the channels in a sensible order instead of the random order the broadcasters have ended up with - so I have the 'updatechannels' setting at 3 instead of 5. Problem 2 is that VDR doesn't complete HD tuning - at least in first 30 mins or so, example here - I deleted BBC1HD & BBC2HD, set the update value to 5, restarted and let it retune. It added both back, but BBC1HD is saved like this after about 30 mins (incomplete/nonworking): BBC ONE HD:546000:G32M256P0Q16435S1T8X1:T:27500:0:0:0:0:17540:9018:16516:0 The right tuning values are: BBC ONE HD:546000:G32M256P0Q16435S1T8X1:T:27500:6601=27:6602=eng@17,6606=eng@17:0;6605=eng:0:17540:9018:16516:0 Bit it did get BBC2HD right immediately - on the same multiplex. BBC TWO HD:546000:G32M256P0Q16435S1T8X1:T:27500:101=27:102=eng@17,106=eng@17:0;105=eng:0:17472:9018:16516:0 The transponder data and the PIDs are broadcast in separate lists. Maybe the PID list is parsed before the transponder list, and thus the PIDs are missed for BBC ONE HD. IIRC there were some changes in list parsing after version 2.2 (which I understand is the version you have in use). Can you please try the latest version from git.tvdr.de, to see whether this problem still persists? Klaus After maybe an hour or so, it seems to update and get it right, so it may just be that I'm not waiting long enough for the HD channels to re-tune when doing this way, or maybe something to do with the first channel? Nowadays I let the SD channels tune themselves the same way, and they are OK in a minute or 2. My normal process is to set updatechannels to 5 to capture new stuff occasionally, then manually re-sort the new channels added, and reset to 3. Appreciate your views. On 20/11/2020 1:00 pm, Klaus Schmidinger wrote: I have several DVB-T2 channels in my list, for instance: Das Erste HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4113=36:4114=deu@17,4115=mis@17:4116:0:769:8468:12291:0 arte HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:4134:0:770:8468:12291:0 phoenix HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4145=36:4146=deu@17,4147=mul@17:4148:0:771:8468:12291:0 tagesschau24 HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4161=36:4162=deu@17:4163:0:772:8468:12291:0 ONE HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4177=36:4178=deu@17,4179=mis@17:4180:0:773:8468:12291:0 If I delete "arte HD" it gets re-added automatically (after I switch to that transponder again): Nov 20 13:55:33 vdr3 vdr: [26237] creating new channel 'arte HD,;BR' on T transponder 554 with id 8468-12291-770-0 Nov 20 13:55:34 vdr3 vdr: [26237] changing pids of channel 2096 (arte HD) from 0+0=0:0:0:0 to 4129+4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:0:4134 Where exactly is the problem? Klaus On 19.11.20 13:34, Richard F wrote: I'm using DVB-T2 with a PC-TV 290E USB nanostick in UK. I'm also still on V2.20. My notes on tuning confirm that "... this (setting VDR to find new transponders) doesn't seem to be able to config HD channels - can check TS-ID, ON-ID Srv-ID with Sony TV" Basically I have to hand-edit the parameters taken off a normal HD TV, as also none of the 3rd party tuning tools seem to properly tune HD for me, and I've tried many of them and many versions and methods over the years. I once thought I had it working with w_scan, but no longer, results don't work, though w_scan does see the channels. Would be really good to fix ! Sadly I think most or all of these 3rd party tools are now effectively unmaintained. Richard On 18/11/2020 9:50 pm, prelude wrote: Hello and thx for this great VDR software. Could someone help me at the start as I cannot get dvb-t2 channels visible in VDR? If I add HD channels manually in channels.conf then VDR mark those as OBSOLETE. Yesterday I even clean my channels.conf totally and just left one channel on it and put in setup "add new transponders". In the morning all DVB-T channels were in channels.conf file but not any DVB-T2. tvheadend works fine also in HD channels but i just like so much more VDR user experience that i don't want to change it. ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Subtitle
On 18.11.20 13:07, Alexander wrote: Hi, my wife is hard of hearing and that is why we have permanently discontinued the subtitle in the vdr. But if she don't watch, I'll turn off the subtitle with the hotkey. When I switch channels, the subtitle is on again. Is there a possibility that the subtitles will not appear until the next restart of vdr? Set "Setup/DVB/Display subtitles" to "no". When you want them to be displayed automatically again, set it back to "yes". You could add to you VDR start script that in setup.conf the line DisplaySubtitles = 0 is changed to DisplaySubtitles = 1 before starting VDR. You don't actually need to change that line, just appending DisplaySubtitles = 1 to setup.conf will do. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR do not show HD channels.
I have several DVB-T2 channels in my list, for instance: Das Erste HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4113=36:4114=deu@17,4115=mis@17:4116:0:769:8468:12291:0 arte HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:4134:0:770:8468:12291:0 phoenix HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4145=36:4146=deu@17,4147=mul@17:4148:0:771:8468:12291:0 tagesschau24 HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4161=36:4162=deu@17:4163:0:772:8468:12291:0 ONE HD;BR:554000:B8D0G19128M2P0Q111S1T16X0Y0:T:27500:4177=36:4178=deu@17,4179=mis@17:4180:0:773:8468:12291:0 If I delete "arte HD" it gets re-added automatically (after I switch to that transponder again): Nov 20 13:55:33 vdr3 vdr: [26237] creating new channel 'arte HD,;BR' on T transponder 554 with id 8468-12291-770-0 Nov 20 13:55:34 vdr3 vdr: [26237] changing pids of channel 2096 (arte HD) from 0+0=0:0:0:0 to 4129+4129=36:4130=deu@17,4131=fra@17,4132=mis@17,4133=mul@17:0:4134 Where exactly is the problem? Klaus On 19.11.20 13:34, Richard F wrote: I'm using DVB-T2 with a PC-TV 290E USB nanostick in UK. I'm also still on V2.20. My notes on tuning confirm that "... this (setting VDR to find new transponders) doesn't seem to be able to config HD channels - can check TS-ID, ON-ID Srv-ID with Sony TV" Basically I have to hand-edit the parameters taken off a normal HD TV, as also none of the 3rd party tuning tools seem to properly tune HD for me, and I've tried many of them and many versions and methods over the years. I once thought I had it working with w_scan, but no longer, results don't work, though w_scan does see the channels. Would be really good to fix ! Sadly I think most or all of these 3rd party tools are now effectively unmaintained. Richard On 18/11/2020 9:50 pm, prelude wrote: Hello and thx for this great VDR software. Could someone help me at the start as I cannot get dvb-t2 channels visible in VDR? If I add HD channels manually in channels.conf then VDR mark those as OBSOLETE. Yesterday I even clean my channels.conf totally and just left one channel on it and put in setup "add new transponders". In the morning all DVB-T channels were in channels.conf file but not any DVB-T2. tvheadend works fine also in HD channels but i just like so much more VDR user experience that i don't want to change it. ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] option parsing for --log still broken
On 17.11.20 12:17, Harald Milz wrote:
Hi Klaus and all,
it appears that option parsing for the --log option is still broken, as
described in this thread:
https://www.vdr-portal.de/forum/index.php?thread/108924-gel%C3%B6st-logging-von-yavdr-in-separaten-logfiles-anstelle-des-syslog-und-probleme/
...
In your patch, if optarg is longer than 3 characters, strncpy() wouldn't
terminate
'copy' with 0.
This should do, too:
--- vdr.c 2020/05/18 16:47:29 4.33
+++ vdr.c 2020/11/17 17:11:51
@@ -422,6 +422,7 @@
SysLogLevel = l;
if (!p)
break;
+ *p = '.';
if (isnumber(p + 1)) {
int l = atoi(p + 1);
if (0 <= l && l <= 7) {
The first break doesn't matter, because p is NULL in that case and thus optarg
has
not been changed.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 2.4.4 released
VDR version 2.4.4 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.4.4.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.4.1-2.4.4.diff MD5 checksums: ccf724c157740b2b153ca41ad38f1217 vdr-2.4.4.tar.bz2 12845052da407da62748982c01cc5d52 vdr-2.4.1-2.4.4.diff You can also get the latest version at the official VDR GIT archive with git clone git://git.tvdr.de/vdr.git This version fixes a few bugs that came up after the release of version 2.4.1. The changes since version 2.4.1: - Fixed moving channels between number groups in SVDRP's MOVC command and the Channels menu, in case a channel is moved to a higher number and into a numbered group (reported by Manuel Reimer). - Now retuning if the received transponder's SDT doesn't contain the expected values for NID and TID (thanks to Uwe Scheffler for reporting a problem with failed tuning in SCR systems, and Helmut Binder for helping with the implementation). - Fixed compatibility with current versions of glibc (thanks to Manuel Reimer). - The SVDRP command DELC now also accepts a channel id (suggested by Manuel Reimer). - Fixed dropping capabilities in case cap_sys_time is not available. - Added the language code for Bulgarian (thanks to Helmut Binder). - Fixed handling multi part ExtendedEventDescriptors where only the first part contains information about the character table (based on a patch from Helmut Binder). - When setting the system character table, it is no longer checked against the known entries that are hard coded in libsi/si.c, but rather given to iconv_open() and the result of that call is used to check whether the given name is valid. - Checking whether the system character table is "single byte" is now done by checking the result of a sample call to iconv(). - Setting the override character table now checks and reports whether the given value is valid (suggested by Helmut Binder). - The isSingleByte parameter in the call to getCharacterTable() is deprecated and only present for backwards compatibility. - Fixed a possible crash in case replay is started and stopped in rapid sequence, by adding missing locking to cControl::Control(). The caller of this function must now provide a cMutexLock which stays alive as long as the result of this call is used. The old version of this function is still there for backwards compatibility with plugins, because this problem appears to occur only under very rare circumstances. Authors of plugins that use this function should switch to the new version, because the old one is deprecated and will be removed in a future version. The version numbers (both VDRVERSNUM and APIVERSNUM) have been bumped to 2.4.2, so that plugins can detect the presence of the new cControl::Control(). - Added a missing '-D' to the 'plugins' target of the Makefile (thanks to Johann Friedrichs). - Fixed the size of cChannel::dtypes[] (thanks to Winfried Köhler). The version numbers (both VDRVERSNUM and APIVERSNUM) have been bumped to 2.4.3 to indicate this change. - Added a device hook for detecting whether a device provides EIT data (thanks to Winfried Köhler). - Fixed memory handling in cString::Append() (reported by Stefan Herdler). - Revised 'Fixed a possible deadlock when detaching a receiver from a device' from version 2.3.9, which sometimes caused a black screen when switching channels (thanks to Stefan Verse). - Added failsafe defaults for 'make LCLBLD=1' to the Makefile (thanks to Stefan Herdler). - Added codes for more languages and special audio tracks (thanks to Helmut Binder). - Added cMtdCamSlot::TsPostProcess() (thanks to Helmut Binder). - Added cMtdHandler::StopDecrypting() (thanks to Helmut Binder). - Added support for detecting new channels broadcast in HEVC (thanks to Helmut Binder). - Added support for detecting 'advanced codec digital radio sound service' (thanks to Helmut Binder). - Added handling shared PMT pids and multiple PMT sections (thanks to Helmut Binder). - Changed the country code in the generated ParentalRatingDescriptor from 'DEU' to '902' to make it valid for all countries (thanks to Helmut Binder). - Added optional verbose output to the libsi Makefile (thanks to Tobias Grimm). - Made the call to pkg_config configurable via the PKG_CONFIG macro, which is necessary for cross-building VDR (thanks to Tobias Grimm). Plugin authors may want to modify their Makefiles accordingly by adding the line 'PKG_CONFIG ?= pkg-config' and replacing every occurrence of 'pkg-config' with '$(PKG_CONFIG)', as can be seen in the Makefiles of the plugins that come with the VDR source. - Fixed a typo in svdrp.c (thanks to Tobias Grimm). - Added support for HEVC-video and AC-4-audio (thanks to Christoph Haubrich). - Added a comment about the semantics of cTimeMs::Set(). - Adjusted device selection in GetDeviceForTransponder() to that in GetDevice() (thanks to
Re: [vdr] Filtering encrypted channels
On 07.04.20 06:11, Daniel wrote: Vom: Tue, 7 Apr 2020 00:00:06 +0200 On 06.04.20 18:23, Daniel wrote: > Vom: Mon, 6 Apr 2020 15:07:31 +0200 > > I've fiddled with the settings and when I changed "Audio-Languages" from 1 > to 2 and configured Language 1 to german and 2 to english, I could switch > to NHK WORLD-JAPAN which previously didn't work. That sounds rather odd. It makes sense to me. I configured german as only language and never noticed that CNN still works (only one audio stream, non-german). But channels with multiple audio streams (and no german one) didn't work. That must be a problem in the VNSI plugin or whatever. It works fine in plain VDR (just tested it). If none of the preferred languages is available, it selects the first one. > I suppose the other unencrypted channels could work, too when I select the > correct audio language. There's no such thing as "correct audio language". It should work with any language. It _seems_ like a vdr-plugin-vnsiserver issue. Still it's just a wild guess. Since this setting apparently fixed it, i didn't dig deeper. Well, if it works for you, that's fine. ... Is there a way to test if VDR is currently tuned to a channel? Yesterday I learned that my thinking was wrong. I watched TV (no recording) and VDR was restarted at midnight while watching ;) VDR is *always* tuned to a (live) channel ;-). I tried "svdrpsend chan" but it always returns the first entry in channels.conf, no matter if kodi plays TV or not (or what channel it's tuned to). The CHAN command tells you which channel VDR itself is currently showing live. If you are watching with some streaming plugin, you need to ask that plugin. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filtering encrypted channels
On 06.04.20 18:23, Daniel wrote: Vom: Mon, 6 Apr 2020 15:07:31 +0200 I've fiddled with the settings and when I changed "Audio-Languages" from 1 to 2 and configured Language 1 to german and 2 to english, I could switch to NHK WORLD-JAPAN which previously didn't work. That sounds rather odd. I suppose the other unencrypted channels could work, too when I select the correct audio language. There's no such thing as "correct audio language". It should work with any language. As mentioned in my previous reply: please test with plain vanilla VDR, no VNSI or any other streaming stuff. Once things work there, you can add other output methods if you need to. I'm quite happy the way it is. Thank you so much Olly and Klas for your help! Just another question: Is there a way to run the script before VDR starts to tune to a channel? Or after it stops playback of any channel? I would run the script at midnight and restart VDR to reload the new channels.conf but when I record something, the recording would be interrupted that way. You can use the SVDRP command NEXT to see if VDR is currently recording, or when the next recording will start. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filtering encrypted channels
On 06.04.20 17:49, Daniel wrote: ... > channel marked as FTA but can't be displayed: > > NHK WORLD-JAPAN (eng);Digital > Free:546000:C0M256:C:6900:2931=2:2932=eng@3:0:0:53120:61441:10004:0 This is MPEG video (2931=2). Strange, it can't be played. VDR doesn't output anything with loglevel 3 when I switch to this channel. Kodi log says: 2020-04-06 17:38:26.865 T:139778643008064 NOTICE: VideoPlayer::OpenFile: 2020-04-06 17:38:26.865 T:139778453800704 NOTICE: Creating InputStream 2020-04-06 17:38:26.865 T:139778453800704 ERROR: Error on dvdnav_open 2020-04-06 17:38:26.865 T:139778453800704 ERROR: CVideoPlayer::OpenInputStream - error opening [] 2020-04-06 17:38:26.865 T:139778453800704 NOTICE: CVideoPlayer::OnExit() 2020-04-06 17:38:26.878 T:139777123219200 ERROR: SignalQuality: Add-on 'VDR-Network-Streaming-Interface (VNSI) Server:127.0.0.1:34890' returned an error: server error 2020-04-06 17:38:27.119 T:139778643008064 NOTICE: CVideoPlayer::CloseFile() 2020-04-06 17:38:27.119 T:139778643008064 NOTICE: VideoPlayer: waiting for threads to exit 2020-04-06 17:38:27.119 T:139778643008064 NOTICE: VideoPlayer: finished waiting could this be an issue with VNSI? VNSI is not an integral part of VDR. Have you tried watching the channel directly in VDR? Things to test: - Can your output device play MPEG video? Some devices (like the Raspberry Pi, for instance) require a separate license for that. It should be. I can playing MPEG container videos with kodi. I'm running kodi on gentoo with system ffmpeg libraries. Please make these tests with plain vanilla VDR. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filtering encrypted channels
On 06.04.20 14:49, Daniel Hiepler wrote: Vom: Mon, 6 Apr 2020 14:31:33 +0200 '1' means that this channel is "hardwired" to device 1, whether it's encrypted or not. Generally hardwiring channels to devices is not recommended. '0' means the channel is FTA (free to air, unencrypted). Values greater than 0xFF define the CA ID of that channel, which means it is encrypted. There can be more than one CA ID for a given channel, as in "98C,9C4,98D". Ah, so when I decode the hex number, any channel with CAID < 255 should be unencrypted and viewable? For simplicity, let's just assume that FTA channels have a CA ID of '0', while encrypted channels have something else. Any value between '1' and '255' (including) would have to be set manually, which I assume you never did. (I'm not getting what "device" means in this case) The 'device' is the receiver (the thing you connect the antenna cable to). ... FTA channel that can be displayed: SWR RP HD;ARD:33:C0M256:C:6900:5131=27:0;5132=deu@106,5133=mis@106:5134;5135=deu:0:10304:1:1051:0 This one has H.264 video (5131=27). channel marked as FTA but can't be displayed: NHK WORLD-JAPAN (eng);Digital Free:546000:C0M256:C:6900:2931=2:2932=eng@3:0:0:53120:61441:10004:0 This is MPEG video (2931=2). channel with CA ID (can't be displayed): Euro Star (tur);Türkisch:546000:C0M256:C:6900:671=2:672=tur@3:0:1722,1834,9C7,1861,9FD,1854:53210:61441:10004:0 Also MPEG video (671=2), but encrypted. You will need a CAM with a proper smartcard to decrypt this one. Things to test: - Can your output device play MPEG video? Some devices (like the Raspberry Pi, for instance) require a separate license for that. - Do you receive any data from "NHK WORLD-JAPAN"? Check the log entries for "buffer stats" when switching to that channel, remaining on it for a while, and then switching to a different channel. - If you record "NHK WORLD-JAPAN", does it produce a non-empty file? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filtering encrypted channels
On 06.04.20 14:36, Daniel wrote: ... According to https://github.com/yavdr/vdr/blob/master/channels.c#L571 it's definetly field #9. But there are channels with 0 at this position which I can't view with kodi. Would VDR change channels.conf if dvbscan wrote that field wrongly or just leave it that way? I wonder if that's a bug. If the PAT contains the correct CA IDs and the field #9 is 0 or greater than 0xFF, then VDR will update the CA IDs in channels.conf. Try enabling the line //#define DEBUG_CA_DESCRIPTORS 1 in pat.c to see whether the PAT contains CA descriptors. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filtering encrypted channels
On 06.04.20 00:10, Daniel wrote: Vom: Sun, 5 Apr 2020 23:42:30 +0200 On 05.04.20 19:53, Daniel wrote: > Meaning, when field 11 in channels.conf is 1 it is free and if it's != 1 > it's encrypted? The CA ID is stored in field number 9. '1' means that this channel is "hardwired" to device 1, whether it's encrypted or not. Generally hardwiring channels to devices is not recommended. '0' means the channel is FTA (free to air, unencrypted). Values greater than 0xFF define the CA ID of that channel, which means it is encrypted. There can be more than one CA ID for a given channel, as in "98C,9C4,98D". That is my understanding of man 5 vdr Hm, how do you read it's field 11 from man 5 vdr? It totally confused me since the CHANNELS section mentions from left to right documentation of fields: Name, Frequency, Parameters, Source, Strate, VPID, APID, TPID, Conditional access, SID, NID, TID and RID which would make field 11 the NID and field 9 the conditional access field. You are right, it is field 9. My channels.conf has 13 fields. An example line would be SWR RP HD;ARD:33:C0M256:C:6900:5131=27:0;5132=deu@106,5133=mis@106:5134;5135=deu:0:10304:1:1051:0 So if it's field 9, then cut -d":" -f1,9 /etc/vdr/channels.conf | grep -E ':0$' should display only free channels, but it also displays Eurosport360HD 5,Eurosp360 5;SKY:378000:C0M256:C:6900:0:0:0:0:310:133:4:0 (complete line) for example. If this is an encrypted channel, then the provider doesn't broadcast the CA ID according to the DVB standard. If it's field 11, then only free channels are listed but some free channels are missing, like PHOENIX HD;ARD:474000:C0M256:C:6900:581=27:0;582=deu@106,583=mul@106:584:0:10331:61441:10009:0 Is something wrong with my file? Kodi can show PHOENIX HD and can't decrypt Eurosport360HD 5 I'm not sure if it's ok to paste my complete channels.conf for clarification to the list (if that helps). It has 463 lines. Just post two lines, one for an FTA channel and one for an encrypted channel. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] GIT archive of VDR code
The VDR source code is now available in the GIT archive hosted at http://git.tvdr.de Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 20 Years of VDR / Announcing "GeoTagger"
On 19.02.20 18:45, Wolfgang Rohdewald wrote: Am Mittwoch, den 19.02.2020, 16:36 +0100 schrieb Klaus Schmidinger: Unfortunately there was no application available under Linux that really fit my needs (maybe I just missed that one great program ;-). digikam I took a look at that one. Certainly a great program, but way too complex for such a simple task. Besides, the first thing it wants to do is create a "database". No need for that... Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] 20 Years of VDR / Announcing "GeoTagger"
Twenty years ago today, I released the first version of the VDR source. A pretty long time, in which much has happened. Back then a VDR was something special, while today it's just an ordinary device. But still it feels good to be able to tweak things yourself. Lately it's been rather quiet from my side, regarding the VDR development. For one this was because it just works fine in every day life. But I was also busy working on a totally different project. I wanted to add/adjust the GPS coordinates in the many photos that piled up over the years (partly scanned from negatives). Unfortunately there was no application available under Linux that really fit my needs (maybe I just missed that one great program ;-). So I decided to do some development of my own, and today, for the 20th "birthday" of VDR, I'd like to present the result: http://www.tvdr.de/geotagger This is the very first version to go "out in the wild", so chances are there will still be some quirks. So far I have tested it on Linux (openSUSE Leap 15.0) and Mac OS 10.13. I can't test on Windows, because I don't have such a system. Maybe it can be of some use to some of you out there, too. Please send problem reports directly to me, so we don't clog this mailing list. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 2.4.1 released
VDR version 2.4.1 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.4.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.4.0-2.4.1.diff MD5 checksums: b2897fe6b6e6711d512a69642b1b8ec1 vdr-2.4.1.tar.bz2 cf5f328165e1a48e28e68b6709312e63 vdr-2.4.0-2.4.1.diff This version fixes a few bugs that came up after the release of version 2.4.0. The changes since version 2.4.0: - Fixed handling the tfRecording flag in the SVDRP commands MODT and UPDT (reported by Johann Friedrichs). - Fixed a possible invalid locking sequence in case a remote timer handling error message is displayed on the OSD and the skin tries to lock the Recordings or DeletedRecordings list in its Flush() function (for instance by calling cVideoDiskUsage::HasChanged()). To do this, the call to Skins.Message() in menu.c's HandleRemoteModifications() has been changed to Skins.QueueMessage(), and cSkins::ProcessQueuedMessages() is now called unconditionally in the main loop, and checks whether the current cSkinDisplay object (if any) implements SetMessage(). - Fixed locking the Channels list in cDisplayChannel, where the lock was still held when Flush() was called (reported by Matthias Senzel and Uwe Scheffler). - Fixed shutdown after user inactivity in case a plugin is keeping the OSD open (reported by Ulrich Eckhardt). - Fixed switching through encrypted channels with the Up/Down keys (thanks to Helmut Binder). - Now deactivating MTD support if a non MCD capable CAM is inserted after removing a previously used CAM that is MCD capable (thanks to Helmut Binder). - Added support for DVB devices with more than one frontend that all use the same dvr and demux. Note that in order for this to work, you must not set symbolic links like "demux1 -> demux0" and "dvr1 -> dvr0", as is mentioned in some user manuals of multi frontend DVB cards. - Reverted the change "The EIT filter no longer parses data from "other TS"...". It led to missing EPG data on channels from Canal Digital Norway (reported by Stian B. Barmen). - Fixed accessing the actual frontend on multi frontend devices (thanks to Helmut Binder). - Fixed opening the UDP port in peerdemo (thanks to Robert Hannebauer). - Fixed handling PATs that contain no PMTs. - Fixed processing the last entry in the scan list of the EIT scanner (thanks to Helmut Binder). - Fixed processing transponder data in the NIT (thanks to Helmut Binder). - Fixed triggering the SDT filter when parsing the NIT (thanks to Helmut Binder). - Added support for EAC3 audio from other sources (thanks to Jürgen Schneider). - No longer logging tuning timeouts for transponders that are announced in the NIT but are not currently broadcasting. - Fixed processing SI::T2DeliverySystemDescriptor when typecasting it over an SI::ExtensionDescriptor (reported by Helmut Binder). - Fixed sorting recordings alphabetically. - Fixed dropping capabilities in case cap_sys_time is not available. - Fixed updating the cursor position when switching channels with the Channel+/- keys while the Channels menu is open. - Fixed handling shared CA pids (thanks to Onur Sentürk). - Now touching the .update file in the video directory after removing deleted recordings, so that other VDRs that use the same video directory will update their list of (deleted) recordings and thus won't display too much empty disk space. - Fixed the install target in case of multiple jobs (thanks to Chris Mayo). - Fixed mapping SIDs in MTD (thanks to Helmut Binder). - Fixed updating the checksum in the CA table after mapping EMM PIDs for MTD (thanks to Helmut Binder). - Fixed a compiler warning in ExchangeChars() (thanks to Helmut Binder). - Fixed a compiler warning and a possible buffer overflow in cCiMMI::SendAnswer(). - Fixed a possible invalid lock sequence if the main menu is open and the user switches to a channel that is currently not available, using the Channel+/- keys. - Fixed handling remote timers in case the response to LSTT is '550 No timers defined'. - Fixed a compiler warning in cIndexFile::ConvertToPes() and added __attribute__((packed)) to tIndexPes and tIndexTs (suggested by Helmut Binder). - Fixed handling repeat function for keyboards. - Added a workaround for broadcasters who set an event to status "not running" where this is inappropriate; implicitly setting events to "not running" is now also logged. - Fixed asserting free disk space in case there is no local timer currently recording. - The default maximum size of a cPixmap has been raised to the maximum possible value. - Increased PLAYERBUFSIZE to (MAXFRAMESIZE * 5) to avoid stuttering replay under heavy system load, and to better document that this buffer size is related to the maximum frame size. - Fixed inconsistent behavior in case only certain devices are used (selected by the '-D' option). - Fixed a wrong variable name in cFileName::cFileName(). - If
Re: [vdr] Index of /Developer/Patches/vdr-2.4
On 03.06.19 21:18, Karim AFIFI wrote: ... Do you plan to provide soon a vdr-2.4.1 release with all of them ? Yes. There is one problem with the channel display on the Raspberry Pi that still needs to be solved, and after that I'm planning to release version 2.4.1. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 2.20 skincurses build error GCC7
On 03.06.19 10:30, Richard F wrote: Hi, I'm not sure how relevant the skincurses plugin is, but I can no longer build it under GCC7 (Opensuse 15.1) Please try this patch: http://ftp.tvdr.de/Developer/Patches/vdr-2.4/vdr-2.4.0-15-fix-skincurses.diff Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A couple of noob questions on VDR + vaapidevice (output plugin)
On 11.05.19 09:02, Frantisek Rysanek wrote: ... Yes, VDR, when started with vaapidevice, does ask me to press some keys on my remote to "detect the protocol". Except that I probably don't have a compatible remote for the mygica, or maybe the mygica "input device" in xinput does not count as a "LIRC remote", or I don't have lircd running, or its config is empty, or some such. If you put these lines in your 'remote.conf', you should be able to control VDR with vaapidevice via the keyboard: XKeySym.Up Up XKeySym.Down Down XKeySym.Menu m XKeySym.Ok Return XKeySym.Back BackSpace XKeySym.Left Left XKeySym.Right Right XKeySym.RedF1 XKeySym.Green F2 XKeySym.Yellow F3 XKeySym.Blue F4 XKeySym.0 0 XKeySym.1 1 XKeySym.2 2 XKeySym.3 3 XKeySym.4 4 XKeySym.5 5 XKeySym.6 6 XKeySym.7 7 XKeySym.8 8 XKeySym.9 9 XKeySym.Info i XKeySym.Channel+ k XKeySym.Channel- j XKeySym.Audio a XKeySym.Subtitles s XKeySym.User1 F5 XKeySym.User2 F6 XKeySym.User3 F7 XKeySym.User4 F8 XKeySym.User5 F9 XKeySym.User6 F10 Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Native client/server function
On 06.11.18 23:25, linuxtv at ncs-online wrote: Hi all, does someone know: ...are there any plans to implement a native client/server functionality direct into a future VDR code, with a kind of streamdev client/server usability? The plan ist still there, although there are still other things with higher priority, like support for multi frontend devices, which I am currently working on. Since there is streamdev, the pressure for implementing this into the VDR core is not really that high... Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
On 10/10/18 11:46 AM, Martin Gansser wrote:
I have contacted Andreas.
On advice of Andreas, I have defined the IOCTL myself in the file
dvbhdffdevice.h
this is the Patch: define_AUDIO_GET_PTS.patch
with this patch i get this warnings: [2]
--- vdr-2.4.0/PLUGINS/src/dvbhddevice/dvbhdffdevice.h.orig 2018-10-10
09:03:47.464147905 +0200
+++ vdr-2.4.0/PLUGINS/src/dvbhddevice/dvbhdffdevice.h 2018-10-10
09:04:59.353350738 +0200
@@ -4,6 +4,9 @@
* See the README file for copyright information and how to reach the author.
*/
+#ifndef AUDIO_GET_PTS _IOR('o', 19, __u64)
This should just be
#ifndef AUDIO_GET_PTS
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
On 10/9/18 10:27 AM, Martin Gansser wrote: Hello Klaus, will you provide a kernel> = 4.8 patch or will I need to contact the kernel developer for this? Hello Martin, please contact Andreas Regel about this. He maintains the dvbhddevice plugin. Greetings Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
On 9/28/18 8:05 PM, Jasmin J. wrote: Hi! This is obsolete since Kernel 4.8: https://www.kernel.org/doc/html/v4.8/media/uapi/dvb/audio-get-pts.html So VDR would already have needed to be changed quite some time ago. I guess it is time to do it now. BTW: I always thought that Linux kernel policy is not to allow userspace applications to break. Apparently this is no longer the case :-(. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
On 9/28/18 8:05 PM, Jasmin J. wrote: Hi! This is obsolete since Kernel 4.8: https://www.kernel.org/doc/html/v4.8/media/uapi/dvb/audio-get-pts.html Any idea why it was necessary to break these things? So VDR would already have needed to be changed quite some time ago. I guess it is time to do it now. In this particular case I would also suggest to create a patch for VDR 2.4.0, so that people with the stable VDR version can still compile it with recent Kernels. The core VDR doesn't use any of these. AFAIK they are only used in the output device plugins dvbsddevice and dvbhddevice. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
On 9/28/18 12:02 PM, Alexander Grothe wrote: It seems this definition has been removed upstream, because it was considered to be "unused": https://github.com/torvalds/linux/commit/d21c249b26311dd193b100e65fc9e7ae96233d40#diff-56193b27b16cac28881a16f295c6ff3cL133 Signed-off-by: Mauro Carvalho Chehab ...quite the expert, apparently ;-). Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
On 9/28/18 11:04 AM, Martin Gansser wrote:
ok, the Fedora30 package [1] kernel-headers-4.19.0-0.rc5.git2.1.fc30.x86_64.rpm
contains the file /usr/include/linux/dvb/audio.h,
but definition
#define AUDIO_GET_PTS _IOR('o', 19, __u64)
fehlt.
[1]
https://kojipkgs.fedoraproject.org//packages/kernel-headers/4.19.0/0.rc5.git2.1.fc30/x86_64/kernel-headers-4.19.0-0.rc5.git2.1.fc30.x86_64.rpm
I don't know what to do, write to the packager, so he can put in this definition again ?
The question is: why did he remove it in the first place?
or is there a other solution ?
You could put it back in yourself ;-).
Or take the header file from a previous version, where it still worked.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
On 9/28/18 10:21 AM, Martin Gansser wrote:
...
dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope
if (ioctl(fd_audio, AUDIO_GET_PTS, ) == -1) {
^
dvbhdffdevice.c:569:33: note: suggested alternative: 'VIDEO_GET_PTS'
if (ioctl(fd_audio, AUDIO_GET_PTS, ) == -1) {
^
VIDEO_GET_PTS
AUDIO_GET_PTS is defined in /usr/include/linux/dvb/audio.h.
Maybe this isn't included correctly, or you have a wrong version of it?
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiple vdr peers on same machine
On 9/25/18 8:52 PM, Mikko Tuumanen wrote: I have two vdr instances running on the same machine, one for recording and other for viewing. Then I wanted them to use the new vdr peer system to be able to edit timers from the viewing side. Running two vdr's didn't work because they both want to bind the 6419 port, ... Actually it should be possible to run several VDRs on the same machine without any exta efforts. All you need to do is use separate SVDRP ports via the --port option. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Modified VDR User Counter
In an effort to avoid possible problems with the new data protection law
in Germany ("DSGVO"), I have modified the VDR User Counter in such a way
that it no longer asks for or displays the user's name, public email address
and homepage URL. Any such previously entered data has been deleted from
the database.
Consequently, the page "People who have built a VDR" has been removed
entirely, because it connected user names to VDR User Numbers.
The VDR User Counter can be found at http://tvdr.de/counter.htm.
Maybe this is a good time to refresh your entry in case it has a
status of "outdated" or "unreachable" ;-). To do so, select "Edit your entry"
from the counter's main page, enter your user number and password and click
on "Edit my entry".
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 2.4.0 released
VDR version 2.4.0 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.4.0.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.9-2.4.0.diff MD5 checksums: 12c6a3abeadfa915fcfe736bb047a3ab vdr-2.4.0.tar.bz2 6d98c2d619e82f3d4503146602fccde7 vdr-2.3.9-2.4.0.diff A summary of all the major changes since the last stable version 2.2.0 can be found at http://www.tvdr.de/changelog.htm When updating from an earlier version of VDR please make sure you read the INSTALL and MANUAL files that come with the VDR source _before_ doing so! Please make sure you have backup copies of all your configuration files, and verify carefully that your timers will be set to the correct channels after switching to this new version. Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR, and also to all users who just enjoy VDR! Please also visit the VDR homepage at http://www.tvdr.de and VDR's facebook page at https://www.facebook.com/VideoDiskRecorder Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Video-Audio disruptions with 4.16+ kernel
On 12.04.2018 05:12, Richard Scobie wrote: ... Apr 11 09:46:18 vdr vdr[718]: [874] ERROR: driver buffer overflow on device 1 Apr 11 09:57:20 vdr vdr[718]: [892] ERROR: 1 TS packet(s) not accepted in Transfer Mode Apr 11 10:11:29 vdr vdr[718]: [914] ERROR: 6 TS packet(s) not accepted in Transfer Mode Apr 11 10:21:13 vdr vdr[721]: [816] ERROR: driver buffer overflow on device 1 Apr 11 10:21:21 vdr vdr[721]: [816] ERROR: driver buffer overflow on device 1 Apr 11 10:39:33 vdr vdr[721]: [873] ERROR: 11 TS packet(s) not accepted in Transfer Mode The above log messages regarding "packet(s) not accepted in Transfer Mode" appear to be from VDR 2.3.9, but the following ones must be from an earlier version: Apr 12 14:37:32 vdr vdr[922]: [957] ERROR: TS packet not accepted in Transfer Mode Apr 12 14:37:32 vdr vdr[922]: [957] ERROR: TS packet not accepted in Transfer Mode Apr 12 14:37:32 vdr vdr[922]: [957] ERROR: TS packet not accepted in Transfer Mode Apr 12 14:37:33 vdr vdr[922]: [957] ERROR: TS packet not accepted in Transfer Mode Apr 12 14:37:33 vdr vdr[922]: [957] ERROR: TS packet not accepted in Transfer Mode Apr 12 14:37:34 vdr vdr[922]: [957] ERROR: TS packet not accepted in Transfer Mode Apr 12 14:37:34 vdr vdr[922]: [957] ERROR: TS packet not accepted in Transfer Mode Apr 12 14:37:34 vdr vdr[922]: [957] ERROR: TS packet not accepted in Transfer Mode Just my 2ct, I'm afraid other than that I can't help. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Looking for DVB API documentation
On 09.04.2018 09:52, Josef Wolf wrote: Hello everybody, I am looking for the DVB API documentation. I know there is https://www.linuxtv.org/wiki/ and https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/dvb/dvbapi.html but the wiki states, the current API is v5. And there don't seem to exist any information about API v5. Well, it says "Version 5.10" in that file!? Maybe you are confused by "v4l", which is short for "Video For Linux"? PS: Is this the rigt list for such questions? A list for DVB specific topics (not vdr specific) don't seem to exist? You may want to try http://vger.kernel.org/vger-lists.html#linux-media Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 2.3.9: a few last minute fixes and last call for translations!
VDR version 2.3.9 is about to be released as stable 2.4.0 on April 15! The archive can be found here: ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.9.tar.bz2 (this is still the same as in my announcement dated March 18). I have posted a few last minute fixes at https://www.vdr-portal.de/forum/index.php?thread/131711-vdr-2-3-9-fixes (don't worry about the German descriptions, just download the "vdr-2.3.9-*.diff" files attached to each posting and apply them in order. The following language files still have the given number of untranslated texts: po/ar.po: 76 po/ca_ES.po: 76 po/cs_CZ.po: 22 po/da_DK.po: 208 po/el_GR.po: 271 po/es_ES.po: 22 po/et_EE.po: 7 po/fr_FR.po: 22 po/hr_HR.po: 208 po/hu_HU.po: 22 po/lt_LT.po: 22 po/nl_NL.po: 22 po/nn_NO.po: 336 po/pt_PT.po: 104 po/ro_RO.po: 22 po/ru_RU.po: 10 po/sk_SK.po: 22 po/sl_SI.po: 77 po/sr_RS.po: 76 po/sv_SE.po: 22 po/tr_TR.po: 208 po/zh_CN.po: 76 If nobody takes care of these, they will remain untranslated in version 2.4.0. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish
On 02.04.2018 14:22, Torgeir Veimo wrote: Do you have any plans for more integrated means of running a client server setup like the streamdev setup? I like the raspberry pi since it's low power, and does hdmi-cec, but without sata I'm concerned with disk bandwidth with multiple recordings. This already works very good with remote timers in VDR 2.3.9 (that's the setup I currently use). For replaying recordings I just mount the server's video directory on the RasPi. There's more to come after version 2.4.0 ;-). Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish
On 02.04.2018 14:20, Oliver Endriss wrote:
Am Montag, den 02.04.2018, 12:28 +0200 schrieb Klaus Schmidinger:
On 01.04.2018 19:01, Oliver Endriss wrote:
> ...
>> >> >> Does it make a difference whether the progress display is active or not
>> >> >> when you set the mark?
>> >
>> > If the progress bar is off, and you set a mark, progress bar and
>> > mark show up immediately. -> No problem.
>>
>> ...
>> > Could it be that this action is triggered _before_ the mark has been
>> > written to the OSD buffer? In this case, the OSD would be displayed
>> > without the mark, and the mark would be displayed during the next
>> > cycle, i.e. one second later.
>>
>> I doubt that.
Well, meanwhile I think you were right here.
In cReplayControl::MarkToggle() there is
lastCurrent = -1; // triggers redisplay
which it used to do until the switch to GetFrameNumber() ;-).
Now this has no immediate effect any more, and that may explain
the sluggishness you observe.
Please try this:
--- menu.c 2018/03/24 11:43:40 4.70
+++ menu.c 2018/04/02 10:07:05
@@ -5728,7 +5728,7 @@
bool cReplayControl::ShowProgress(bool Initial)
{
int Current, Total;
- if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
+ if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) -
lastProgressUpdate >= 1) {
if (GetFrameNumber(Current, Total) && Total > 0) {
if (!visible) {
displayReplay = Skins.Current()->DisplayReplay(modeOnly);
> I am pretty sure that something is wrong.
> With the following (ugly) patch, the problem is gone:
> ...
> All it does is executing the code in 'if (Initial...)' one more time,
> after lastProgressUpdate has been set to 0.
Thanks for pointing this out. This triggered my idea with lastCurrent above.
Thanks, your patch fixed the issue.
Taking a step back and considering that GetFrameNumber() was supposed to
be a drop-in replacement for GetIndex(), just returning the exact number
of the currently replayed frame and not just the index into the 'index'
file (which, apart from I-frames, is typically different) I revoked the
whole change and simply replaced GetIndex() with GetFrameNumber(). That
resulted in the sluggish progress display on the Raspberry Pi I reported
earlier. I then found that this was caused by the extra Flush() calls in
cReplayControl::ShowProgress(). So I removed them and now everything runs
smoothly on the RasPi and also on softhddevice.
So please try the attached patch instead of the previous one, and especially
check whether it still works on the dvbsddevice. This should hopefully also
fix the "jumping progress display".
There is, apparently, still a problem on the RasPi, where once you set
a mark, a subsequent "play" doesn't take effect until a couple of seconds
later. However, since this doesn't occur with softhddevice, I assume this
is a RasPi specific problem. I'll discuss this with Thomas separately.
Klaus
--- menu.h 2018/02/01 15:35:48 4.6
+++ menu.h 2018/04/02 13:41:49
@@ -300,7 +300,6 @@
bool lastPlay, lastForward;
int lastSpeed;
time_t timeoutShow;
- time_t lastProgressUpdate;
bool timeSearchActive, timeSearchHide;
int timeSearchTime, timeSearchPos;
void TimeSearchDisplay(void);
--- menu.c 2018/03/24 11:43:40 4.70
+++ menu.c 2018/04/02 13:41:39
@@ -5564,7 +5564,6 @@
lastPlay = lastForward = false;
lastSpeed = -2; // an invalid value
timeoutShow = 0;
- lastProgressUpdate = 0;
timeSearchActive = false;
cRecording Recording(fileName);
cStatus::MsgReplaying(this, Recording.Name(), Recording.FileName(), true);
@@ -5728,43 +5727,36 @@
bool cReplayControl::ShowProgress(bool Initial)
{
int Current, Total;
- if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
- if (GetFrameNumber(Current, Total) && Total > 0) {
-if (!visible) {
- displayReplay = Skins.Current()->DisplayReplay(modeOnly);
- displayReplay->SetMarks();
- SetNeedsFastResponse(true);
- visible = true;
- }
-if (Initial) {
- if (*fileName) {
- LOCK_RECORDINGS_READ;
- if (const cRecording *Recording = Recordings->GetByName(fileName))
- displayReplay->SetRecording(Recording);
- }
- lastCurrent = lastTotal = -1;
+ if (GetFrameNumber(Current, Total) && Total > 0) {
+ if (!visible) {
+displayReplay = Skins.Current()->DisplayReplay(modeOnly);
+displayReplay->SetMarks();
+SetNeedsFastResponse(true);
+visible = true;
+}
+ if (Initial) {
+if (*fileName) {
+ LOCK_RECORDINGS_READ;
+ if (const cRecording *Recording = Recordings->GetByName(fileName))
Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish
On 02.04.2018 12:35, Torgeir Veimo wrote: Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger: At the time this was done, I was still using the TT S2-6400 as output device. Jut curious, what are you using now? A raspberry pi? Currently a Raspberry Pi, but I'm planning to use my J3455M board's graphics with softhddevice (or vaapidevice). Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish
On 01.04.2018 19:01, Oliver Endriss wrote:
...
>> >> Does it make a difference whether the progress display is active or not
>> >> when you set the mark?
>
> If the progress bar is off, and you set a mark, progress bar and
> mark show up immediately. -> No problem.
...
> Could it be that this action is triggered _before_ the mark has been
> written to the OSD buffer? In this case, the OSD would be displayed
> without the mark, and the mark would be displayed during the next
> cycle, i.e. one second later.
I doubt that.
Well, meanwhile I think you were right here.
In cReplayControl::MarkToggle() there is
lastCurrent = -1; // triggers redisplay
which it used to do until the switch to GetFrameNumber() ;-).
Now this has no immediate effect any more, and that may explain
the sluggishness you observe.
Please try this:
--- menu.c 2018/03/24 11:43:40 4.70
+++ menu.c 2018/04/02 10:07:05
@@ -5728,7 +5728,7 @@
bool cReplayControl::ShowProgress(bool Initial)
{
int Current, Total;
- if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
+ if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) -
lastProgressUpdate >= 1) {
if (GetFrameNumber(Current, Total) && Total > 0) {
if (!visible) {
displayReplay = Skins.Current()->DisplayReplay(modeOnly);
I am pretty sure that something is wrong.
With the following (ugly) patch, the problem is gone:
--- vdr-2.3.9.org/menu.c2018-03-18 13:01:09.0 +0100
+++ vdr-2.3.9/menu.c2018-04-01 18:13:14.701413905 +0200
@@ -5726,7 +5726,19 @@ void cReplayControl::ShowMode(void)
bool cReplayControl::ShowProgress(bool Initial)
{
int Current, Total;
+
+#if 1 // OE
+ static int count = 0;
+
+ if (lastProgressUpdate == 0)
+ count = 2; // 0/1: problem, 2: fixed
+ else if (count > 0)
+ count--;
+
+ if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1 || count
> 0) {
+#else
if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
+#endif
if (GetFrameNumber(Current, Total) && Total > 0) {
if (!visible) {
displayReplay = Skins.Current()->DisplayReplay(modeOnly);
All it does is executing the code in 'if (Initial...)' one more time,
after lastProgressUpdate has been set to 0.
Thanks for pointing this out. This triggered my idea with lastCurrent above.
Of course, it does not affect the 'jumping' progress bar. See below.
...
> Btw, with a short recording, you can see that the progress bar is
> jumping in one second steps...
That's pretty much the distance between the I-frames, and thus the steps in
which VDR updates the progress bar.
I don't care about I-frames. I use the cutter to produce small audio
or video clips. The current behavior of the progress bar is annoying,
when I play these clips. Anyway, I can easily revert the code to get
the old behavior.
Is the jumping mainly with radio recordings?
If so, that could be explained by the lastProgressUpdate timeout, because
in radio recordings every frame is considered to be an "I-frame", while
in video recordings I-frames are typically spaced 0.5 to 1 second.
Let's first see whether the above patch fixes your sluggish marks display,
and then continue with the jumping progress bar.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish
On 19.03.2018 18:01, Oliver Endriss wrote:
Am Montag, den 19.03.2018, 14:45 +0100 schrieb Klaus Schmidinger:
On 19.03.2018 01:33, Oliver Endriss wrote:
> Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
>> On 18.03.2018 20:39, Oliver Endriss wrote:
>> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
>> >> On 18.03.2018 18:55, Oliver Endriss wrote:
>> >> > Hi,
>> >> >
>> >> > just installed vdr 2.3.9 and noticed that there is a delay
>> >> > when I try to set a recording mark, compared with vdr 2.2.0.
>> >> >
>> >> > Steps to reproduce:
>> >> > - Play a recording.
>> >> > - Press ok to display the progress bar.
>> >> > - Press 0 to set a mark.
>> >> >
>> >> > There is a notable delay between the keypress
>> >> > and the mark showing up.
>> >> >
>> >> > Can someone confirm this?
>> >>
>> >> Tried it while replaying on a Raspberry Pi, with the video directory
>> >> mounted via NFS, and had no unusual delay.
>> >>
>> >> - Which skin are you using?
>> > Classic skin.
>> >
>> >> - If applicable: Does it also happen with the LCARS skin?
>> > Yes.
>> >
>> >> - Are you running any plugins that utilize the cStatus::MarksModified() function?
>> > No. Test setup: vdr + dvbsddevice + remote.
>>
>> I'm afraid I don't have a working VDR with the old FF card any more, so
>> I can't test on that hardware. It doesn't happen with the Raspberry Pi,
though.
>>
>> Does it make a difference whether the progress display is active or not
>> when you set the mark?
Can you comment on this one?
If the progress bar is off, and you set a mark, progress bar and
mark show up immediately. -> No problem.
Very good!
>> >> - If none of the above: can you determine which version between 2.2.0 and
>> >>2.3.9 introduced this?
>> >
>> > Ok. I went back in time and installed the older versions.
>> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
>>
>> The only change that was introduced in that area between these two versions
>> is in cReplayControl::ShowProgress():
>>
>>if (Initial || time(NULL) - lastProgressUpdate >= 1) {
>>
>> Please try commenting out that line and the corresponding closing '}'.
>> While I don't see why this would only be a problem on dvbsddevice and not
>> on rpihddevice, I strongly suspect it to be the culprit.
>
> Yes, this fixes the issue completely!
If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).
So is this a workaround for the Raspberry?
Not in particular.
At the time this was done, I was still using the TT S2-6400 as output device.
> In vdr-2.3.9 the line looks like
> if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)
>
> As a consequence, the mark shows up immediately during fast-forward,
> while it is displayed with (variable) delay in play mode.
In cReplayControl::ProcessKey() there is
if (Key != kNone)
lastProgressUpdate = 0;
so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
always be true immediately after a key has been pressed ('0' in case of
setting a mark).
Can you verify this by adding some debug output?
Debug output indicates that this is true.
Could it be that this action is triggered _before_ the mark has been
written to the OSD buffer? In this case, the OSD would be displayed
without the mark, and the mark would be displayed during the next
cycle, i.e. one second later.
I doubt that.
While trying to reproduce this I saw that my LIRC remote control sometimes
"misses" a keypress, which makes the whole thing appear "sluggish".
When I set/remove a mark with the '0' key on the PC's keyboard, it works
just fine every time.
Do you see any difference in behavior between the (LIRC?) remote control
and using the keyboard?
> In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
> is affected, too.
>
> Anyway, I do not understand why rpihddevice should behave differently.
> Does this device have a slow OSD? In this case you might not notice...
The OSD on the RasPi is a lot faster than that on the old FF cards.
> I will update my dvbhddevice vdr to vdr-2.3.9 soon.
> I expect that it affected the same way.
I used a TT S2-6400 until recently (the motherboard is broken) and had no
problems setting editing marks. I'm curious to see what your experience
will be.
Update: The HD FF behaves exactly the same way as the SD FF.
Btw, with a short recording, you can see that the progress bar is
jumping in one second steps...
That's pretty much the distance between the I-frames, and thus the steps in
which VDR updates the progress bar.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish
On 19.03.2018 01:33, Oliver Endriss wrote:
Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
On 18.03.2018 20:39, Oliver Endriss wrote:
> Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
>> On 18.03.2018 18:55, Oliver Endriss wrote:
>> > Hi,
>> >
>> > just installed vdr 2.3.9 and noticed that there is a delay
>> > when I try to set a recording mark, compared with vdr 2.2.0.
>> >
>> > Steps to reproduce:
>> > - Play a recording.
>> > - Press ok to display the progress bar.
>> > - Press 0 to set a mark.
>> >
>> > There is a notable delay between the keypress
>> > and the mark showing up.
>> >
>> > Can someone confirm this?
>>
>> Tried it while replaying on a Raspberry Pi, with the video directory
>> mounted via NFS, and had no unusual delay.
>>
>> - Which skin are you using?
> Classic skin.
>
>> - If applicable: Does it also happen with the LCARS skin?
> Yes.
>
>> - Are you running any plugins that utilize the cStatus::MarksModified() function?
> No. Test setup: vdr + dvbsddevice + remote.
I'm afraid I don't have a working VDR with the old FF card any more, so
I can't test on that hardware. It doesn't happen with the Raspberry Pi, though.
Does it make a difference whether the progress display is active or not
when you set the mark?
Can you comment on this one?
>> - If none of the above: can you determine which version between 2.2.0 and
>>2.3.9 introduced this?
>
> Ok. I went back in time and installed the older versions.
> Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
The only change that was introduced in that area between these two versions
is in cReplayControl::ShowProgress():
if (Initial || time(NULL) - lastProgressUpdate >= 1) {
Please try commenting out that line and the corresponding closing '}'.
While I don't see why this would only be a problem on dvbsddevice and not
on rpihddevice, I strongly suspect it to be the culprit.
Yes, this fixes the issue completely!
If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).
In vdr-2.3.9 the line looks like
if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)
As a consequence, the mark shows up immediately during fast-forward,
while it is displayed with (variable) delay in play mode.
In cReplayControl::ProcessKey() there is
if (Key != kNone)
lastProgressUpdate = 0;
so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
always be true immediately after a key has been pressed ('0' in case of
setting a mark).
Can you verify this by adding some debug output?
In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
is affected, too.
Anyway, I do not understand why rpihddevice should behave differently.
Does this device have a slow OSD? In this case you might not notice...
The OSD on the RasPi is a lot faster than that on the old FF cards.
I will update my dvbhddevice vdr to vdr-2.3.9 soon.
I expect that it affected the same way.
I used a TT S2-6400 until recently (the motherboard is broken) and had no
problems setting editing marks. I'm curious to see what your experience
will be.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish
On 18.03.2018 20:39, Oliver Endriss wrote:
Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
On 18.03.2018 18:55, Oliver Endriss wrote:
> Hi,
>
> just installed vdr 2.3.9 and noticed that there is a delay
> when I try to set a recording mark, compared with vdr 2.2.0.
>
> Steps to reproduce:
> - Play a recording.
> - Press ok to display the progress bar.
> - Press 0 to set a mark.
>
> There is a notable delay between the keypress
> and the mark showing up.
>
> Can someone confirm this?
Tried it while replaying on a Raspberry Pi, with the video directory
mounted via NFS, and had no unusual delay.
- Which skin are you using?
Classic skin.
- If applicable: Does it also happen with the LCARS skin?
Yes.
- Are you running any plugins that utilize the cStatus::MarksModified()
function?
No. Test setup: vdr + dvbsddevice + remote.
I'm afraid I don't have a working VDR with the old FF card any more, so
I can't test on that hardware. It doesn't happen with the Raspberry Pi, though.
Does it make a difference whether the progress display is active or not
when you set the mark?
- If none of the above: can you determine which version between 2.2.0 and
2.3.9 introduced this?
Ok. I went back in time and installed the older versions.
Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
The only change that was introduced in that area between these two versions
is in cReplayControl::ShowProgress():
if (Initial || time(NULL) - lastProgressUpdate >= 1) {
Please try commenting out that line and the corresponding closing '}'.
While I don't see why this would only be a problem on dvbsddevice and not
on rpihddevice, I strongly suspect it to be the culprit.
If you like, we can continue this in private.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish
On 18.03.2018 18:55, Oliver Endriss wrote: Hi, just installed vdr 2.3.9 and noticed that there is a delay when I try to set a recording mark, compared with vdr 2.2.0. Steps to reproduce: - Play a recording. - Press ok to display the progress bar. - Press 0 to set a mark. There is a notable delay between the keypress and the mark showing up. Can someone confirm this? Tried it while replaying on a Raspberry Pi, with the video directory mounted via NFS, and had no unusual delay. - Which skin are you using? - If applicable: Does it also happen with the LCARS skin? - Are you running any plugins that utilize the cStatus::MarksModified() function? - If none of the above: can you determine which version between 2.2.0 and 2.3.9 introduced this? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 2.3.9
On 18.03.2018 17:59, Wolfgang Rohdewald wrote: On So, 2018-03-18 at 14:54 +0100, Klaus Schmidinger wrote: - Disabled the use of posix_fadvise() when reading (i.e. replaying), since it caused stuttering replay in fast forward and fast rewind mode in case the video directory is mounted via NFS. You can re-enable it by setting the macro USE_FADVISE_READ to 1 in tools.c. Will it be possible to do that at compile time without changing the source code like you now do for the deprecated function? Yes, that should be possible. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 2.3.9
VDR developer version 2.3.9 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.9.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.8-2.3.9.diff MD5 checksums: 9e4202b046df9ea960d930ce99e967ab vdr-2.3.9.tar.bz2 38a0f436fbed219665725aa2e54a9ca0 vdr-2.3.8-2.3.9.diff Approaching version 2.4.0: == If there are no more serious bug reports, the final version 2.4.0 of VDR shall be released on April 15. So please test this developer version intensely and report any problems you might encounter as soon as possible. The following language files still have the given number of untranslated texts: PLUGINS/src/hello/po/ca_ES.po: 6 PLUGINS/src/hello/po/da_DK.po: 6 PLUGINS/src/hello/po/el_GR.po: 6 PLUGINS/src/hello/po/es_ES.po: 6 PLUGINS/src/hello/po/fr_FR.po: 6 PLUGINS/src/hello/po/hu_HU.po: 6 PLUGINS/src/hello/po/nl_NL.po: 6 PLUGINS/src/hello/po/nn_NO.po: 6 PLUGINS/src/hello/po/pt_PT.po: 6 PLUGINS/src/hello/po/ro_RO.po: 6 PLUGINS/src/hello/po/sl_SI.po: 6 PLUGINS/src/hello/po/sv_SE.po: 6 po/ar.po: 76 po/ca_ES.po: 76 po/cs_CZ.po: 22 po/da_DK.po: 208 po/el_GR.po: 271 po/es_ES.po: 22 po/et_EE.po: 7 po/fi_FI.po: 3 po/fr_FR.po: 22 po/hr_HR.po: 208 po/hu_HU.po: 22 po/it_IT.po: 3 po/lt_LT.po: 22 po/mk_MK.po: 22 po/nl_NL.po: 22 po/nn_NO.po: 336 po/pt_PT.po: 104 po/ro_RO.po: 22 po/ru_RU.po: 10 po/sk_SK.po: 22 po/sl_SI.po: 77 po/sr_RS.po: 76 po/sv_SE.po: 22 po/tr_TR.po: 208 po/uk_UA.po: 22 po/zh_CN.po: 76 If nobody takes care of these, they will remain untranslated in version 2.4.0. The changes since version 2.3.8: - Updated the Italian OSD texts (thanks to Diego Pierotto). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Fixed a possible crash when stopping VDR (thanks to Matthias Senzel for reporting and helping to debug this one). - Fixed handling VPS events outside the LingerLimit, which could cause recordings to stop prematurely (thanks to Johann Friedrichs). - Fixed an invalid lock sequence when trying to remove a deleted recording in case of low disk space. - Now making sure that AssertFreeDiskSpace() is called with the maximum timer priority in case there are several timers recording with different priorities. - The MTD mapper now avoids immediately reusing unique PIDs when switching channels, to prevent possible problems with old data in buffers (thanks to Onur Sentürk). - The function cDevice::GetVideoSystem() (which has been deprecated since version 2.1.6) has been finally removed. - The macros used to control deprecated code or functions have been changed to hold numeric values (0 and 1), so that they can be controlled at compile time, without having to edit the actual source code (suggested by Jasmin Jessich). - The default for DEPRECATED_VDR_CHARSET_OVERRIDE has been set to 0, which means VDR no longer reacts on the environment variable VDR_CHARSET_OVERRIDE. You can add 'DEPRECATED_VDR_CHARSET_OVERRIDE=1' when compiling in order to restore this functionality. However, it is recommended to use the command line option --chartab instead. - The timeout for the channel display is now reset whenever the channel or EPG data changes. - OSD menus now try to keep the offset of the list cursor at a constant position on the screen, even if the list is modified while being displayed. - The LCARS skin's main menu now reacts to changes of the current channel's name. - If an event in the Schedules menu is marked with a 'T' or 'I' and the user presses the Red button to edit the timer, local timers are now preferred over remote timers in case there is more than one timer that will record that event. - Switching the primary device is no longer done via osSwitchDvb (which has been removed), but rather by the main program loop reacting to changes in Setup.PrimaryDVB. - The new SVDRP commands 'LSTD' and 'PRIM' can be used to list all available devices and to switch the primary device (thanks to Thomas Reufer). - Added some comments regarding font height (thanks to Thomas Reufer). - Fixed handling timers during the change from DST to winter time (thanks to Johann Friedrichs). - Added missing checks of 'player' in member functions of cControl, and setting cControl::player to NULL in cDvbPlayerControl::Stop() to avoid a possible crash with plugins that retrieve player information after a replay has been stopped, but before the replay control has been destroyed (thanks to Johann Friedrich). - Now calling Hide() and cStatus::MsgReplaying(..., false) from cReplayControl::Stop(), to inform plugins about an ending replay session before the replay control gets destroyed. - Fixed a possible crash when moving a recording between different volumes (reported by Matthias Senzel). - Fixed positioning the cursor in the Recordings menu when moving a recording between different volumes. - Added a note to PLUGINS.html about writing log messages in English. -
Re: [vdr] Channels getting deleted on new scan
On 11.03.2018 22:10, Timothy D. Lenz wrote: It turns out that both stations are owned by the same company. I have sent KGUN9 a second email about the conflict and reported it to the FCC as interference because they interfering with each other. Looking at this site: https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf I found this near the end: "RID Radio ID. Typical 0. Can be used to differentiate between channels having the same SID, NID and TID." Introducing the RID was a pretty ugly workaround. I suggest not to use it and rather try and find somebody at the broadcaster who knows his stuff ;-). My guess is they simply copy/pasted the configuration for these channels and didn't bother adhering to standards. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channels getting deleted on new scan
On 10.03.2018 01:21, Torgeir Veimo wrote: Isn't there a plugin that can change such data before it gets processed? The problem is that these are *duplicate* channels - they can't be in the channel list to begin with. They need to have different Transport Stream Ids. And as wen can see from Timothy's old channel list, they used to have these. So somebody just screwed up! Klaus On 10 March 2018 at 08:47, Timothy D. Lenz <tl...@vorgon.com <mailto:tl...@vorgon.com>> wrote: Wel, it gets better. Tonight I see VDR is grabbing guide data for 9x and using it for 58.x. So 58.x data is now being lost. g On 3/9/2018 2:29 AM, Klaus Schmidinger wrote: On 08.03.2018 22:38, Klaus Schmidinger wrote: On 08.03.2018 22:13, Timothy D. Lenz wrote: I was hoping it was something simple I could fix in the conf. I haven't worked on it or in linux in a long time and don't have the free time to figure it all out again. I'll have to look at this some other time. I am in the U.S. and these are ATA channels. They each have their own freq. and my guess is that they can use what ever numbers they want since they are on there own freq which they bought. Well, it's funny though that they use exactly the same IDs ;-). Sure they can do whatever they want, but there are a few basic rules that should be followed in order to guarantee a reasonable coexistance. One of them is that channels that are broadcast in the same area (like from the same terrestrial transmitter, on the same cable or the same satellite) should use unique IDs, even if they are on different transponders. One of these IDs is the "transport stream id", which in your case is 207 for both channels. This should be different. For testing I added your new channel list to my channels.conf. Here's what my VDR reported upon startup: Mar 9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf Mar 9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 Mar 9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0 Mar 9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0 With your old list I get no such log entries. So I guess somebody messed up with the TIDs, and the problem should be fixed there. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
On 09.03.2018 12:01, Patrick Boettcher wrote:
On Fri, 9 Mar 2018 11:55:02 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
On 09.03.2018 11:51, Patrick Boettcher wrote:
> On Fri, 9 Mar 2018 11:30:36 +0100
> Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
>
>> On 01.03.2018 10:22, Patrick Boettcher wrote:
>> > On Wed, 28 Feb 2018 11:01:23 +0100
>> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
>> >
>> >> On 27.02.2018 17:58, Patrick Boettcher wrote:
>> >> > On Tue, 27 Feb 2018 16:54:35 +0100
>> >> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
>> >> >
>> >> >> Hello Patrick,
>> >> >>
>> >> >> your scan doesn't contain the NIT, which is where the
>> >> >> transponder innformation is broadcast. Can you scan that,
>> >> >> too, please?
>> >> >
>> >> > Hi Klaus,
>> >> >
>> >> > NIT attached (from another multiplex with the same
>> >> > symptoms).
>> >>
>> >> DVB-DescriptorTag: 90 (0x5a) [=
>> >> terrestrial_delivery_system_descriptor] descriptor_length: 11
>> >> (0x0b) Center frequency: 0x (= 42949672.095 kHz)
>> >>
>> >> @@ -219,6 +219,8 @@
>> >>cDvbTransponderParameters dtp;
>> >>int Source =
>> >> cSource::FromData(cSource::stTerr); int Frequency =
>> >> Frequencies[0] = sd->getFrequency() * 10;
>> >> + Frequency = Transponder() * 100;//XXX
>> >> + dsyslog("Frequency = %08X, Transponder = %d",
>> >> sd->getFrequency(), Transponder());//XXX static int
>> >> Bandwidths[] = { 800, 700, 600, 500, 0, 0, 0,
>> >> 0 }; dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static
>> >> int Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };
>> >
>> > It works. I had to have VDR recreate the channels because it was
>> > mixing things up with the already existing ones.
>> >
>> > As to why the frequency is set to "-10" I don't know (yet), but I
>> > remember it has always been like this since 2005.
>> >
>> > Initial tuning files have always contained all active frequencies
>> > for their region, because the NIT did not set the center
>> > frequencies correctly.
>> >
>> > It might be because the multiplexed transport streams are
>> > generated centrally and then distributed to all the
>> > base-stations where they are emitted as-is but on different
>> > frequencies depending on the region.
>> >
>> > What can we do to get this upstream?
>>
>> I'm afraid I don't see how this case can be handled correctly.
>>
>> Maybe somebody else has an idea?
>
> One approach might be to ignore frequencies for DVB-T channels
> update during NIT parsing (in France only?).
>
>>From my experiences with DVB-T SetTopBoxes using the NIT for
> new channel-discovery is rarely done. No customer of my ex-employer
> was using it - scanning was entirely based on continuous
> frequency-band scanning with a spare demod.
>
> That would be my idea. But I don't know whether this can be easily
> applied to VDR.
Well, maybe this works for you?
--- nit.c 2016/12/23 14:16:59 4.4
+++ nit.c 2018/03/09 10:53:38
@@ -218,6 +218,8 @@
SI::TerrestrialDeliverySystemDescriptor *sd =
(SI::TerrestrialDeliverySystemDescriptor *)d;
cDvbTransponderParameters dtp; int Source =
cSource::FromData(cSource::stTerr);
+ if (sd->getFrequency() == 0x)
+continue;
int Frequency = Frequencies[0] =
sd->getFrequency() * 10; static int Bandwidths[] = { 800,
700, 600, 500, 0, 0, 0, 0 };
dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]);
This is what I'm doing right now (though I'm using break instead of
continue).
I realized that right after I had sent that message ;-).
But won't his inhibit the update of modulation parameters of the
_current_ channel?
Sure. But I don't see how to handle this...
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
On 09.03.2018 11:55, Klaus Schmidinger wrote:
On 09.03.2018 11:51, Patrick Boettcher wrote:
On Fri, 9 Mar 2018 11:30:36 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
On 01.03.2018 10:22, Patrick Boettcher wrote:
> On Wed, 28 Feb 2018 11:01:23 +0100
> Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> >> On 27.02.2018 17:58, Patrick Boettcher wrote: >> > On Tue, 27 Feb 2018
16:54:35 +0100
>> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
>> > >> >> Hello Patrick,
>> >> >> >> your scan doesn't contain the NIT, which is where the
>> >> transponder innformation is broadcast. Can you scan that, too,
>> >> please? >> > >> > Hi Klaus,
>> > >> > NIT attached (from another multiplex with the same symptoms). >> >>
DVB-DescriptorTag: 90 (0x5a) [=
>> terrestrial_delivery_system_descriptor] descriptor_length: 11
>> (0x0b) Center frequency: 0x (= 42949672.095 kHz)
>> >> @@ -219,6 +219,8 @@
>> cDvbTransponderParameters dtp;
>> int Source = cSource::FromData(cSource::stTerr);
>> int Frequency = Frequencies[0] =
>> sd->getFrequency() * 10;
>> + Frequency = Transponder() * 100;//XXX
>> + dsyslog("Frequency = %08X, Transponder = %d",
>> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
>> { 800, 700, 600, 500, 0, 0, 0, 0 };
>> dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
>> Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO }; > > It works. I had
to have VDR recreate the channels because it was
> mixing things up with the already existing ones.
> > As to why the frequency is set to "-10" I don't know (yet), but I
> remember it has always been like this since 2005.
> > Initial tuning files have always contained all active frequencies
> for their region, because the NIT did not set the center frequencies
> correctly.
> > It might be because the multiplexed transport streams are generated
> centrally and then distributed to all the base-stations where they
> are emitted as-is but on different frequencies depending on the
> region.
> > What can we do to get this upstream?
I'm afraid I don't see how this case can be handled correctly.
Maybe somebody else has an idea?
One approach might be to ignore frequencies for DVB-T channels update
during NIT parsing (in France only?).
From my experiences with DVB-T SetTopBoxes using the NIT for
new channel-discovery is rarely done. No customer of my ex-employer was
using it - scanning was entirely based on continuous frequency-band
scanning with a spare demod.
That would be my idea. But I don't know whether this can be easily
applied to VDR.
Sorry, of course it has to be "break" instead of "continue":
--- nit.c 2016/12/23 14:16:59 4.4
+++ nit.c 2018/03/09 10:57:21
@@ -216,6 +216,8 @@
break;
case SI::TerrestrialDeliverySystemDescriptorTag: {
SI::TerrestrialDeliverySystemDescriptor *sd =
(SI::TerrestrialDeliverySystemDescriptor *)d;
+ if (sd->getFrequency() == 0x)
+break;
cDvbTransponderParameters dtp;
int Source = cSource::FromData(cSource::stTerr);
int Frequency = Frequencies[0] = sd->getFrequency() * 10;
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
On 09.03.2018 11:51, Patrick Boettcher wrote:
On Fri, 9 Mar 2018 11:30:36 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
On 01.03.2018 10:22, Patrick Boettcher wrote:
> On Wed, 28 Feb 2018 11:01:23 +0100
> Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
>
>> On 27.02.2018 17:58, Patrick Boettcher wrote:
>> > On Tue, 27 Feb 2018 16:54:35 +0100
>> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
>> >
>> >> Hello Patrick,
>> >>
>> >> your scan doesn't contain the NIT, which is where the
>> >> transponder innformation is broadcast. Can you scan that, too,
>> >> please?
>> >
>> > Hi Klaus,
>> >
>> > NIT attached (from another multiplex with the same symptoms).
>>
>> DVB-DescriptorTag: 90 (0x5a) [=
>> terrestrial_delivery_system_descriptor] descriptor_length: 11
>> (0x0b) Center frequency: 0x (= 42949672.095 kHz)
>>
>> @@ -219,6 +219,8 @@
>>cDvbTransponderParameters dtp;
>>int Source = cSource::FromData(cSource::stTerr);
>>int Frequency = Frequencies[0] =
>> sd->getFrequency() * 10;
>> + Frequency = Transponder() * 100;//XXX
>> + dsyslog("Frequency = %08X, Transponder = %d",
>> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
>> { 800, 700, 600, 500, 0, 0, 0, 0 };
>> dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
>> Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };
>
> It works. I had to have VDR recreate the channels because it was
> mixing things up with the already existing ones.
>
> As to why the frequency is set to "-10" I don't know (yet), but I
> remember it has always been like this since 2005.
>
> Initial tuning files have always contained all active frequencies
> for their region, because the NIT did not set the center frequencies
> correctly.
>
> It might be because the multiplexed transport streams are generated
> centrally and then distributed to all the base-stations where they
> are emitted as-is but on different frequencies depending on the
> region.
>
> What can we do to get this upstream?
I'm afraid I don't see how this case can be handled correctly.
Maybe somebody else has an idea?
One approach might be to ignore frequencies for DVB-T channels update
during NIT parsing (in France only?).
From my experiences with DVB-T SetTopBoxes using the NIT for
new channel-discovery is rarely done. No customer of my ex-employer was
using it - scanning was entirely based on continuous frequency-band
scanning with a spare demod.
That would be my idea. But I don't know whether this can be easily
applied to VDR.
Well, maybe this works for you?
--- nit.c 2016/12/23 14:16:59 4.4
+++ nit.c 2018/03/09 10:53:38
@@ -218,6 +218,8 @@
SI::TerrestrialDeliverySystemDescriptor *sd =
(SI::TerrestrialDeliverySystemDescriptor *)d;
cDvbTransponderParameters dtp;
int Source = cSource::FromData(cSource::stTerr);
+ if (sd->getFrequency() == 0x)
+continue;
int Frequency = Frequencies[0] = sd->getFrequency() * 10;
static int Bandwidths[] = { 800, 700, 600,
500, 0, 0, 0, 0 };
dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]);
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
On 01.03.2018 10:22, Patrick Boettcher wrote:
On Wed, 28 Feb 2018 11:01:23 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
On 27.02.2018 17:58, Patrick Boettcher wrote:
> On Tue, 27 Feb 2018 16:54:35 +0100
> Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
>
>> Hello Patrick,
>>
>> your scan doesn't contain the NIT, which is where the transponder
>> innformation is broadcast. Can you scan that, too, please?
>
> Hi Klaus,
>
> NIT attached (from another multiplex with the same symptoms).
DVB-DescriptorTag: 90 (0x5a) [=
terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
Center frequency: 0x (= 42949672.095 kHz)
@@ -219,6 +219,8 @@
cDvbTransponderParameters dtp;
int Source = cSource::FromData(cSource::stTerr);
int Frequency = Frequencies[0] =
sd->getFrequency() * 10;
+ Frequency = Transponder() * 100;//XXX
+ dsyslog("Frequency = %08X, Transponder = %d",
sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
{ 800, 700, 600, 500, 0, 0, 0, 0 };
dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };
It works. I had to have VDR recreate the channels because it was mixing
things up with the already existing ones.
As to why the frequency is set to "-10" I don't know (yet), but I
remember it has always been like this since 2005.
Initial tuning files have always contained all active frequencies for
their region, because the NIT did not set the center frequencies
correctly.
It might be because the multiplexed transport streams are generated
centrally and then distributed to all the base-stations where they are
emitted as-is but on different frequencies depending on the region.
What can we do to get this upstream?
I'm afraid I don't see how this case can be handled correctly.
Maybe somebody else has an idea?
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channels getting deleted on new scan
On 08.03.2018 22:38, Klaus Schmidinger wrote: On 08.03.2018 22:13, Timothy D. Lenz wrote: I was hoping it was something simple I could fix in the conf. I haven't worked on it or in linux in a long time and don't have the free time to figure it all out again. I'll have to look at this some other time. I am in the U.S. and these are ATA channels. They each have their own freq. and my guess is that they can use what ever numbers they want since they are on there own freq which they bought. Well, it's funny though that they use exactly the same IDs ;-). Sure they can do whatever they want, but there are a few basic rules that should be followed in order to guarantee a reasonable coexistance. One of them is that channels that are broadcast in the same area (like from the same terrestrial transmitter, on the same cable or the same satellite) should use unique IDs, even if they are on different transponders. One of these IDs is the "transport stream id", which in your case is 207 for both channels. This should be different. For testing I added your new channel list to my channels.conf. Here's what my VDR reported upon startup: Mar 9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf Mar 9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 Mar 9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0 Mar 9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0 With your old list I get no such log entries. So I guess somebody messed up with the TIDs, and the problem should be fixed there. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channels getting deleted on new scan
On 08.03.2018 22:13, Timothy D. Lenz wrote: I was hoping it was something simple I could fix in the conf. I haven't worked on it or in linux in a long time and don't have the free time to figure it all out again. I'll have to look at this some other time. I am in the U.S. and these are ATA channels. They each have their own freq. and my guess is that they can use what ever numbers they want since they are on there own freq which they bought. Well, it's funny though that they use exactly the same IDs ;-). Sure they can do whatever they want, but there are a few basic rules that should be followed in order to guarantee a reasonable coexistance. One of them is that channels that are broadcast in the same area (like from the same terrestrial transmitter, on the same cable or the same satellite) should use unique IDs, even if they are on different transponders. One of these IDs is the "transport stream id", which in your case is 207 for both channels. This should be different. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channels getting deleted on new scan
On 08.03.2018 03:36, Timothy D. Lenz wrote: Haven't used the list in awhile I I think my first reply went to the wrong address. So redoing plus adding some info. 91 is 9.1 KGUN which is the local for ABC Broadcast Network A National Network. The other 9.x channels are assorted small stations. 581 or 58.1 is CW, Another big network. They are very different. 58.2 is some spanish channel using sub channel space. And here is the channel.conf provided by ATSCEPG plugin: ... :@91 KGUN-HD,KGUN-HD:189028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0 ... :@581 KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0 ... The four rightmost numbers are SID:NID:TID:RID. These values are used to compose the "channel id". So these channels have exactly the same "id", and thus are "the same" to VDR. Since you are saying that these are in fact very different channels (presumably with different EPG), it is just plain wrong to use the same values for NID, TID and SID (RID=0 is irrelevant). The question is: who does it wrong? If these values are broadcast as such in the SDT, it´s the broadcaster´s fault. If they are correct (i.e. different for each channel) in the SDT, it´s the ATSCEPG plugin´s fault. To see which values are broadcast, you can set static bool DebugSdt = true; in sdt.c. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channels getting deleted on new scan
On 07.03.2018 00:04, Timothy D. Lenz wrote: So I'm using an old version of VDR, looks like 1.7.15 with the ATSC plugin. Just don't have the time to update everything. I noticed that the 9x locals stopped getting guide data. I did a new scan and the new list worked for 9x but would wipe 58x channels. comparing them, they changed the next to last field entry for 9x from 215 to 207 which is the same as for the 58x. That's the only reason I see. I can switch to 9x ... Using the same NID, TID and SID makes these channels look like "the same" to VDR, and it only assigns the schedule to teh first one it finds in its channel list. Are channels 91 and 581 carrying the same content, and this supposed to have the same EPG? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
On 01.03.2018 11:39, Patrick Boettcher wrote:
On Thu, 1 Mar 2018 10:22:10 +0100
Patrick Boettcher <patrick.boettc...@posteo.de> wrote:
On Wed, 28 Feb 2018 11:01:23 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> On 27.02.2018 17:58, Patrick Boettcher wrote:
> > On Tue, 27 Feb 2018 16:54:35 +0100
> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> >
> >> Hello Patrick,
> >>
> >> your scan doesn't contain the NIT, which is where the transponder
> >> innformation is broadcast. Can you scan that, too, please?
> >
> > Hi Klaus,
> >
> > NIT attached (from another multiplex with the same symptoms).
>
> DVB-DescriptorTag: 90 (0x5a) [=
> terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
> Center frequency: 0x (= 42949672.095 kHz)
>
> @@ -219,6 +219,8 @@
>cDvbTransponderParameters dtp;
>int Source = cSource::FromData(cSource::stTerr);
>int Frequency = Frequencies[0] =
> sd->getFrequency() * 10;
> + Frequency = Transponder() * 100;//XXX
> + dsyslog("Frequency = %08X, Transponder = %d",
> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
> { 800, 700, 600, 500, 0, 0, 0, 0 };
> dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
> Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };
It works. I had to have VDR recreate the channels because it was
mixing things up with the already existing ones.
As to why the frequency is set to "-10" I don't know (yet), but I
remember it has always been like this since 2005.
Here is the explanation why the frequency field in French DVB-T shall
not be used, (cf. CSA-Profil-de-signalisationv3.4.pdf, page 30,
terrestrial_delivery_system_descriptor):
le terrestrial delivery_system_descriptor diffusés dans la NIT
correspond au cas général. En effet, la NIT ne décrit pas de façon
exhaustive le réseau actuel d’émetteurs, mais l’organisation des
services des multiplex diffusés : ainsi les fréquences des multiplex
renseignées par le paramètre centre_frequency ont une valeur fixée à
0x. Ces fréquences ne sont pas à prendre en compte
It says, grosso modo, that the NIT does not describe the network in an
exhaustive manner, but it does for services. Le field centre_frequency
contains the value 0x and is not to be taken into consideration.
My last message was sent before I received your log.
I'll take a further look...
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
On 01.03.2018 10:22, Patrick Boettcher wrote:
On Wed, 28 Feb 2018 11:01:23 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
On 27.02.2018 17:58, Patrick Boettcher wrote:
> On Tue, 27 Feb 2018 16:54:35 +0100
> Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
>
>> Hello Patrick,
>>
>> your scan doesn't contain the NIT, which is where the transponder
>> innformation is broadcast. Can you scan that, too, please?
>
> Hi Klaus,
>
> NIT attached (from another multiplex with the same symptoms).
DVB-DescriptorTag: 90 (0x5a) [=
terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
Center frequency: 0x (= 42949672.095 kHz)
@@ -219,6 +219,8 @@
cDvbTransponderParameters dtp;
int Source = cSource::FromData(cSource::stTerr);
int Frequency = Frequencies[0] =
sd->getFrequency() * 10;
+ Frequency = Transponder() * 100;//XXX
+ dsyslog("Frequency = %08X, Transponder = %d",
sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
{ 800, 700, 600, 500, 0, 0, 0, 0 };
dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };
It works. I had to have VDR recreate the channels because it was mixing
things up with the already existing ones.
As to why the frequency is set to "-10" I don't know (yet), but I
remember it has always been like this since 2005.
Can you please send me the log line that was generated by the added dsyslog()
statement?
Initial tuning files have always contained all active frequencies for
their region, because the NIT did not set the center frequencies
correctly.
It might be because the multiplexed transport streams are generated
centrally and then distributed to all the base-stations where they are
emitted as-is but on different frequencies depending on the region.
What can we do to get this upstream?
I suggest checking sd->getFrequency() against 0x and if it has that
value,
use Transponder() * 100 instead. I'd just like to see whether the log really
confirms this.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
On 27.02.2018 17:58, Patrick Boettcher wrote:
On Tue, 27 Feb 2018 16:54:35 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
Hello Patrick,
your scan doesn't contain the NIT, which is where the transponder
innformation is broadcast. Can you scan that, too, please?
Hi Klaus,
NIT attached (from another multiplex with the same symptoms).
Transport_stream_ID: 1 (0x0001)
Original_network_ID: 8442 (0x20fa) [= >>ERROR: not (yet) defined...
Report!<<]
reserved_1: 15 (0x0f)
Transport_descriptor_length: 205 (0x00cd)
DVB-DescriptorTag: 90 (0x5a) [=
terrestrial_delivery_system_descriptor]
descriptor_length: 11 (0x0b)
Center frequency: 0x (= 42949672.095 kHz)
I assume this is the problem: the NIT doesn't contain a proper frequency entry.
To avoid problems with NITs that are broadcast on other transponders, VDR checks
whether the frequency contained in the NIT is the same as the transponder that
is currently broadcast. This check will always fail in your case.
For a quick test whether my assumtion is correct, please try the following
patch:
--- nit.c 2016-12-23 15:16:59.0 +0100
+++ nit.c 2018-02-28 10:58:38.595483737 +0100
@@ -22,7 +22,7 @@
#define MAXNETWORKNAME Utf8BufSize(256)
// Set to 'true' for debug output:
-static bool DebugNit = false;
+static bool DebugNit = true;//XXX false;
#define dbgnit(a...) if (DebugNit) fprintf(stderr, a)
@@ -219,6 +219,8 @@
cDvbTransponderParameters dtp;
int Source = cSource::FromData(cSource::stTerr);
int Frequency = Frequencies[0] = sd->getFrequency() * 10;
+ Frequency = Transponder() * 100;//XXX
+ dsyslog("Frequency = %08X, Transponder = %d",
sd->getFrequency(), Transponder());//XXX
static int Bandwidths[] = { 800, 700, 600,
500, 0, 0, 0, 0 };
dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]);
static int Constellations[] = { QPSK, QAM_16, QAM_64,
QAM_AUTO };
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
Hello Patrick, your scan doesn't contain the NIT, which is where the transponder innformation is broadcast. Can you scan that, too, please? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs
On 25.02.2018 15:26, Patrick Boettcher wrote:
Hi list,
since some time (1-2 years) I noticed that the DVB-T channels do not
show EPG anymore. I'm not sure what is the root-cause: either it
was the migration of French DVB-T to HD (in 2016) or an update of VDR.
Anyway, this morning I took the time to figure out what is wrong and
here is what I found.
In short, the channel-ID generated from the one received in the EIT
does not correspond to a known channel-ID from the channel list, and
VDR drops the whole section:
In cEIT::cEIT (from eit.c) we see
tChannelID channelID(Source, getOriginalNetworkId(), getTransportStreamId(),
getServiceId());
cChannel *Channel = Channels->GetByChannelID(channelID, true);
and channel is NULL in my case.
I added some debug prints to GetByChannelID() in the search loop:
printf("sid: %d == %d, %s, %s %d\n",
Channel->Sid(),
sid,
(const char *)ChannelID.ToString(),
(const char *)Channel->GetChannelID().ToString(),
Channel->GetChannelID() == ChannelID);
And here is an example of what I get:
sid: 517 == 517, T-8442-2-517, T-0-506-517 0
The internal channel ID of vdr reads T-0-506-517. 517 is the SID, 506
is the radio-channel frequency in MHz. This is the right internal
channel for this EIT-section.
The EIT-channel-ID is telling me that 8442 is the original network ID
and 2 might be the radio-channel ID.
I tweaked the operator==() of ChannelID to make it work, but not in a
contributable manner.
How should this be fixed correctly?
Is this a regression introduced somewhere?
Can it be solved by configuration?
Hello Patrick,
where did the channel with ID T-0-506-517 come from in the first place?
What happens if you delete that channel from VDR's channel list and tune
to the transponder? Does it create the channel with the correct ID?
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not cleaning .del directories
On 19.01.2018 18:48, Teemu Suikki wrote:
I'm starting to think that maybe my problem IS caused entirely by this
softhddevice bug. Because my softhddevice keep freezing quite
frequently, I have added a shutdown command that detaches softhddevice
and leaves vdr running. And then when I watch something, I'm pressing
buttons and using menus and there might be timers recording etc, so
vdr never becomes idle enough to do the housekeeping?
I tried to understand the code, but I'm having difficulties. :) in
vdr.c, only place that sets LastInteract is this:
Interact = Menu ? Menu : cControl::Control(); // might have
been closed in the mean time
if (Interact) {
LastInteract = Now;
eOSState state = Interact->ProcessKey(key);
if (state == osUnknown && Interact != cControl::Control()) {
So.. Does this mean that softhddevice's dummy player has menu open all
the time? softhddevice.cpp doesn't have really anything menu-related
in the dummy player, all those methods must be inherited from main vdr
class.
Only thing that looks suspicious is this, dummy player's ProcessKey:
eOSState cSoftHdControl::ProcessKey(eKeys key)
{
if (SuspendMode == SUSPEND_NORMAL && (!ISMODELESSKEY(key)
|| key == kMenu || key == kBack || key == kStop)) {
delete Player;
Player = NULL;
Resume();
SuspendMode = NOT_SUSPENDED;
return osEnd;
}
return osContinue;
}
Should it really return osContinue all the time?
As long as a cPlayer (or a cReceiver, for that matter) is attached to
a cDevice, VDR will not perform its housekeeping tasks. This is to
avoid any problems during replay or recording, possibly caused by
heavy disk access.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not cleaning .del directories
On 18.01.2018 21:26, Teemu Suikki wrote: Ok, I did some debugging. First of all, I noticed something weird that perhaps is not even related to this problem. In vdr.c there is a check: if ((Now - LastInteract) > ACTIVITYTIMEOUT if softhhddevice is detached or suspended, "Now - LastInteract" is always zero, and vdr can never enter housekeeping tasks. This must be a bug in softhddevice? I guess so. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not cleaning .del directories
On 18.01.2018 08:54, Teemu Suikki wrote: Ok, it might be the same thing. I added some debug as Klaus suggested. After restart, vdr instantly deleted a few directories.. So at least it works sometimes. :) Perhaps the cleanup fails if Plex or another vdr is currently accessing the same files? Maybe vdr then thinks it has deleted them, and does not try again. In cRemoveDeletedRecordingsThread::Action() VDR tries to get a lock on the video directory. If this fails, it can't remove deleted recordings. Please add some debug output to this function, to see whether it is called and whether it gets the lock. If it doesn't get the lock while Plex is running, try without Plex. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not cleaning .del directories
On 16.01.2018 19:44, Teemu Suikki wrote: Hi, I just experienced weird problem. My hard drive became 100% full. But I noticed that there are tons of .del directories, some dating from months ago.. VDR hasn't removed them! What could cause this? I see entries in log: low disk space while recording, trying to remove a deleted recording... Jan 16 08:23:06 puucee vdr: [30504] removing recording xxx.del And these recordings ARE removed really. But the normal background cleaning does not happen. This is somehow related to the fact that I now have Plex Media Server sitting on the VDR recordings directory. But still I could remove the .del directories easily from the command line. After manually deleting them, disk is now only 85% full.. And that's 4TB drive. :) So there were quite a bit of .del directories. Do you have anything going on that causes frequent "user ineraction" with VDR? Try adding some debug output to RemoveDeletedRecordings() and maybe also to cRemoveDeletedRecordingsThread::Action() (both in recording.c) to find out what might be causing this. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Race condition when executing recording hook
On 14.12.2017 08:26, Harald Milz wrote: I don't know how to handle this properly. My suggestion would be to ignore the channel pid change during an active recording on this channel, and defer the change until the recording is finished_if_ "-r something" is set on the command line. If you ignore the PID change, you might risk getting a broken or incomplete recording. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with DVB-T2 on frontend 1
On 28.11.2017 21:12, Marko Mäkelä wrote:
Hallo Klaus,
On Tue, Nov 28, 2017 at 11:28:13AM +0100, Klaus Schmidinger wrote:
On 27.11.2017 19:55, Marko Mäkelä wrote:
On Sun, Nov 26, 2017 at 07:21:58PM +0200, Marko Mäkelä wrote:
Hi all,
I recently got a USB adapter "Astrometa DVB-T2" that I would like to use with
VDR. It comprises two frontends:
/dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T)
/dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C)
Apart from these files, in /dev/dvb/adapter0 I can see the following:
demux0 dvr0 net0
It seems to me that the dvbdevice.c of VDR 2.3.8 assumes that all these files
exist for all frontends. But there is no demux1, dvr1, or net1 on my system.
That's right, VDR assumes that if there is a frontend1 there is also demux1
and dvr1.
In dvbdevice.h, I think that the macros DEV_VIDEO, DEV_DVB_VIDEO, DEV_DVB_AUDIO
are unused and the definitions could be removed.
DEV_DVB_VIDEO is still used by the dvb[sh]ddevice plugins.
Sorry, I should have thought of output plugins. rpihddevice does not refer to
any of these.
For cDvbTuner::SetFrontend() the cDvbTuner::adapter and cDvbTuner::frontend are already fixed. For my device, frontend0 should only be valid for DVB-T, while frontend1 is valid for DVB-T2 and DVB-C. How to handle these known-invalid combinations? By 'return true'? Or should I rather hack
cDvbTuner so that it opens a file descriptor for each frontend, and then chooses the appropriate one in cDvbTuner::SetFrontend() based on frontendType?
Which devices does VDR create at startup?
Please post the related log entries.
Attached are two complete logs from /var/log/messages for plain VDR 2.3.8
startup.
On both startup attempts, channels.conf (attached) contains only DVB-T2
entries, and the default channel is free-to-view (YLE TV1 HD). The
channels.conf was converted by dvb-format-convert version 1.12.3:
dvb-format-convert -I DVBV5 -O VDR dvb_channel.conf channels.conf
The first attempt is with the /dev/dvb/adapter0 as is. VDR expectedly claims
that it cannot tune to the channel with the DVB-T frontend.
The second startup is for a tweak where I removed /dev/dvb/adapter0/frontend0 and renamed frontend1 to frontend0. On this startup, VDR will not complain anything, but it will not find any signal either. It properly detects the MN88473, but perhaps improperly claims that it provides DVB-T along with
DVB-T2 and DVB-C.
Well, from the information that VDR gets from the driver, it does support
DVB-T, -T2 and -C:
frontend 0/0 provides DVB-T,DVB-T2,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256
("Panasonic MN88473")
If this is not correct, I assume it's a driver problem.
But since the channel you are initially tuning to is DVB-T2, anyway, it doesn't
really
matter if VDR thinks the frontend can handle DVB-T, too.
I'm afraid I can't say why tuning fails, though.
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with DVB-T2 on frontend 1
On 27.11.2017 19:55, Marko Mäkelä wrote: On Sun, Nov 26, 2017 at 07:21:58PM +0200, Marko Mäkelä wrote: Hi all, I recently got a USB adapter "Astrometa DVB-T2" that I would like to use with VDR. It comprises two frontends: /dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T) /dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C) Apart from these files, in /dev/dvb/adapter0 I can see the following: demux0 dvr0 net0 It seems to me that the dvbdevice.c of VDR 2.3.8 assumes that all these files exist for all frontends. But there is no demux1, dvr1, or net1 on my system. That's right, VDR assumes that if there is a frontend1 there is also demux1 and dvr1. In dvbdevice.h, I think that the macros DEV_VIDEO, DEV_DVB_VIDEO, DEV_DVB_AUDIO are unused and the definitions could be removed. DEV_DVB_VIDEO is still used by the dvb[sh]ddevice plugins. For cDvbTuner::SetFrontend() the cDvbTuner::adapter and cDvbTuner::frontend are already fixed. For my device, frontend0 should only be valid for DVB-T, while frontend1 is valid for DVB-T2 and DVB-C. How to handle these known-invalid combinations? By 'return true'? Or should I rather hack cDvbTuner so that it opens a file descriptor for each frontend, and then chooses the appropriate one in cDvbTuner::SetFrontend() based on frontendType? Which devices does VDR create at startup? Please post the related log entries. Last, I noticed that there exists cDvbDevice::BondDevices() for bonding multiple DVB-S devices to the same dish. I guess it is not feasible to extend this to my DVB-T/DVB-T2 device, because I would suppose that unlike the DVB-S devices, my USB stick does not support concurrent reception from both frontends at the same time. Device bonding is only meant for DVB-S devices. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR locking up
On 27.11.2017 09:04, Teemu Suikki wrote:
I made this change few hours ago, but I'm still waiting for the
problem to appear.. Obviously it now is working 100%. :)
Does "working 100%" mean that youre not getting any of these error
messages any more? Not even once?
Klaus
2017-11-27 0:08 GMT+02:00 Klaus Schmidinger <klaus.schmidin...@tvdr.de>:
On 26.11.2017 19:09, Teemu Suikki wrote:
I know I'm replying to a year old thread, but I'm having the exact same
problem.
I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
drivers to latest version.. Now I have this problem, that randomly VDR
starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
log. It will not jam right away, but after maybe 30-60min it is
jammed.
Some VDR functions like timers seem to still work, but the GUI is stuck.
This is VDR 2.2.0 from yavdr repos.
Any ideas?
Even though this might be a driver bug, perhaps vdr of softhddevice
could simply stop displaying the channel after the first error?
I can't contribute anything regarding the driver or softhddevice,
but I guess limiting the log message to, say, one message per minute
could save the program from getting stuck.
That's assuming your log is actually flooded with thousands of
entries like that.
To qickly verify this could you please precede the line
esyslog("ERROR: TS packet not accepted in Transfer Mode");
in transfer.c with
static int Counter = 0;
if ((Counter++ % 1) == 0)
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR locking up
On 26.11.2017 19:09, Teemu Suikki wrote:
I know I'm replying to a year old thread, but I'm having the exact same problem.
I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
drivers to latest version.. Now I have this problem, that randomly VDR
starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
log. It will not jam right away, but after maybe 30-60min it is
jammed.
Some VDR functions like timers seem to still work, but the GUI is stuck.
This is VDR 2.2.0 from yavdr repos.
Any ideas?
Even though this might be a driver bug, perhaps vdr of softhddevice
could simply stop displaying the channel after the first error?
I can't contribute anything regarding the driver or softhddevice,
but I guess limiting the log message to, say, one message per minute
could save the program from getting stuck.
That's assuming your log is actually flooded with thousands of
entries like that.
To qickly verify this could you please precede the line
esyslog("ERROR: TS packet not accepted in Transfer Mode");
in transfer.c with
static int Counter = 0;
if ((Counter++ % 1) == 0)
Klaus
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature request: sort recording like extrecmenu plugin does
On 08.11.2017 12:31, ca...@nekanali.nl wrote: Would it be possible to add a new sort mode for the recordings in the new stable vdr release? On top directories sorted on date from date high to -low Below that the recordings from date high to low. Later option is now only available on low to high date sort Can you suggest a patch for that? Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 2.3.8
VDR developer version 2.3.8 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.8.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.7-2.3.8.diff MD5 checksums: 2afe8b899b3af1967320c216c1315f3e vdr-2.3.8.tar.bz2 d6ef77c644432dde9a01a05280ca5228 vdr-2.3.7-2.3.8.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. Note: This is a "holiday release" ;-) - I'm going on vacation and just wanted to make the current source available before that. There will be at least one more developer version before the final stable version 2.4.0. The changes since version 2.3.7: - Updated links in the INSTALL file (thanks to Chris Mayo). - Fixed detecting whether a CAM replies to queries, which didn't work on some systems since the implementation of RI_HOST_CONTROL (reported by Daniel Scheller). - Added some missing locks when calling functions from cStatus or cSkin*, and added some text to status.h and skins.h, explaining the locking situation when such functions are called. - Fixed a possible crash in cStateLockLog. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Now skipping a leading '/' in AddDirectory(), to avoid double slashes (reported by Chris Mayo). - Fixed drawing very long menu titles in the LCARS skin (reported by Matthias Senzel). - Timers are now linked to EPG events even if they are inactive. By default Events that are linked to inactive timers are marked with 'I' and 'i', depending on whether the timer would record the entire Event or only part of it. The function cSkinDisplayMenu::SetItemEvent() now has an additional parameter named TimerActive, which indicates whether the timer that would record this event (if any) is active. A plugin may react on this when displaying a menu line for an event. The old version of cSkinDisplayMenu::SetItemEvent() (without the TimerActive parameter) is still there for backwards compatibility. It may be removed in a future version, so plugin authors should switch to the new one. - Now using readdir() instead of readdir_r(), if GLIBC version 2.24 or newer is used (suggested by Frank Neumann). - Added a note to the log, indicating that no further invalid lock sequences will be reported until VDR is restarted. - Whenever a change is made to the recordings in the video directory, the SVDRP command UPDR is now sent to all peer VDRs, so that they will update their recordings list. This is especially useful if one VDR mounts the video directory of an other one into a subdirectory. - SVDRP peering can now be limited to the default SVDRP host (see MANUAL for details). Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 2.3.6
VDR developer version 2.3.6 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.6.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.5-2.3.6.diff MD5 checksums: eab982df03da492a7d263718a8c487c2 vdr-2.3.6.tar.bz2 84a53afa495740bfdf9aab4b8900df99 vdr-2.3.5-2.3.6.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 2.3.5: - Added backtrace functions for debugging (see cBackTrace in thread.h). - Added checking the correct sequence of locking global lists (with help and suggestions from Jasmin Jessich). At the first occurrence of an invalid locking sequence, the 20 most recent locks will be written to the log file, followed by a backtrace that led to the call in question. This code can be activated by defining the macro DEBUG_LOCKSEQ in thread.c (which is on by default). When debugging an actual invalid locking sequence, you can additionally define the macro DEBUG_LOCKCALL in thread.c, which will add information about the caller of each lock. Note that this may cause some stress on the CPU, therefore it is off by default. - The file Make.config.template now reacts on DEBUG=1 in the 'make' command line, and disables code optimizations by setting -O0 (thanks to Jasmin Jessich). This can be helpful when backtracing highly optimized code. You may want to 'make distclean' before running 'make' with a modified setting of DEBUG, to make sure all object files are newly compiled. - Fixed the locking sequence when dumping EPG data. - Fixed the locking sequence when starting a recording. - The Makefiles now use the macro $(Q) instead of a plain '@' in front of their commands, so that verbosity can be controlled by the user (suggested by Jasmin Jessich). Add VERBOSE=1 to the 'make' call in the VDR source directory to see the actual commands that are executed. Plugin authors should modify their makefiles accordingly, by simply preceeding the respective commands with '$(Q)' and inserting '@echo XX $@' (where XX is one of the character combinations listed in the release note for version 2.3.5) before the command. The newplugin script has also been modified accordingly. Note that if you build a plugin directly in the plugin's own source directory, the $(Q) macro won't be defined and commands will be displayed. You can add Q=@ to the make call to have it less verbose (provided the plugin's Makefile was modified as described above). - Added clearing CiResourceHandlers before shutting down the plugin manager. - Fixed a double channel switch when pressing the Channel+/- keys while no menu or channel display is open. - Fixed generating k_Release key events for LIRC remote controls (due to the short timeout another normal key was sometimes put into the queue after the generated release). Also removed some code redundancy and added some buffer checks. - Now using a separate mutex to fix the race between SVDRP CHAN and cDevice::HasProgramme(), because the previous fix caused a deadlock (reported by Derek Kelly). - Fixed a possible crash in case the SVDRP connection to a peer VDR is terminated while getting remote timers. - Fixed the locking sequence when creating a new timer from the Schedules menu. - Fixed the locking sequence when switching between 'Now', 'Next' and 'Schedule' in the Schedules menu. Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 2.3.5
Unfortunately two things slipped under my radar in the previous upload, so I had to do it again. Here are the links again, with the new checksums: VDR developer version 2.3.5 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.5.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.4-2.3.5.diff MD5 checksums: 01fabef4d20ec01f11d53354d99a9642 vdr-2.3.5.tar.bz2 a9cc12e0bf76942c6435a36c429c6b42 vdr-2.3.4-2.3.5.diff Sorry about that. Klaus ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
