On 05/21/11 16:55, Juergen Lock wrote:
In article<4dd7c61e.8060...@tvdr.de> you write:
On 05/07/11 20:11, Juergen Lock wrote:
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
a recording or live viewing, so that devices that provide more capabilities
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
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.
vdr mailing list