| Message ID | f5283c43-0363-0899-37a9-f14bad1e27e1@tvdr.de |
|---|---|
| State | New |
| Headers |
Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <vdr-bounces@linuxtv.org>) id 1euFg2-0000nS-L9; Fri, 09 Mar 2018 10:55:06 +0000 Received: from racoon.tvdr.de ([88.198.76.220]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <Klaus.Schmidinger@tvdr.de>) id 1euFfz-0000n3-CI for vdr@linuxtv.org; Fri, 09 Mar 2018 10:55:03 +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 w29At2r5032676 for <vdr@linuxtv.org>; Fri, 9 Mar 2018 11:55:02 +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 w29At2tF005046 for <vdr@linuxtv.org>; Fri, 9 Mar 2018 11:55:02 +0100 To: VDR Mailing List <vdr@linuxtv.org> 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> From: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> Message-ID: <f5283c43-0363-0899-37a9-f14bad1e27e1@tvdr.de> Date: Fri, 9 Mar 2018 11:55:02 +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: <20180309115104.6659b0d5@yaise-pc1> 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 <vdr.linuxtv.org> List-Unsubscribe: <https://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr/> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> Reply-To: VDR Mailing List <vdr@linuxtv.org> Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: vdr-bounces@linuxtv.org Sender: "vdr" <vdr-bounces@linuxtv.org> |
Commit Message
Klaus Schmidinger
March 9, 2018, 10:55 a.m. UTC
On 09.03.2018 11:51, Patrick Boettcher wrote: > On Fri, 9 Mar 2018 11:30:36 +0100 > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: > >> On 01.03.2018 10:22, Patrick Boettcher wrote: >> > On Wed, 28 Feb 2018 11:01:23 +0100 >> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: >> > >> >> On 27.02.2018 17:58, Patrick Boettcher wrote: >> >> > On Tue, 27 Feb 2018 16:54:35 +0100 >> >> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> 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. Well, maybe this works for you? Klaus
Comments
On Fri, 9 Mar 2018 11:55:02 +0100 Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: > On 09.03.2018 11:51, Patrick Boettcher wrote: > > On Fri, 9 Mar 2018 11:30:36 +0100 > > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: > > > >> On 01.03.2018 10:22, Patrick Boettcher wrote: > >> > On Wed, 28 Feb 2018 11:01:23 +0100 > >> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: > >> > > >> >> On 27.02.2018 17:58, Patrick Boettcher wrote: > >> >> > On Tue, 27 Feb 2018 16:54:35 +0100 > >> >> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> 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. > > Well, maybe this works for you? > > --- nit.c 2016/12/23 14:16:59 4.4 > +++ nit.c 2018/03/09 10:53:38 > @@ -218,6 +218,8 @@ > SI::TerrestrialDeliverySystemDescriptor *sd = > (SI::TerrestrialDeliverySystemDescriptor *)d; > cDvbTransponderParameters dtp; int Source = > cSource::FromData(cSource::stTerr); > + if (sd->getFrequency() == 0xFFFFFFFF) > + continue; > int Frequency = Frequencies[0] = > sd->getFrequency() * 10; static int Bandwidths[] = { 8000000, > 7000000, 6000000, 5000000, 0, 0, 0, 0 }; > dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); This is what I'm doing right now (though I'm using break instead of continue). But won't his inhibit the update of modulation parameters of the _current_ channel? -- Patrick.
On 09.03.2018 12:01, Patrick Boettcher wrote: > On Fri, 9 Mar 2018 11:55:02 +0100 > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: > >> On 09.03.2018 11:51, Patrick Boettcher wrote: >> > On Fri, 9 Mar 2018 11:30:36 +0100 >> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: >> > >> >> On 01.03.2018 10:22, Patrick Boettcher wrote: >> >> > On Wed, 28 Feb 2018 11:01:23 +0100 >> >> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: >> >> > >> >> >> On 27.02.2018 17:58, Patrick Boettcher wrote: >> >> >> > On Tue, 27 Feb 2018 16:54:35 +0100 >> >> >> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> 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. >> >> Well, maybe this works for you? >> >> --- nit.c 2016/12/23 14:16:59 4.4 >> +++ nit.c 2018/03/09 10:53:38 >> @@ -218,6 +218,8 @@ >> SI::TerrestrialDeliverySystemDescriptor *sd = >> (SI::TerrestrialDeliverySystemDescriptor *)d; >> cDvbTransponderParameters dtp; int Source = >> cSource::FromData(cSource::stTerr); >> + if (sd->getFrequency() == 0xFFFFFFFF) >> + continue; >> int Frequency = Frequencies[0] = >> sd->getFrequency() * 10; static int Bandwidths[] = { 8000000, >> 7000000, 6000000, 5000000, 0, 0, 0, 0 }; >> dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); > > This is what I'm doing right now (though I'm using break instead of > continue). I realized that right after I had sent that message ;-). > But won't his inhibit the update of modulation parameters of the > _current_ channel? Sure. But I don't see how to handle this... Klaus
--- nit.c 2016/12/23 14:16:59 4.4 +++ nit.c 2018/03/09 10:53:38 @@ -218,6 +218,8 @@ SI::TerrestrialDeliverySystemDescriptor *sd = (SI::TerrestrialDeliverySystemDescriptor *)d; cDvbTransponderParameters dtp; int Source = cSource::FromData(cSource::stTerr); + if (sd->getFrequency() == 0xFFFFFFFF) + continue; int Frequency = Frequencies[0] = sd->getFrequency() * 10; static int Bandwidths[] = { 8000000, 7000000, 6000000, 5000000, 0, 0, 0, 0 }; dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]);