Re: [vdr] Channels getting deleted on new scan

[Torgeir Veimo]

Isn't there a plugin that can change such data before it gets processed?

On 10 March 2018 at 08:47, Timothy D. Lenz  wrote:

> Wel, it gets better. Tonight I see VDR is grabbing guide data for 9x
> and using it for 58.x. So 58.x data is now being lost. g
>
>
> On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:
>
>> On 08.03.2018 22:38, Klaus Schmidinger wrote:
>>
>>> On 08.03.2018 22:13, Timothy D. Lenz wrote:
>>>
 I was hoping it was something simple I could fix in the conf. I haven't
 worked on it or in linux in a long time and don't have the free time to
 figure it all out again. I'll have to look at this some other time. I am in
 the U.S. and these are ATA channels. They each have their own freq. and my
 guess is that they can use what ever numbers they want since they are on
 there own freq which they bought.

>>>
>>> Well, it's funny though that they use exactly the same IDs ;-).
>>>
>>> Sure they can do whatever they want, but there are a few basic rules that
>>> should be followed in order to guarantee a reasonable coexistance. One of
>>> them is that channels that are broadcast in the same area (like from the
>>> same terrestrial transmitter, on the same cable or the same satellite)
>>> should use unique IDs, even if they are on different transponders. One
>>> of these IDs is the "transport stream id", which in your case is 207 for
>>> both channels. This should be different.
>>>
>>
>> For testing I added your new channel list to my channels.conf.
>> Here's what my VDR reported upon startup:
>>
>> Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
>> Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel
>> KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
>>
>> Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel
>> LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
>> Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel
>> ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
>>
>> With your old list I get no such log entries. So I guess somebody messed
>> up
>> with the TIDs, and the problem should be fixed there.
>>
>> Klaus
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



-- 
-Tor
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

Wel, it gets better. Tonight I see VDR is grabbing guide data for 9x 
and using it for 58.x. So 58.x data is now being lost. g


On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I 
haven't worked on it or in linux in a long time and don't have the 
free time to figure it all out again. I'll have to look at this some 
other time. I am in the U.S. and these are ATA channels. They each 
have their own freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


With your old list I get no such log entries. So I guess somebody messed up
with the TIDs, and the problem should be fixed there.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Channels getting deleted on new scan

[Timothy D. Lenz]

I sent an email to KGUN and if they don't fix the conflict right away, I 
guess I'll have to make a complaint to the FCC, not that it will do much 
good.


On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I 
haven't worked on it or in linux in a long time and don't have the 
free time to figure it all out again. I'll have to look at this some 
other time. I am in the U.S. and these are ATA channels. They each 
have their own freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


With your old list I get no such log entries. So I guess somebody messed up
with the TIDs, and the problem should be fixed there.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

[Klaus Schmidinger]

On 09.03.2018 12:01, Patrick Boettcher wrote:

On Fri, 9 Mar 2018 11:55:02 +0100
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: 0x (= 42949672.095 kHz)
>> >> 
>> >> @@ -219,6 +219,8 @@

>> >>cDvbTransponderParameters dtp;
>> >>int Source =
>> >> cSource::FromData(cSource::stTerr); int Frequency =
>> >> Frequencies[0] = sd->getFrequency() * 10;
>> >> + Frequency = Transponder() * 100;//XXX
>> >> + dsyslog("Frequency = %08X, Transponder = %d",
>> >> sd->getFrequency(), Transponder());//XXX static int
>> >> Bandwidths[] = { 800, 700, 600, 500, 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() == 0x)
+continue;
   int Frequency = Frequencies[0] =
sd->getFrequency() * 10; static int Bandwidths[] = { 800,
700, 600, 500, 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


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

[Patrick Boettcher]

On Fri, 9 Mar 2018 11:55:02 +0100
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: 0x (= 42949672.095 kHz)
> >> >> 
> >> >> @@ -219,6 +219,8 @@
> >> >>cDvbTransponderParameters dtp;
> >> >>int Source =
> >> >> cSource::FromData(cSource::stTerr); int Frequency =
> >> >> Frequencies[0] = sd->getFrequency() * 10;
> >> >> + Frequency = Transponder() * 100;//XXX
> >> >> + dsyslog("Frequency = %08X, Transponder = %d",
> >> >> sd->getFrequency(), Transponder());//XXX static int
> >> >> Bandwidths[] = { 800, 700, 600, 500, 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() == 0x)
> +continue;
>int Frequency = Frequencies[0] =
> sd->getFrequency() * 10; static int Bandwidths[] = { 800,
> 700, 600, 500, 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.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

[Klaus Schmidinger]

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: 0x (= 42949672.095 kHz)
>> >> @@ -219,6 +219,8 @@
>>    cDvbTransponderParameters dtp;
>>    int Source = cSource::FromData(cSource::stTerr);
>>    int Frequency = Frequencies[0] =
>> sd->getFrequency() * 10;
>> + Frequency = Transponder() * 100;//XXX
>> + dsyslog("Frequency = %08X, Transponder = %d",
>> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
>> { 800, 700, 600, 500, 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() == 0x)
+break;
  cDvbTransponderParameters dtp;
  int Source = cSource::FromData(cSource::stTerr);
  int Frequency = Frequencies[0] = sd->getFrequency() * 10;

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

[Klaus Schmidinger]

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: 0x (= 42949672.095 kHz)
>> 
>> @@ -219,6 +219,8 @@

>>cDvbTransponderParameters dtp;
>>int Source = cSource::FromData(cSource::stTerr);
>>int Frequency = Frequencies[0] =
>> sd->getFrequency() * 10;
>> + Frequency = Transponder() * 100;//XXX
>> + dsyslog("Frequency = %08X, Transponder = %d",
>> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
>> { 800, 700, 600, 500, 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() == 0x)
+continue;
  int Frequency = Frequencies[0] = sd->getFrequency() * 10;
  static int Bandwidths[] = { 800, 700, 600, 
500, 0, 0, 0, 0 };
  dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]);

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

[Patrick Boettcher]

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: 0x (= 42949672.095 kHz)
> >> 
> >> @@ -219,6 +219,8 @@
> >>cDvbTransponderParameters dtp;
> >>int Source = cSource::FromData(cSource::stTerr);
> >>int Frequency = Frequencies[0] =
> >> sd->getFrequency() * 10;
> >> + Frequency = Transponder() * 100;//XXX
> >> + dsyslog("Frequency = %08X, Transponder = %d",
> >> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
> >> { 800, 700, 600, 500, 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.

--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

[Klaus Schmidinger]

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: 0x (= 42949672.095 kHz)

@@ -219,6 +219,8 @@
   cDvbTransponderParameters dtp;
   int Source = cSource::FromData(cSource::stTerr);
   int Frequency = Frequencies[0] =
sd->getFrequency() * 10;
+ Frequency = Transponder() * 100;//XXX
+ dsyslog("Frequency = %08X, Transponder = %d",
sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
{ 800, 700, 600, 500, 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?

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Channels getting deleted on new scan

[Klaus Schmidinger]

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I haven't worked on it or in linux in a long time and don't have the free time to figure it all out again. I'll have to look at this some other time. I am in the U.S. and these are ATA channels. They each have their own freq. and my 
guess is that they can use what ever numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0

With your old list I get no such log entries. So I guess somebody messed up
with the TIDs, and the problem should be fixed there.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr