vdr April 2019

vdr@linuxtv.org

1 participants
3 discussions

Trouble with DVB-T2 on frontend 1
by Marko Mäkelä 03 Jan '22

03 Jan '22

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/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

2 7

French DVB-T Channel IDs vs. EIT Channel IDs
by Patrick Boettcher 25 Jan '20

25 Jan '20

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? Thanks for any help. best regards, -- Patrick.

4 22

vdr-convert version 2.3 released
by Richard F 04 Apr '19

04 Apr '19

vdr-convert is a tool to accurately transcode VDR1.x and VDR2.x 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. See https://projects.vdr-developer.org/projects/vdr-convert/ This is mostly a small bugfix release Changelog: * Fixed support for mono podcasts using HE-AAC (V2 only supports stereo) * Support latest ffmpeg with more relevant/shorter service name+provider metadata * AAC streams: Silently use Fraunhofer (libfdk) if available in ffmpeg build unless specifically set with -a option * Improved error reporting tolerance x264/5 * Improved error reporting tolerance (subtitle stream) with foreign language (hard-subtitled) programmes Enjoy! Richard

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr April 2019