Yesterday, I finally bought external storage for my Raspberry Pi based
VDR setup, a Samsung Portable SSD T7. It supports USB 3, but it also
works on the Raspberry Pi 2's USB 2.0 and does not consume too much
power. My old tower PC case based system that I had set up in 2004 has
now been replaced with something that is better in every thinkable
respect: power consumption, noise (passive cooling, no HDDs), speed, and
size (not much larger than the remote control unit).
Hardware:
* …
[View More]Raspberry Pi 2
* Pi TV hat
* TV hat case
* an IR receiver attached via soldered wires to the TV hat, at GPIO pin 18
* a remote control unit (from an old Hauppauge Nova-T PCI card)
* Samsung Portable SSD T7 (1 TB)
Software:
* Raspberry OS Legacy installed on a MicroSD card, with no GUI
* sudo apt install ir-keytable
* VDR 2.6.3 (or 2.6.2) compiled from source
* https://github.com/reufer/rpihddevice/ compiled from source
* "make install" to /usr/local
My /boot/config.txt includes the following lines:
dtoverlay=gpio-ir,gpio_pin=18
dtparam=audio=on
gpu_mem=256
In /etc/rc_maps.cfg (the configuration file of ir-keytable), ensure that
there is a line like the following that will match the remote control
unit that you are using:
* * hauppauge.toml
The above works for several RC5 based Hauppauge remote control units.
To prevent the Power button on the remote control unit from shutting
down the entire system, add the following to the [Login] section of
/etc/systemd/logind.conf:
HandlePowerKey=ignore
The default is HandlePowerKey=poweroff.
Use mkfs.ext4 to replace the FAT file system of the only partition of
the T7. There is no need to change the partitioning or specify a block
size or alignment, because the physical block size is reported as 512
bytes. Optionally, you may set a label by executing something like this:
tune2fs -L VDR /dev/sda1
You may create a mount point:
sudo mkdir -m 000 /video
Then, add a line like this to /etc/fstab to have the storage mounted
automatically:
LABEL=VDR /video ext4 defaults,noatime,nofail 0 1
You may replace the LABEL=VDR with whatever symbolic link you have in
/dev/disk/by-label (see also tune2fs above). On my system, I actually
wrote PARTUUID=33d32895-01 because there is a symbolic link
/dev/disk/by-partuuid/33d32895-01 that identifies the partition.
Once the storage is mounted, execute the following:
sudo mkdir /video/video
sudo chown pi:pi /video/video
The next step is to configure VDR to start up correctly. I have some
configuration files in /var/lib/vdr. For testing, I used to start VDR
manually from the command line, and shut it down by choosing "restart"
from the OSD menu. Now I want it to restart automatically, but only if
suitable USB storage has been plugged in:
sudo tee /etc/systemd/system/vdr.service << EOF
[Unit]
After=systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service
After=getty(a)tty1.service
After=video.mount
Conflicts=getty(a)tty1.service
ConditionPathExists=/video/video
[Service]
User=pi
ExecStart=/usr/local/bin/vdr --no-kbd --lirc=/dev/lirc0 -Prpihddevice -v /video/video -s /var/lib/vdr/vdr-shutdown.sh
TimeoutStartSec=infinity
Type=idle
Restart=on-failure
RestartSec=1s
TTYVTDisallocate=yes
[Install]
Alias=display-manager.service
EOF
This will replace the getty process on virtual terminal 1 (tty1). If the
storage is not plugged within 90 seconds from startup (I do not know how
to configure that timeout), then an error message will appear on the
console. No getty will be started on tty1 in any case; you can always
log in from tty2 by pressing Alt+F2.
The shutdown script /var/lib/vdr/vdr-shutdown.sh does not work as
intended yet:
#!/bin/sh
if [ "$5" = 1 ]
then
sudo service vdr stop
sudo umount /video
sudo udisksctl power-off -b /dev/sda
fi
The first step appears to terminate the shell script, because the shell
is a subprocess of VDR. So, the storage will remain mounted and powered
on. I guess that we need to launch a separate "vdr-shutdown" service
that would take care of the remaining steps. Has someone already
implemented something like this?
After the "umount" and "udisksctl" commands are executed, it is safe to
unplug the storage. The LED of the SSD will shortly change color and
then turn off during the execution of the "udisksctl" command.
What I am also missing is a udev rule that would automatically mount the
storage and attempt to start up VDR as soon as the storage is plugged
in. Currently, I have to manually execute the following if I plug in the
drive to an already running system:
sudo mount /video
sudo service vdr start
This configuration provides a rather simple user interface for VDR. No
keyboard or mouse is needed, just the remote control unit, a display,
and optionally the USB cable, if the system has other uses that are
independent of VDR.
For timed recordings, I think that on the Raspberry Pi, it is easiest to
let the VDR process run all the time. Starting up the Pi based on timer
would require additional hardware.
One thing that I'd like to improve in that regard is to let VDR shut
down all tuners when the system is idle. This could be based on an
inactivity timer or an explicit user action, such as pressing a button
on the remote control. The video output would shut off, and the tuner
would be powered off, except when needed for something (EPG scan,
recording). As soon as a button is pressed on the remote control unit,
the user interface would spring back to life.
Happy holidays,
Marko
[View Less]
VDR version 2.6.3 is now available at the official VDR GIT archive
git://git.tvdr.de
You can also get the latest stable version with
git clone --branch stable/2.6 git://git.tvdr.de/vdr.git
or as a tar archive with
http://git.tvdr.de/?p=vdr.git;a=snapshot;h=refs/tags/2.6.3;sf=tbz2
This version fixes a few bugs that came up after the release of version 2.6.2.
The changes since version 2.6.2:
- Fixed a compiler warning.
- Fixed generating the index file in the cutter (…
[View More]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
[View Less]
Because of the heap-use-after-free race condition that was rather easily
reproducible with AddressSanitizer (-fsanitize=address), I thought that
I should finally try to learn to use ThreadSanitizer (TSAN,
-fsanitize=thread in GCC and clang).
https://clang.llvm.org/docs/ThreadSanitizer.html
Because VDR makes use of POSIX thread synchronization primitives, no
additional instrumentation via <sanitizer/tsan_interface.h> should be
necessary.
Before C++11 defined a memory model for …
[View More]multi-threaded applications,
semantics around shared data structures were rather unclear, and I would
guess that most multi-threaded pre-C++11 code bases would trip
ThreadSanitizer. Also, multi-threaded CPUs were rare in the early days,
and the Total Store Order of the x86 is very forgiving, compared to the
weak memory model of ARM (see
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html for some
examples).
To silence one prominent source of TSAN warnings in the cThread
destructor, I applied the attached patch. It is not ideal, because
std::atomic defaults to std::memory_order_seq_cst while
std::memory_order_relaxed would likely suffice here.
Even after applying the first patch, a simple test with no DVB receiver
device and no valid data directory would still produce a couple of data
race reports (see the end of this message). I recorded a trace of such a
run with "rr record" (https://rr-project.org) and debugged it in "rr
replay". Unsurprisingly, I did not find actual evidence of a race
condition.
Finally, I figured out what is causing the first report:
cThread::description is not protected by cThread::mutex. Possibly, most
cThread data members (including cThread::active) should be protected by
cThread::mutex?
With both attached patches applied, the report of the first race will
disappear. The second race is apparently about some memory that is
allocated inside opendir(). I did not figure it out yet.
Related to this, cThread::Cancel() especially when invoked with
WaitSeconds=-1 looks problematic to me, and I see that VDR is invoking
pthread_detach() and never invoking pthread_join(). The second patch
includes an attempt to clean this up as well.
Both patches are just a proof of concept; I did not test them beyond the
simple failing-to-start VDR run under TSAN. Unfortunately, TSAN is not
available for my primary VDR hardware, running on 32-bit ARM.
With best regards,
Marko
vdr: error while reading '/var/lib/vdr/sources.conf'
vdr: error while reading '/var/lib/vdr/channels.conf'
vdr: no primary device found - using first device!
==================
WARNING: ThreadSanitizer: data race on vptr (ctor/dtor vs virtual call) (pid=96847)
Write of size 8 at 0x7ffc7f773e60 by main thread:
#0 cThread::~cThread() /dev/shm/vdr/thread.c:249 (vdr+0x1d72b8)
#1 cEpgDataReader::~cEpgDataReader() /dev/shm/vdr/epg.h:236 (vdr+0xa956b)
#2 main /dev/shm/vdr/vdr.c:731 (vdr+0xa956b)
Previous read of size 8 at 0x7ffc7f773e60 by thread T2:
#0 cThread::StartThread(cThread*) /dev/shm/vdr/thread.c:293 (vdr+0x1d76d9)
Location is stack of main thread.
Location is global '<null>' at 0x000000000000 ([stack]+0x1fe60)
Thread T2 'epg data reader' (tid=96855, finished) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001 (libtsan.so.2+0x5e686)
#1 cThread::Start() /dev/shm/vdr/thread.c:316 (vdr+0x1d6fe0)
#2 main /dev/shm/vdr/vdr.c:804 (vdr+0xaa477)
SUMMARY: ThreadSanitizer: data race on vptr (ctor/dtor vs virtual call) /dev/shm/vdr/thread.c:249 in cThread::~cThread()
==================
==================
WARNING: ThreadSanitizer: data race (pid=96847)
Write of size 8 at 0x7b04000005a0 by main thread:
#0 free ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:706 (libtsan.so.2+0x47e82)
#1 cString::~cString() /dev/shm/vdr/tools.c:1097 (vdr+0x1e52df)
#2 cxa_at_exit_wrapper ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:389 (libtsan.so.2+0x2dee3)
Previous read of size 8 at 0x7b04000005a0 by thread T1:
#0 opendir ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3271 (libtsan.so.2+0x4c641)
#1 cReadDir::cReadDir(char const*) /dev/shm/vdr/tools.c:1553 (vdr+0x1ea8bd)
#2 cVideoDirectoryScannerThread::ScanVideoDir(char const*, int, int) /dev/shm/vdr/recording.c:1439 (vdr+0x180620)
#3 cVideoDirectoryScannerThread::Action() /dev/shm/vdr/recording.c:1433 (vdr+0x180bfc)
#4 cThread::StartThread(cThread*) /dev/shm/vdr/thread.c:293 (vdr+0x1d76ea)
Thread T1 'video directory' (tid=96854, running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001 (libtsan.so.2+0x5e686)
#1 cThread::Start() /dev/shm/vdr/thread.c:316 (vdr+0x1d6fe0)
#2 cRecordings::Update(bool) /dev/shm/vdr/recording.c:1554 (vdr+0x175387)
#3 main /dev/shm/vdr/vdr.c:788 (vdr+0xaa3f8)
SUMMARY: ThreadSanitizer: data race /dev/shm/vdr/tools.c:1097 in cString::~cString()
==================
ThreadSanitizer: reported 2 warnings
[View Less]
Another day, another sanitizer.
After fixing issues reported by -fsanitize=address yesterday, I gave
-fsanitize=undefined a try. The GCC documentation points to the clang
documentation:
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
The issues related to cControl::player were tricky. In the end, I
figured it out after setting UBSAN_OPTIONS=print_stacktrace=1 and
setting a breakpoint on _Unwind_Backtrace(). The name of the reporting
function in my system was …
[View More]__ubsan_handle_dynamic_type_cache_miss(),
nothing about "vptr". Also, the diagnostics was misleadingly pointing to
the body of the constructor, and not the initializer list where a data
member was being assigned to before the base class had been initialized.
The -fsanitize=undefined in clang might report more things.
Next I may give -fsanitize=thread a try.
GCC does not implement -fsanitize=memory (checking for the use of
uninitialized memory) at all. It will require clang and libc++ (not
libstdc++) and that all libraries except libc are built with
-fsanitize=memory. If you are familiar with Valgrind's default memcheck
tool, it is roughly comparable to the combination of -fsanitize=address
and -fsanitize=memory.
Marko
[View Less]
VDR version 2.6.2 is now available at the official VDR GIT archive
git://git.tvdr.de
You can also get the latest stable version with
git clone --branch stable/2.6 git://git.tvdr.de/vdr.git
or as a tar archive with
http://git.tvdr.de/?p=vdr.git;a=snapshot;h=refs/tags/2.6.2;sf=tbz2
This version fixes a few bugs that came up after the release of version 2.6.1.
The changes since version 2.6.1:
- Added UPDATE-2.6.0, which was missing in the official 2.6.0 release.
- …
[View More]Fixed unexpected calls of the '-r' script when a recording is interrupted and
the timer has not yet finished.
- Now dropping capabilities after opening terminal.
- Now assuming the lock when removing deleted recordings even if the disk is full
(reported by Claus Muus).
- When checking whether a recording is still active, VDR no longer checks whether the
index file is being written, but rather checks for the presence of a '.timer' file.
The cutter now writes a dummy '.timer' file with timer ID '0' to make this work
for recordings that are currently being edited.
- Fixed a possible crash if an editing process is canceled while the edited
recording is being replayed.
- Added a warning if an attempt is made to obtain a write lock twice from the same thread.
- Fixed default values for DVB-T (thanks to Winfried Köhler and Jose Angel).
- Removed some unnecessary locks from SVDRPClientHandler.
- Fixed a possible deadlock in case two SVDRP clients send each other POLL commands
at the same time.
- Added a missing 'const' to cTimers::GetTimerForEvent() (reported by Markus Ehrnsperger).
- Added a chapter about locking to PLUGINS.html (suggested by Markus Ehrnsperger).
- Implemented parsing frame rate and image size for MPEG2, H.264 and H.265 (thanks
to Christoph Haubrich).
- Using the frame rate parsed from the stream, with fall back to determining it from
PTS values.
- Fixed printing/scanning values for systems where %ld doesn't work for time_t.
- Added support for kernel based LIRC driver (thanks to Marko Mäkelä). Use the
command line option '--lirc=/dev/lirc0' to use this. Requires kernel version 5.10
or above.
- Added periodic calls to malloc_trim(0) to reduce memory consumption (thanks to
Onur Sentürk).
- Fixed regenerating the index file of a recording in case it is present, but empty
(reported by Stefan Herdler).
- Added missing rounding when dividing frequencies in processing the NIT (thanks to
Winfried Köhler).
Homepage: http://www.tvdr.de
Facebook: https://www.facebook.com/VideoDiskRecorder
Have fun!
[View Less]
Hi all,
I was an active VDR user from about 2004 to 2010 when my children were
younger and there was a need to record TV programs for them. The old
setup was more or less abandoned when I got a smart TV and the family
started to use video streaming services.
Some years ago, I got a Raspberry Pi 2 B and an Astrometa DVB-T2 USB
stick that also includes an infrared receiver. Because its bundled
remote control unit (RCU) has much fewer buttons than the one that I got
with the Hauppauge Nova-…
[View More]T PCI 90002 years ago, I configured lircd to
translate the RC5 codes from the old RCU. For output, I am using
rpihddevice.
Yesterday, I upgraded to VDR 2.5.6 and rpihddevice 1.0.4 from
git://projects.vdr-developer.org/vdr-plugin-rpihddevice.git while
keeping the rest of the Raspbian 9.13 mostly intact.
I installed the self-built software simply by replacing the original
/usr/bin/vdr that was part of the distribution's vdr 2.2.0 package, and
copying the plugin to /usr/lib/vdr/plugins/. It might not be the
cleanest solution, but it worked for me.
I had some trouble with Systemd, which I resolved by creating a
configuration file:
# cat > /etc/systemd/system/vdr.service << EOF
[Service]
Restart=on-failure
RestartSec=1s
ExecStart=/usr/bin/vdr
TimeoutStartSec=infinity
EOF
# systemctl daemon-reload
# service lightdm stop
# service vdr start
I did not double-check it, but I understood that this could entirely
bypass the /etc/init.d/vdr script, which would invoke the runvdr script
(which normally runs vdr in a loop). If I choose Restart from the VDR
menu, systemd will restart it nicely.
I did not configure the Power button yet. Currently, VDR complains that
no -s parameter is given when I press the Power button on the RCU.
Ideally, I think that VDR should suspend the live video output and
somehow inform Systemd that the entire system may be suspended, as far
as VDR is concerned. (Of course, only if there are no recordings or
remote connections active to VDR.) Then, if nothing else prevents the
system from being shut down or suspended, Systemd would do it based on
its configuration.
Years ago, I developed some patches and configuration at
https://iki.fi/msmakela/software/vdr/ to achieve something like this on
my old system, and I would now like to revive this somehow. Ideally, the
Power button would shut down the DVB receiver and display some
indication on the OSD or the video frame buffer that the output has been
suspended.
If my Raspberry Pi were not an "always-on server" that runs some other
services as well, I might want to reimplement the "wake-on-RCU" hardware
that is generating a wake-on-LAN signal via the Nova-T PCI card,
possibly by extending
https://spellfoundry.com/product/sleepy-pi-2-usb-c/ or a similar product
that would implement a wake-on-timer for the Raspberry Pi. Then, the
system would power up nicely either by RCU or by a recording timer.
Integrating the wake-on-timer logic with Systemd could be another
challenge. I might try this on PC hardware, which already supports
wake-on-timer out of the box. A quick search turned up a promising
starting point:
https://www.freedesktop.org/software/systemd/man/systemd.timer.html
The motivation of this exercise is to have a stand-alone VDR front/back
end installation that plays nicely with Systemd, without reinventing any
logic around scheduling, startup, and shutdown.
Maybe one day, once some more progress has been made with Wayland and
when using a Raspberry Pi model with more GPU memory, one could press
the Power button on the RCU and have the live TV pop up either
fullscreen or in a window, on top of the graphical desktop (which would
be available for generic use).
Best regards,
Marko
[View Less]
> On 16.07.22 14:07, Richard F wrote:
> >/I've just updated to VDR V2.61 after a long time on V2.2, using the
> same config and the epgtableid0 (2.4.0) plug-in. />//>/The issue I'm seeing is that when VDR is restarted, it doesn't seem
> to be reading/respecting the epg.data file. />/... /
> Is this the only EPG handler you have installed, or are there others?
> If so, make sure this one is installed FIRST.
>
> Klaus
Actually after more testing it seems the …
[View More]table 0 EPG entries are always being overwritten after EPG scans, not just at startup.
The only EPG handler I have is XMLTV using SVDRP: once a day a script clears the existing EPG then inserts new entries in table 0
The correct table 0 entries can be seen in VDR for a while, then get overwritten after automatic scans.
I do need both types, as some channels / programmes don't have current data in XMLTV, only DVB.
My command line is:
/usr/bin/vdr -c /etc/vdr -E /mnt/lvm0/TV/epg.data -l 2 --no-kbd -P streamdev-server -P epgsearch -v 1 -l /var/log/epgsearch.log -m /usr/local/bin/sendEmail.pl -P epgtableid0 -P vnsiserver -P vdrmanager -P dummydevice -r /usr/local/bin/vdr-auto -u vdr --vfat -v /mnt/lvm0/TV
(same as V2.20)
Thx/Richard
[View Less]
Hi all,
TL;DR: How could I connect VDR to the kernel-provided /dev/lirc0 device?
Is there a dummy lircd implementation that would simply open /dev/lirc0
in LIRC_MODE_SCANCODE and relay its contents over a socket?
As far as I understand, LIRC was first implemented as a user-space
daemon that would decode a bitstream (via various bit-banging
interfaces) into scancodes that would then be relayed over a socket to
the final application.
At some point (before I started to use VDR in 2005 or …
[View More]2006), support for
remote control units was expanded in the Linux kernel, and also a
translation into input events was implemented. In VDR, the input event
interface can be used via the "remote" plugin (vdr -Premote). I think
that this is what I always used with VDR, first using the cx88 driver
(Hauppauge Nova-T PCI 90002) and now trying to use a USB stick
(rtl82xxu, Astrometa DVB-T2) on a Raspberry Pi.
The input event interface is mapping the stream of IR messages to
"key-down", "key-up" and "key-repeat" events, which adds some
inaccuracy. For the rtl82xxu, the repeat logic is broken: key-repeat or
key-down events for long key presses are only being sent intermittently.
The fix in
https://patchwork.linuxtv.org/project/linux-media/list/?series=7322
improves it a lot. The USB interface for delivering IR events in a
128-byte buffer is prone to race conditions, and that cannot be fixed
without changing the device firmware.
There is also a kernel-based interface (such as /dev/lirc0) that can
provide scan codes to end applications. Both the input event interface
and this one would be polled by "ir-keytable -t".
I would like to use the /dev/lirc0 interface with VDR, so that VDR has a
chance to react to each and every IR message that is sent by the remote
control unit. I think that this would minimize the disturbance caused by
the broken USB protocol of the rtl82xxu. It is OK if one LIRC scancode
of a long keypress (say, browsing a list of recordings) would be lost;
another one would be sent in 113ms by the RC5 protocol. With the input
event driver, a lost IR message would result in a bogus key-up event, a
bogus key-down event, and a long delay before key-repeat events are
generated again.
My initial attempt at using /dev/lirc0 did not work:
vdr -v /var/lib/vdr/video --no-kbd --lirc=/dev/lirc0 -Prpihddevice
That is, pressing any buttons on the remote control unit did not have
any effect, and VDR did not start in the "learning mode" either, even
after I renamed the remote.conf that it is opening at startup. It
appeared that a read() on "/dev/lirc0" would block indefinitely, but I
did not check that.
I noticed that VDR's lirc.c is explicitly opening a Unix domain socket
to the LIRC device, while "ir-keytable -t" would invoke open(2) followed
by ioctl(lircfd, LIRC_SET_REC_MODE, &mode):
https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/keytable.c
My goal would be to use the Hauppauge remote control with the Astrometa
DVB-T2 stick and for it to be as responsive as it was back in 2006 with
my patched cx88 driver. My implementation back then directly mapped IR
messages to input events:
(1) produced a key-down event for the first IR message
(2) discard the first repeated IR message (to have an initial delay)
(3) produced key-repeat events for subsequent IR messages (every 113ms)
(4) if any key-up events were produced, that would be after a timeout
that would be reset in (1),(2),(3).
I think that it should be possible to implement this behaviour in a
dummy lircd that translates /dev/lirc0 into a socket. Before I implement
that from the scratch, I would like to know if something similar already
exists.
Related to this, I submitted a fix to the kernel to set the "repeat"
flag in the LIRC scan codes when appropriate:
https://patchwork.linuxtv.org/project/linux-media/list/?series=8338
Without this fix, it should still be possible to detect repeat key
events (long key presses) by comparing successive scancodes. For
protocols that do not include a toggle flag (like RC5 does), it might be
possible to compare timestamps to distinguish long button presses from
multiple short presses.
Best regards,
Marko
[View Less]
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 not
seem to have been updated for years; it does not mention Raspberry Pi at
all, despite it being a viable alternative for more than 10 years.
I was an active VDR user from 2004 or 2005, when I …
[View More]built a PC based
setup, using a "budget" DVB-T card (Hauppauge Nova-T PCI). That system
was never upgraded to DVB-T2; instead, we got a flat screen TV with a
built-in tuner. Gradually, as our children got older, recordings were
made and watched less often.
We mostly stopped using VDR about 10 years ago. Since then, I have made
some attempts to "come back", initially, using a Raspberry Pi 2 B and an
Astrometa USB DVB-T/T2 stick.
This month, I purchased a TV HAT case and the DVB-T/T2 uHAT for my
Raspberry Pi 2 B. As far as I understand, the plexiglass TV HAT case
should fit the Raspberry Pi 2, 3, and 4. The LED holes next to the
MicroSD card slot are on the wrong side for the Pi 2, but everything
fits perfectly.
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 trouble with. By design, its infrared
receiver will lose messages when a button is being held down, because a
128-byte buffer of the microcontroller would overflow, and there is no
way to use it as a ring buffer (I tried). A kernel maintainer came up
with some experimental patches that significantly improved the
situation, but every few of seconds some key-repeat events were still
being lost.
Out of that effort, a tiny patch from me was included in the Linux
kernel, to have the kernel's LIRC interface set the "repeat" flag for
all IR protocols:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
The Pi TV HAT is missing an infrared receiver out of the box. I soldered
an IR receiver module to some thin wires, isolating the legs with heat
shrink tube. The other ends of the thin wires I soldered to some pads
next to the connector: 3.3V at pin 1, ground at pin 6 (or 9), and the
signal output to GPIO 18 (pin 12). GPIO 17 at pin 11 would have worked
as well. I made the IR receiver module stick out from a vent hole on the
top, because my initial attempt of keeping the module inside the
transparent lid of the case did not work that well.
The module can pick up IR signal some 8 meters away.
The software configuration was easy:
(1) Add the following line to /boot/config.txt:
dtoverlay=gpio-ir,gpio_pin=18
(2) Execute "sudo apt install ir-keytable"
(3) Edit /etc/rc_maps.cfg to load a suitable table for your remote
control unit. To reuse the old remote control unit that I had, I wrote
an entry
* * hauppauge.toml
(4) Reboot for the config.txt change to take effect.
For me, the remote control unit appeared in /dev/input/event0 as well as
/dev/lirc0 and some buttons (such as the number keys) would directly
work in the /dev/tty1 textual login prompt.
For starting up VDR, I used a command like this:
vdr -v /var/lib/vdr/video --no-kbd -Prpihddevice -P'remote -i /dev/input/event0'
Yes, the Pi TV HAT was detected automatically; I did not have to do
anything special. I had previously used the same VDR configuration with
an Astrometa USB stick.
This is with a copy of https://github.com/reufer/rpihddevice with some
critical patches applied. (The issues and a pull request that I opened
in January 2022 are still unattended.)
The experience with the Pi TV HAT is simply great. The Sony tuner in the
Pi TV HAT produces an error-free bit stream and switches transponders
very quickly. The kernel GPIO IR driver is rock solid. I think that the
user experience is at least as good as with my old PC setup.
Some buttons on my remote control unit were unreliable. Using an expired
debit card, I was able to pry open the grey Hauppauge remote control
unit, starting next to the IR LED. I guess I should upload pictures of
the internals somewhere, to help others open theirs.
Next, I plan to attach some external storage for recordings. A USB 3.0
NVMe drive would allow faster backups (when detached from the Raspberry
Pi 2) and an upgrade to a Pi 3 or 4.
On the software side, I am thinking to apply my kernel patch and to
write a "kernel LIRC plugin" for VDR that would allow me to use
/dev/lirc0 for the input. I would prefer to use the lower-level
interface where each IR message corresponds to an event. I do not like
the key-repeat timer logic of the kernel's input event driver. And I
never liked the user-space lircd.
With best regards,
Marko
[View Less]