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)
I guess it is similar to this one; just a slightly different plastic
case with some more ventilation holes:
http://blog.palosaari.fi/2014/09/naked-hardware-18-astrometa-amdvb-t2-v2.ht…
The hardware appears to work fine, once I copied the
/lib/firmware/…
[View More]dvb-demod-mn88473-01.fw from somewhere. The firmware
upload has failed at least once on the Raspberry Pi 2 (using Linux
4.9.59), but never on another machine that runs a 4.13.0 kernel.
I did not yet get the infrared remote control to produce anything in
evtest.
With dvbv5-zap (after running dvbv5-scan), I can tune into DVB-T2
channels like this:
dvbv5-zap -a 0 -f 1 -c dvb_channel.conf 'Yle TV1 HD' -r
After this, I can play the video and audio stream on the Raspberry Pi 2:
omxplayer /dev/dvb/adapter0/dvr0
Unless I explicitly specify the options -a 0 -f 1, then dvbv5-zap will
fail to find any DVB-T2 senders, because it apparently defaults to
frontend0, which is DVB-T only.
In VDR 2.3.8, I have only been able to view DVB-T from the first
frontend.
When I did a trick and renamed /dev/dvb/adapter0/frontend1 to frontend0
before starting VDR, VDR no longer complained that the DVB-T2 channels
(which I converted from the dvb_channel.conf to channels.conf with
dvb-format-convert) not being available, but it did not seem to receive
anything from these channels either.
Also, after using dvbv5-scan or dvbv5-zap, I sometimes have to invoke
w_scan to "reset" the hardware so that VDR can receive DVB-T channels.
I would like to receive and record DVB-T and DVB-T2 on this setup. I am
willing to try patches or do some programming myself, but I would
appreciate some hints to get started.
Marko
[View Less]
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.…
[View More]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?
Thanks for any help.
best regards,
--
Patrick.
[View Less]
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, so
I made a work-around with network namespaces like this:
First, a helper script to create a network namespace if not already created
and run a command there:
/usr/local/sbin/Nsenter_vdr2
----------------------------------…
[View More]------
#!/bin/bash
mp=/home/vdr/vdr2/netns
addr=192.168.8.2/24
gw=192.168.8.1
if ! mountpoint -q $mp ; then
unshare --net=$mp true || exit 1
ip link add vdr2eth type veth peer name eth0 netns $mp
nsenter --net=$mp sh -c "ip link set eth0 up \
&& ip a add $addr dev eth0 \
&& ip link set lo up \
&& ip -4 route add default via $gw"
fi
if test -n "$SUDO_USER" -a "$SUDO_USER" != root ; then
exec nsenter --net=$mp sudo -u "$SUDO_USER" "$@"
else
exec nsenter --net=$mp "$@"
fi
----------------------------------------
The name space mount point is a reqular file (empty) and not a directory.
Nsenter script creates a veth pair named vdr2eth on the outside and eth0
inside.
I used /etc/network/interfaces to set vdr2eth address, but it coud be done in
the Nsenter script too.
allow-hotplug vdr2eth
iface vdr2eth inet static
address 192.168.8.1
netmask 255.255.255.0
Then I run the recording instance of vdr normally on the outside and add
permissions for 192.168.8.2 in svdrphosts and streamdevhosts.
Viewing vdr is run in the network namespace something like this:
#!/bin/bash
if test "$1" = "nsentered" ; then
shift
exec vdr -D- "-Psofthddevice -f" -i 1 -Pstreamdev-client "$@"
exit 1
fi
while true ; do
sudo Nsenter_vdr2 "$0" nsentered "$@"
done
I don't need to peer the viewing vdr to other computers in the local network.
If that were the case, then the outside end of the veth pair would need to be
bridged with the physical network card of the machine.
[View Less]
If there is anyone using the TT S2 6400 with the supplied IR receiver,
remote and the "remote" plugin, could they please post a few lines from
the remote.conf file?
Thanks,
Richard
Hello everyone! I'm from Argentina, and up to last month I've been using
VDR 1.7.262 with an ISDB-T USB adapter. It works really good, but the
last week I've been trying to upgrade to VDR 2.2 and I've found a
problem with ISDB-T cards: they are not supported.
As I'm really interested in using VDR, I was digging inside the code and
found a partial solution for this problem: as ISDBT is the same as DVBT,
I've changed the way delivery system is queried. My changes are applied
in a cloned repo at …
[View More]github:
https://github.com/chrodriguez/vdr/commit/dadbca57c2dc55c1c53b4fa8f68b56728…
That's the only change I've made. Now I can enjoy my fresh upgraded VDR
installation!!
I think a better refactor should be made, but for now it's working
perfectly deployed as a docker container:
https://registry.hub.docker.com/u/chrodriguez/vdr
Thanks for this wonderfull project!
--
Lic. Christian A. Rodriguez
@car_unlp
[View Less]
/vdr-convert is a tool to accurately transcode VDR1.x and VDR2.x TV
recordings, including all valid streams - video, audio (including
AC3/DTS 5.1), Audio Description (AD), and DVB subtitles - into more
compressed and accessible formats, while maintaining perceived quality
with good compatibility. /
The new Podcast mode provides highly compressed and fully
metadata-tagged audio (i.e. radio recording) files suitable for portable
players, using up-to-date codec options for more flexibility, …
[View More]better
quality and compression than typical broadcaster MP3 downloads.
An optional post-processing command has been added to trigger
re-indexing by a media server such as a Squeezeserver.
/See
https://projects.vdr-developer.org/projects/vdr-convert/wiki/Podcast-mode/
Changelog:
* Added --podcast option: podcasts stored in subdirectories, by Title
(like VDR itself)
* Podcast audio codec config: Can use (HE)AAC, Opus or MP3
* Extensive embedding of metadata in output files (mainly for podcasts)
* Added -g option for genre files to define mapping of VDR's G tag to text
* Significant H265 setting updates to reflect recent improvements
* Slight H264 compression increase to reflect recent improvements
* More extensive checking of ffmpeg build options (codec library checks)
* Detect short initial recording files & delete (VPS aborted start)
* Various other fixes and improvements, incl. for FTP/redo modes
* Fixes for recent ffmpeg versions (3.3+)
Enjoy!
Richard
[View Less]