Re: French DVB-T Channel IDs vs. EIT Channel IDs

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 <[email protected]> wrote:
>>
>>> On 01.03.2018 10:22, Patrick Boettcher wrote:
>>> > On Wed, 28 Feb 2018 11:01:23 +0100
>>> > Klaus Schmidinger <[email protected]> wrote:
>>> > >> On 27.02.2018 17:58, Patrick Boettcher wrote: >> > On Tue, 27 Feb 2018 16:54:35 +0100
>>> >> > Klaus Schmidinger <[email protected]> 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":

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

Klaus

_______________________________________________
vdr mailing list
[email protected]
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr