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
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
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
On Thu, 21 Sep 2023 08:28:51 +0200
Torsten Duwe wrote:
> On Wed, 20 Sep 2023 10:09:29 +0200
> Harald Milz wrote:
>
> > In fact I tried to boot satip-axe from a USB stick but for unknown
> > reasons the box stuck to the original FW. :-(
>
> You must not partition the medium, but use it in
On Wed, 20 Sep 2023 10:09:29 +0200
Harald Milz wrote:
> In fact I tried to boot satip-axe from a USB stick but for unknown
> reasons the box stuck to the original FW. :-(
You must not partition the medium, but use it in "USB floppy disk mode".
Put a fat32 on it, with idl4k.scr in the root dir,
Hi Torsten,
long time no hear! Good you're still around!
On Tue, Sep 19, 2023 at 10:43:01AM +0200, Torsten Duwe wrote:
> There is an alternative firmware for this box
In fact I tried to boot satip-axe from a USB stick but for unknown reasons the
box stuck to the original FW. :-(
After
Hi Harald!
On Sun, 17 Sep 2023 19:49:39 +0200
Harald Milz wrote:
> Hi all,
>
> I recently got a stone-aged Digibit R1 to replace an even older PCI-E card.
[...]
There is an alternative firmware for this box
https://github.com/perexg/satip-axe/blob/master/dist/README
Hi all,
I recently got a stone-aged Digibit R1 to replace an even older PCI-E card. My
satellite antenna points at Astra S19.2E and Hotbird S13E, 2 Dual LNBs in Quad
configuration. However, the Digibit device seems not to find anything on S13E.
Not sure if I need DiSeQC with SATIP but I set:
in
*** CALL FOR PAPERS - MUM 2023 ***
*** DEADLINE EXTENDED ***
Deadline for Full and Short Papers: 29th of August 2023, AoE
* We apologize if you receive multiple copies of this CfP *
*For the online version of this Call, please visit:
https://mum-conf.org/2023/index.php?web=papers *
* MUM
*** CALL FOR DEMOS- MUM 2023***
*Demos Submission Deadline: 9th of October 2023, AoE*
* We apologize if you receive multiple copies of this CfP *
*For the online version of this Call, please visit:
https://mum-conf.org/2023/index.php?web=demos *
* MUM 2023, the 22nd International Conference on
*** CALL FOR DOCTORAL CONSORTIUM - MUM 2023***
*Doctoral Consortium Submission Deadline: 9th of October 2023*
* We apologize if you receive multiple copies of this CfP *
*For the online version of this Call, please visit:
https://mum-conf.org/2023/index.php?web=doctoral *
* MUM 2023, the 22nd
***CALL FOR WORKSHOPS AND TUTORIALS – MUM 2023***
Deadline for Workshops and Tutorials: August 22nd, 2023 (AoE)
***Workshop proposals will be peer-reviewed and archived in the ACM DL***
* We apologize if you receive multiple copies of this CfP *
*For the online version of this Call, please
Hi,
15 years ago I've accidently deleted an XFS drive full of recordings.
And even in those (*.vdr) days foremost wasn't the most successful tool
in order to recover recordings.
What I've done:
1. I've made an (dd-) image
2. I used a modified version of genindex to scan the image
The
Hi
I’ve had VDR running for almost 20 years now. Not continuously of course and
occasionally I have updated the system and added more disk and new MB and CPU
and so.
My problem is that I had an external disk for saving recordings which did not
fit on the internal hard disk and now the
*** CALL FOR POSTERS - MUM 2023 ***
Deadline for Posters: 9th of October 2023, AoE
* We apologize if you receive multiple copies of this CfP *
*For the online version of this Call, please visit:
https://mum-conf.org/2023/index.php?web=posters *
* MUM 2023, the 22nd International Conference on
From: Thomas Petazzoni
It is supported by glibc and uClibc (which both define __GLIBC__) but
not musl (which doesn't define __GLIBC__). On musl, it doesn't do
anything because musl has a basic NLS implementation. Even
gettext-tiny defines _nl_msg_cat_cntr as a dummy symbol in its stub
From: Roberto Oliveira
vdr package uses some macros like HOST_NAME_MAX, NAME_MAX, which are defined
in limits.h.
Needs to be explicitly included on ppc64le and for all archs for debug build.
Downloaded from
https://git.alpinelinux.org/aports/tree/community/vdr/include-missing-limits.patch
malloc_trim is a GNU extension and therefore not present in non-glibc C
libraries such as musl. Wrapping this in an ifdef fixes musl builds.
Signed-off-by: Bernd Kuhls
---
vdr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/vdr.c b/vdr.c
index 0f426e61..bc4902de 100644
--- a/vdr.c
+++
From: Carlo Landmeter
Downloaded from
https://git.alpinelinux.org/aports/tree/community/vdr/musl-compat.patch
Initial commit:
https://git.alpinelinux.org/aports/commit/?id=140248605cee4a0160f80b47ce77a823be2f740a
Signed-off-by: Bernd Kuhls
---
i18n.h | 2 +-
osd.c| 2 +-
thread.c |
Mon, Apr 17, 2023 at 09:14:30PM +0300, Marko Mäkelä wrote:
The "rtcwake -m show" straight after the reboot indicated that the
alarm is off. I read all journal entries between the two rtcwake
commands, which were helpfully logged. The only thing I found was a
kernel boot message that said that
Mon, Apr 17, 2023 at 04:38:11PM +0300, Marko Mäkelä wrote:
Mon, Apr 17, 2023 at 10:17:03AM +0200, g.bruno wrote:
here a longer thread at problems with rtcwake (in German):
https://forum.ubuntuusers.de/topic/rtcwake-geht-nicht-mehr/#post-9369451
Thank you. I am not going to use rtcwake on
Mon, Apr 17, 2023 at 10:17:03AM +0200, g.bruno wrote:
here a longer thread at problems with rtcwake (in German):
https://forum.ubuntuusers.de/topic/rtcwake-geht-nicht-mehr/#post-9369451
Thank you. I am not going to use rtcwake on those 2 problematic laptops
for anything real, but out of
Hallo,
here a longer thread at problems with rtcwake (in German):
https://forum.ubuntuusers.de/topic/rtcwake-geht-nicht-mehr/#post-9369451
Perhaps it might be useful for someone,
GBruno
Am 16.04.23 um 19:54 schrieb Marko Mäkelä:
Today, I tested rtcwake on several x86 or x86-64 based
Reminds me of the nvram-wakeup lotto back in the day.
Am 16. April 2023 19:54:03 MESZ schrieb "Marko Mäkelä" :
>Today, I tested rtcwake on several x86 or x86-64 based computers.
>
>The outcome:
>
>(1) Suspend to RAM (say, "rtcwake -m mem -s 10"):
>* Success: Every system.
>(2) Wake-on-timer
Today, I tested rtcwake on several x86 or x86-64 based computers.
The outcome:
(1) Suspend to RAM (say, "rtcwake -m mem -s 10"):
* Success: Every system.
(2) Wake-on-timer ("rtcwake -m no -s 120 && shutdown -h now" or "rtcwake
-m off -s 120"):
* Success: Lenovo Thinkpad X220 (2012?), and a
Wed, Apr 12, 2023 at 08:29:48AM +0200, Harald Milz wrote:
Let me put my unsolicited €0.02 in. My mindset is pretty hackerish as
well, but I'm also an engineer thinking in efficiency terms. The raspi
is what it is, and it is a nice building block for many jobs. If I
wanted to build a vdr, I'd
Let me put my unsolicited €0.02 in. My mindset is pretty hackerish as well, but
I'm also an engineer thinking in efficiency terms. The raspi is what it is, and
it is a nice building block for many jobs. If I wanted to build a vdr, I'd
either let the raspi run permanently (given its low energy
Tue, Apr 11, 2023 at 05:41:24PM +0200, Joerg Riechardt wrote:
https://github.com/j1rie/IRMP_STM32
Thank you. This is a user space solution, with the benefit that it is
not limited to Linux. I think that it would be good to mention this at
Am 11.04.2023 um 16:36 schrieb Marko Mäkelä:
Can you point to an example?
https://github.com/j1rie/IRMP_STM32/blob/master/irmplircd/vdrshutdown
writes the time of the next vdr timer start into the alarm of the STM32
https://github.com/j1rie/IRMP_STM32/tree/master/stm32IRalarm/Linux.
That alarm
Tue, Apr 11, 2023 at 12:23:44PM +0200, Joerg Riechardt wrote:
Maybe still not what you want, but how other guys do it:
https://www.vdr-portal.de/forum/index.php?thread/133092-ein-weiterer-ir-einschalter-f%C3%BCr-den-rpi/=1319903=mosfet
Am 11.04.2023 um 07:41 schrieb Marko Mäkelä:
Mon, Apr 10, 2023 at 07:08:29AM -0700, VDRU VDRU wrote:
Why don't you make life easy and just add a $5-10 rtc module and be
done with it?
Based on this discussion
https://forums.raspberrypi.com/viewtopic.php?t=210662 one would need
more than that.
Mon, Apr 10, 2023 at 07:08:29AM -0700, VDRU VDRU wrote:
Why don't you make life easy and just add a $5-10 rtc module and be
done with it?
Based on this discussion
https://forums.raspberrypi.com/viewtopic.php?t=210662 one would need
more than that. "Shutting down" the Raspberry Pi will
Why don't you make life easy and just add a $5-10 rtc module and be
done with it?
On Mon, Apr 10, 2023 at 6:08 AM Marko Mäkelä wrote:
>
> Some time ago, I created the wiki page
> https://www.linuxtv.org/vdrwiki/index.php/Systemd that describes much of
> my VDR installation.
>
> On my Raspberry
Some time ago, I created the wiki page
https://www.linuxtv.org/vdrwiki/index.php/Systemd that describes much of
my VDR installation.
On my Raspberry Pi, there is no real-time-clock. My low-tech solution
for waking up VDR for recordings is that I set an alarm on my phone, to
remind me to turn
Hi Martin,
On Wed, Mar 29, 2023 at 08:21:21PM +0200, Martin Dummer wrote:
> I miss lines like these:
>
> Mar 28 19:28:25 vdr vdr: [21100] SATIP: Adding server
> '192.168.166.129|DVBC-4|FRITZ!Box 6490 Cable' Bind: default Filters:
> none CI: no Quirks: n
> one
Oh, these were 30 or 40 lines
Am 29.03.23 um 18:09 schrieb Harald Milz:
Initially, all seems to look good:
Hello Harald,
I miss lines like these:
Mar 28 19:28:25 vdr vdr: [21100] SATIP: Adding server
'192.168.166.129|DVBC-4|FRITZ!Box 6490 Cable' Bind: default Filters:
none CI: no Quirks: n
one
These lines give you the
Tue, Feb 21, 2023 at 10:47:28AM +0100, Klaus Schmidinger wrote:
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
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.
On 15/02/2023 16:51, Klaus Schmidinger wrote:
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
On 18/02/2023 11:10, Marko Mäkelä wrote:
Wed, Feb 15, 2023 at 05:17:55PM +0100, Klaus Schmidinger wrote:
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)
On 15/02/2023 17:17, Klaus Schmidinger wrote:
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);
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
Wed, Feb 15, 2023 at 05:17:55PM +0100, Klaus Schmidinger wrote:
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)
Wed, Feb 15, 2023 at 06:01:46PM +0100, Klaus Schmidinger wrote:
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
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
@@
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 =
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
On 07/02/2023 07:59, Marko Mäkelä wrote:
Tue, Feb 07, 2023 at 12:54:16AM +0100, Udo Richter wrote:
Two-ended buffers are pretty good when used correctly, but nowadays
they have a small chance of triggering memory ordering issues, where
it is possible that written data to the buffer is still
Tue, Feb 07, 2023 at 12:54:16AM +0100, Udo Richter wrote:
Two-ended buffers are pretty good when used correctly, but nowadays
they have a small chance of triggering memory ordering issues, where it
is possible that written data to the buffer is still stuck in a distant
cache, while the updated
On 06.02.23 23:29, Klaus Schmidinger wrote:
It is supposed to be shared by *exactly* two threads.
One only writing 'head', the other only writing 'tail'.
Two-ended buffers are pretty good when used correctly, but nowadays they
have a small chance of triggering memory ordering issues, where it
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
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
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
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
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
Beside preventing crashes with vdr-2.6.3 this is required to
get vdr to work properly with the gcc thread sanitizer.
---
ringbuffer.c | 18 +-
ringbuffer.h | 3 +++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/ringbuffer.c b/ringbuffer.c
index 902c887..1c24df2
This change fixes the following issue:
==15457==ERROR: AddressSanitizer: SEGV on unknown address 0x02d0 (pc
0x7fd2f4301710 bp 0x7fd2b5552a30 sp 0x7fd2b5552988 T228)
==15457==The signal is caused by a READ memory access.
==15457==Hint: address points to the zero page.
#0
Sun, Jan 22, 2023 at 02:52:03PM +0200, Marko Mäkelä wrote:
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
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;
Sat, Dec 24, 2022 at 11:33:19AM +0200, Marko Mäkelä wrote:
Yesterday, I finally bought external storage for my Raspberry Pi based
VDR setup, a Samsung Portable SSD T7.
I have now documented my setup in the following wiki pages:
https://www.linuxtv.org/vdrwiki/index.php/Systemd
Tue, Dec 27, 2022 at 11:15:29PM +0100, Martin Dummer wrote:
Am 27.12.22 um 21:49 schrieb Marko Mäkelä:
First, I removed the custom /etc/fstab entry. Everything will be
controlled by systemd as follows:
On systemd-systems, each line in /etc/fstab is automatically converted
by a binary
Am 27.12.22 um 21:49 schrieb Marko Mäkelä:
First, I removed the custom /etc/fstab entry. Everything will be
controlled by systemd as follows:
On systemd-systems, each line in /etc/fstab is automatically converted
by a binary "systemd-fstab-generator" into "xxx.mount" units. So what
you do
Tue, Dec 27, 2022 at 12:04:00PM +0200, Marko Mäkelä wrote:
I might configure some more, such as:
* Write some udev rule so that when the USB storage is unplugged and
replugged, the file system will be auto-mounted and VDR service will
be started.
* Restore /etc/systemd/logind.conf to
Mon, Dec 26, 2022 at 01:34:48AM +0100, Udo Richter wrote:
No, just replace the call to vdr in the service with a call to a runvdr
script (any of the ones floating around, or just a three-liner), and in
that script, after vdr ends, do whatever cleanup you need to do.
I see. That could certainly
On 25.12.22 20:47, Marko Mäkelä wrote:
However, I'd say the most clean way is to include the unmount and
udiskctrl into the vdr shutdown itself, so these commands run within
the vdr service after the vdr process stops. That way you just have to
fire the service stop and are done.
Do you mean
Sun, Dec 25, 2022 at 01:10:51PM +0100, Udo Richter wrote:
On 24.12.22 10:33, Marko Mäkelä wrote:
then
sudo service vdr stop
sudo umount /video
sudo udisksctl power-off -b /dev/sda
fi
The first step appears to terminate the shell script, because the shell
is a subprocess of VDR. So, the
On 24.12.22 10:33, Marko Mäkelä wrote:
then
sudo service vdr stop
sudo umount /video
sudo udisksctl power-off -b /dev/sda
fi
The first step appears to terminate the shell script, because the shell
is a subprocess of VDR. So, the storage will remain mounted and powered
on. I guess that
Yesterday, I finally bought external storage for my Raspberry Pi based
VDR setup, a Samsung Portable SSD T7. It supports USB 3, but it also
works on the Raspberry Pi 2's USB 2.0 and does not consume too much
power. My old tower PC case based system that I had set up in 2004 has
now been
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
Wed, Dec 14, 2022 at 10:21:10AM +0100, Klaus Schmidinger wrote:
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 ;-).
The only problem that I am currently aware of is
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,
Sat, Dec 10, 2022 at 07:30:50PM +0200, Marko Mäkelä wrote:
Because of the heap-use-after-free race condition that was rather
easily reproducible with AddressSanitizer (-fsanitize=address), I
thought that I should finally try to learn to use ThreadSanitizer
(TSAN, -fsanitize=thread in GCC and
Sat, Dec 10, 2022 at 07:30:50PM +0200, Marko Mäkelä wrote:
Finally, I figured out what is causing the first report:
cThread::description is not protected by cThread::mutex.
Sorry, I failed to notice that even after applying both patches, both
TSAN reports are still there. The race condition
Because of the heap-use-after-free race condition that was rather easily
reproducible with AddressSanitizer (-fsanitize=address), I thought that
I should finally try to learn to use ThreadSanitizer (TSAN,
-fsanitize=thread in GCC and clang).
https://clang.llvm.org/docs/ThreadSanitizer.html
On 05.12.22 16:54, Marko Mäkelä 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 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
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 =
Tue, Dec 06, 2022 at 01:24:09PM +0200, Marko Mäkelä wrote:
The first attached patch includes your suggested fixes and nothing that
you opposed so far. The second attached patch fixes the following 2
issues. I agree that the NumCamSlots==0 case could be solved in a nicer
way.
I tried to make
Mon, Dec 05, 2022 at 04:08:45PM +0100, Klaus Schmidinger wrote:
Instead if typecasting I guess I'll rather do it this way:
This worked as well.
If x2 ever becomes negative, something else must have gone wrong.
The actual culprit is cDvbSubtitleConverter::FinishPage(), which was
invoking
Hi Klaus,
Tue, Dec 06, 2022 at 12:05:02AM +0100, Klaus Schmidinger wrote:
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?
Because I am
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.
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
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
Another day, another sanitizer.
After fixing issues reported by -fsanitize=address yesterday, I gave
-fsanitize=undefined a try. The GCC documentation points to the clang
documentation:
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
The issues related to cControl::player were
Wed, Nov 30, 2022 at 02:01:13PM +0100, Klaus Schmidinger wrote:
VDR version 2.6.2 is now available at the official VDR GIT archive
git://git.tvdr.de
Thank you, Klaus!
While debugging hangs or crashes during the shutdown of rpihddevice (see
https://github.com/reufer/rpihddevice/pull/6
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
On 28/11/2022 18:17, Marko Mäkelä wrote:
Mon, Nov 28, 2022 at 12:27:08PM +, Richard F wrote:
FYI I'm using the powersaving patch on a system with an Astrometa USB
stick + an old Winfast PCI receiver, and I see 2-3W reduction when
the Astrometa frontend is shut down:
I only tested with a
Mon, Nov 28, 2022 at 12:27:08PM +, Richard F wrote:
FYI I'm using the powersaving patch on a system with an Astrometa USB
stick + an old Winfast PCI receiver, and I see 2-3W reduction when the
Astrometa frontend is shut down:
I only tested with a single receiver. Your patch may very well
I conducted this test without applying the patch
https://github.com/glenvt18/vdr/commit/b368f67d00d0b466ae36028efb9336e81f77dba8
As far as I can tell, even with that patch the EPG parser could keep
running, because the patch does not set the variable InhibitEpgScan.
That would explain
Sun, Oct 17, 2021 at 10:52:11PM +0300, Marko Mäkelä wrote:
I noticed that VDR is consuming about 5% of the CPU power according to
"top". Could it not be made more event-based? It might be interesting
to check with "powertop" how many wakeups per second there are, and
with "perf record" and
Klaus,
Yes I do still have the issue, I reverted back to 2.20 for now as table
0 functionality is critical for me. I also didn't have luck with the
Astrometa DVB-T2 receiver on either current or 2.20, without a udev
script to copy frontend1 over frontend0, which then works fine. Ugly
but
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
Martin Dummer kirjoitti maanantaina 14. marraskuuta 2022 12.16.56 EET:
> Am 14.11.22 um 10:55 schrieb Mikko Tuumanen:
> > Are there any vdr-related irc channels or matrix rooms?
> I know about #gentoo-vdr on libera.chat but it's a quiet place
I created a Matrix space: #vdr:ellipsis.fi and a
Am 14.11.22 um 10:55 schrieb Mikko Tuumanen:
Are there any vdr-related irc channels or matrix rooms?
I know about #gentoo-vdr on libera.chat but it's a quiet place
___
vdr mailing list
vdr@linuxtv.org
Hello
Are there any vdr-related irc channels or matrix rooms?
Which hashtag we should use when mentioning VDR on Mastodon?
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I thought that it would be a good idea to make use of the built-in LIRC
driver of the Linux kernel. Currently, there is a --lirc option for
interfacing to a user-space driver (lircd), but nothing for using the
kernel driver. The "remote" plugin can interface with /dev/input/event*
but not with
Hi,
AFAIK the rpihddevice plugin does not work on RPI4, so consider this on
making hw upgrade. I'm using 3 VDR clients in my home, all 3 are
different RPI3 versions, and they are running rock solid for at least 4
or 5 years.
Upgrading from Pi2 to Pi3 does make sense, as -at least in my
Hi all,
I regret that I did not buy the Pi TV HAT earlier. The USB stick is
simply garbage compared to it.
The Astrometa USB stick switches channels very slowly and the tuner
very frequently produces errors in the bit stream, when using a good
outdoor aerial that other devices have no
Hi all,
Much of this message would probably belong to some wiki page, along with
some photographs that I made. Before starting to write this, I checked
https://vdr-projects.github.io and did not find any hardware projects.
The hardware section of the VDR wiki at https://www.linuxtv.org does
Unfortunately a very long maintenance period. Login is possible, but nothing
else.
What to do without "our" VDR portal?! :o(
Markus
Von: vdr im Auftrag von Narcis Garcia
Gesendet: Montag, 12. September 2022 19:10
An: VDR - SPM
Betreff: Re: [vdr]
1 - 100 of 15834 matches
Mail list logo
