From patchwork Fri Mar 9 10:58:27 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 47793 Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euFjL-0001Pv-2i; Fri, 09 Mar 2018 10:58:31 +0000 Received: from racoon.tvdr.de ([88.198.76.220]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euFjI-0001PP-Ln for vdr@linuxtv.org; Fri, 09 Mar 2018 10:58:29 +0000 Received: from eagle.tvdr.de (eagle.tvdr.de [192.168.1.10]) by racoon.tvdr.de (8.14.9/8.14.9) with ESMTP id w29AwSc6000343 for ; Fri, 9 Mar 2018 11:58:28 +0100 Received: from [192.168.1.10] (eagle.tvdr.de [192.168.1.10]) by eagle.tvdr.de (8.15.2/8.15.2) with ESMTP id w29AwRBF005082 for ; Fri, 9 Mar 2018 11:58:27 +0100 From: Klaus Schmidinger To: VDR Mailing List References: <20180225152621.75458a81@yaise-pc1> <8b233e07-db60-b942-e298-a14c08e647f0@tvdr.de> <20180226232758.454f8022@yaise-pc1> <33ccd29f-8f5f-5d00-7b20-a99d3742286e@tvdr.de> <20180227175820.607bbebb@posteo.de> <31220933-dda2-5e51-7e61-c3655197dddb@tvdr.de> <20180301102210.0aa7cfd9@yaise-pc1> <77d071a7-536a-ed0c-c32d-b72bc5e302d3@tvdr.de> <20180309115104.6659b0d5@yaise-pc1> Message-ID: <3ba10a44-35d8-eff9-293d-901d6ba88746@tvdr.de> Date: Fri, 9 Mar 2018 11:58:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: de-DE X-LSpam-Score: -1.9 (-) X-LSpam-Report: No, score=-1.9 required=5.0 tests=BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01 autolearn=ham autolearn_force=no Subject: Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: VDR Mailing List Errors-To: vdr-bounces@linuxtv.org Sender: "vdr" On 09.03.2018 11:55, Klaus Schmidinger wrote: > On 09.03.2018 11:51, Patrick Boettcher wrote: >> On Fri, 9 Mar 2018 11:30:36 +0100 >> Klaus Schmidinger wrote: >> >>> On 01.03.2018 10:22, Patrick Boettcher wrote: >>> > On Wed, 28 Feb 2018 11:01:23 +0100 >>> > Klaus Schmidinger wrote: >>> > >> On 27.02.2018 17:58, Patrick Boettcher wrote: >> > On Tue, 27 Feb 2018 16:54:35 +0100 >>> >> > Klaus Schmidinger wrote: >>> >> > >> >> Hello Patrick, >>> >> >> >> >> your scan doesn't contain the NIT, which is where the >>> >> >> transponder innformation is broadcast. Can you scan that, too, >>> >> >> please? >> > >> > Hi Klaus, >>> >> > >> > NIT attached (from another multiplex with the same symptoms). >> >>              DVB-DescriptorTag: 90 (0x5a)  [= >>> >> terrestrial_delivery_system_descriptor] descriptor_length: 11 >>> >> (0x0b) Center frequency: 0xffffffff (= 42949672.095 kHz) >>> >> >> @@ -219,6 +219,8 @@ >>> >>                    cDvbTransponderParameters dtp; >>> >>                    int Source = cSource::FromData(cSource::stTerr); >>> >>                    int Frequency = Frequencies[0] = >>> >> sd->getFrequency() * 10; >>> >> +                 Frequency = Transponder() * 1000000;//XXX >>> >> +                 dsyslog("Frequency = %08X, Transponder = %d", >>> >> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] = >>> >> { 8000000, 7000000, 6000000, 5000000, 0, 0, 0, 0 }; >>> >> dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int >>> >> Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO }; > > It works. I had to have VDR recreate the channels because it was >>> > mixing things up with the already existing ones. >>> > > As to why the frequency is set to "-10" I don't know (yet), but I >>> > remember it has always been like this since 2005. >>> > > Initial tuning files have always contained all active frequencies >>> > for their region, because the NIT did not set the center frequencies >>> > correctly. >>> > > It might be because the multiplexed transport streams are generated >>> > centrally and then distributed to all the base-stations where they >>> > are emitted as-is but on different frequencies depending on the >>> > region. >>> > > What can we do to get this upstream? >>> I'm afraid I don't see how this case can be handled correctly. >>> >>> Maybe somebody else has an idea? >> >> One approach might be to ignore frequencies for DVB-T channels update >> during NIT parsing (in France only?). >> >>> From my experiences with DVB-T SetTopBoxes using the NIT for >> new channel-discovery is rarely done. No customer of my ex-employer was >> using it - scanning was entirely based on continuous frequency-band >> scanning with a spare demod. >> >> That would be my idea. But I don't know whether this can be easily >> applied to VDR. Sorry, of course it has to be "break" instead of "continue": Klaus --- nit.c 2016/12/23 14:16:59 4.4 +++ nit.c 2018/03/09 10:57:21 @@ -216,6 +216,8 @@ break; case SI::TerrestrialDeliverySystemDescriptorTag: { SI::TerrestrialDeliverySystemDescriptor *sd = (SI::TerrestrialDeliverySystemDescriptor *)d; + if (sd->getFrequency() == 0xFFFFFFFF) + break; cDvbTransponderParameters dtp; int Source = cSource::FromData(cSource::stTerr); int Frequency = Frequencies[0] = sd->getFrequency() * 10;