dvb-s(2) NumProvidedSystems() vs reelchannelscan

  Hi!

 There seems to be a change in recent vdr versions regarding
NumProvidedSystems() which at least the reelchannelscan plugin
uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places,
apparently it used to return 2 for a dvb-s2 tuner and now returns 3.
Is this intentional?

 I patched reelchannelscan like below:  (would need to check the
vdr version to be general of course, this was for 1.7.18; symptom
was a manual scan wrote out qam32 modulation into the channels.conf
instead of qpsk and of course vdr couldn't tune the new channel(s).)

 Thanx!
	Juergen
  

On 05/07/11 20:11, Juergen Lock wrote:
> Hi!
>
>   There seems to be a change in recent vdr versions regarding
> NumProvidedSystems() which at least the reelchannelscan plugin
> uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places,
> apparently it used to return 2 for a dvb-s2 tuner and now returns 3.
> Is this intentional?

Yes, it is.

2010-06-06: Version 1.7.15

...
- The various modulation types are now taken into account when selecting a device for
   a recording or live viewing, so that devices that provide more capabilities are
   spared.

This was done by incrementing numProvidedSystems in cDvbDevice::cDvbDevice()
for every additional modulation type it provides.

I'm afraid the result from NumProvidedSystems() is in no way suitable
for determining whether the device is DVB-S or DVB-S2.

Klaus

>   I patched reelchannelscan like below:  (would need to check the
> vdr version to be general of course, this was for 1.7.18; symptom
> was a manual scan wrote out qam32 modulation into the channels.conf
> instead of qpsk and of course vdr couldn't tune the new channel(s).)
>
>   Thanx!
> 	Juergen
>
> --- a/csmenu.c
> +++ b/csmenu.c
> @@ -243,7 +243,7 @@ void cMenuChannelscan::TunerDetection()
>                   txtstream<<  tr("DVB-C - Cable")<<  " ("<<  tr("Tuner")<<  ' '<<  tuner + 1<<  ')';
>                   stp = CABLE;
>               } else if (device->ProvidesSource(cSource::stSat)) {
> -                if (device->NumProvidedSystems() == 2) {
> +                if (device->NumProvidedSystems() == 3) {
>   //                    if(TunerIsRotor(tuner))
>   //                       txtstream<<  tr("DVB-S2 - Rotor")<<  " ("<<  tr("Tuner")<<  ' '<<  tuner + 1<<  ')';
>   //                    else
> --- a/scan.c
> +++ b/scan.c
> @@ -421,7 +421,7 @@ void cScan::ScanNitServices()
>   void cScan::ScanDVB_S(cTransponder * tp, cChannel * c)
>   {
>    //const time_t tt = time(NULL);
> -  int maxmods = device->NumProvidedSystems() == 2? 4 : 2;
> +  int maxmods = device->NumProvidedSystems() == 3? 4 : 2;
>
>      // esyslog("%s cTransponder* tp = %x  cChannel *c = %x", __PRETTY_FUNCTION__);
>       esyslog("maxmods = %d",maxmods);
> @@ -431,7 +431,7 @@ void cScan::ScanDVB_S(cTransponder * tp,
>           ;
>
>       // skip HD Transonders on SD Tuner
> -    if ( !device->NumProvidedSystems() == 2&&  static_cast<  cSatTransponder *>(tp)->System() == 1)
> +    if ( !device->NumProvidedSystems() == 3&&  static_cast<  cSatTransponder *>(tp)->System() == 1)
>           return;
>
>     unsigned  int nRadio = radioChannelNames.size();
  

In article <4DD7C61E.8060708@tvdr.de> you write:
>On 05/07/11 20:11, Juergen Lock wrote:
>> Hi!
>>
>>   There seems to be a change in recent vdr versions regarding
>> NumProvidedSystems() which at least the reelchannelscan plugin
>> uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places,
>> apparently it used to return 2 for a dvb-s2 tuner and now returns 3.
>> Is this intentional?
>
>Yes, it is.
>
>2010-06-06: Version 1.7.15
>
>...
>- The various modulation types are now taken into account when selecting a device for
>   a recording or live viewing, so that devices that provide more capabilities are
>   spared.
>
>This was done by incrementing numProvidedSystems in cDvbDevice::cDvbDevice()
>for every additional modulation type it provides.
>
Ah I see.  Curious, what is the third modulation used on dvb-s(2) in
addition to qpsk and 8psk?

>I'm afraid the result from NumProvidedSystems() is in no way suitable
>for determining whether the device is DVB-S or DVB-S2.

 Ok so what would then be the recommended way?

 Wondering... :)
	Juergen
  

On 05/21/11 16:55, Juergen Lock wrote:
> In article<4DD7C61E.8060708@tvdr.de>  you write:
>> On 05/07/11 20:11, Juergen Lock wrote:
>>> Hi!
>>>
>>>    There seems to be a change in recent vdr versions regarding
>>> NumProvidedSystems() which at least the reelchannelscan plugin
>>> uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places,
>>> apparently it used to return 2 for a dvb-s2 tuner and now returns 3.
>>> Is this intentional?
>>
>> Yes, it is.
>>
>> 2010-06-06: Version 1.7.15
>>
>> ...
>> - The various modulation types are now taken into account when selecting a device for
>>    a recording or live viewing, so that devices that provide more capabilities are
>>    spared.
>>
>> This was done by incrementing numProvidedSystems in cDvbDevice::cDvbDevice()
>> for every additional modulation type it provides.
>>
> Ah I see.  Curious, what is the third modulation used on dvb-s(2) in
> addition to qpsk and 8psk?

Originally it was just 2 for DVB-S and DVB-S2.
Then somebody came up with the request that the various
FE_CAN_... flags should also be taken into account
when trying to spare devices with more capabilities
than others.

The whole idea behind NumProvidedSystems() is just to
have a way of deciding which device to use for recording
if they are otherwise equivalent. One with more capabilities
should be preserved in case an other channel requires those.
The actual value of NumProvidedSystems() has no real meaning.
It's just "more" or "less".

>> I'm afraid the result from NumProvidedSystems() is in no way suitable
>> for determining whether the device is DVB-S or DVB-S2.
>
>   Ok so what would then be the recommended way?

I'm afraid there is none - at least at the moment.

I'm thinking about giving cDevice a function that returns
a bit masked value, identifying the delivery systems it
provides. Probably using the fe_delivery_system_t constants
from the LinuxDVB API.

Klaus
  

On Sat, 21 May 2011, Klaus Schmidinger wrote:

> I'm thinking about giving cDevice a function that returns
> a bit masked value, identifying the delivery systems it
> provides. Probably using the fe_delivery_system_t constants
> from the LinuxDVB API.

Could you take again a look at my frontend facilities patch and modify 
the current cDevice API a bit further at the same time?

BR,
--
rofa