vdr July 2018

vdr@linuxtv.org

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 ISDB-T support
by Christian Rodriguez 14 Sep '18

14 Sep '18

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

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr July 2018