[vdr] Re: VDR-1.3.x and a rotorized dish

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Christian Schuld wrote:
> 
> Hi Klaus,
> 
> I have a setup where 2 DVB-s pointing to 19,2°E and 1 DVB-s is connected to a
> rotorized dish.
> 
> There are a few obstacles in this environment:
> 
> 1.) Until 1.3.x I used a special CA value to bind all non-Astra channels to
> the DVB-s where the rotor is connected.
> 
> Unfortunately this won't work in vdr-1.3.x anymore. Reading "man 5 vdr" lead
> me to the solution to use a special value within the range 0x10 .. 0xff for
> this purpose, but I got always "channel not available" errors. Here is dirty
> fix for this:
> 
> <snip>
> diff -Naur vdr-1.3.1/device.h vdr-1.3.1_provides_ca_patch/device.h
> --- vdr-1.3.1/device.h  2004-01-10 15:15:10.000000000 +0100
> +++ vdr-1.3.1_provides_ca_patch/device.h        2004-01-17 21:15:03.000000000 +0100
> @@ -106,6 +106,7 @@
>  private:
>    static int nextCardIndex;
>    int cardIndex;
> +protected:
>    int caCaps[MAXCACAPS];
>  protected:
>    cDevice(void);
> diff -Naur vdr-1.3.1/dvbdevice.c vdr-1.3.1_provides_ca_patch/dvbdevice.c
> --- vdr-1.3.1/dvbdevice.c       2004-01-10 13:21:41.000000000 +0100
> +++ vdr-1.3.1_provides_ca_patch/dvbdevice.c     2004-01-17 21:15:51.000000000
> +0100
> @@ -435,6 +435,11 @@
> 
>  int cDvbDevice::ProvidesCa(const cChannel *Channel) const
>  {
> +  if (Channel->Ca() >= 0x0010 && Channel->Ca() < 0x0100) {
> +     for(int i = 0; i < MAXCACAPS; i++)
> +        if(Channel->Ca() == caCaps[i])
> +           return true;
> +  }
>    if (Channel->Ca() >= 0x0100 && ciHandler) {
>       unsigned short ids[MAXCAIDS + 1];
>       for (int i = 0; i <= MAXCAIDS; i++) // '<=' copies the terminating 0!
> <snap>
> 
> But this doesn't seem to be the right way, because wouldn't the new CA
> handling get undermined by such special CA values? I don't see a (clean) way
> to use a CAM on the rotorized dish. For example ":11,1702:" as CA value,
> suggesting that a channel is only available from the rotorized dish and
> encrypted in BetaCrypt, gets overwritten with ":11:" after tuning to this
> channel.
> 
> The solution for this might be to have a "SourceCaps" setup option similar the
> the "CaCaps", which would look in my particular case like this:
> 
> <snip>
> SourceCaps = 1 S19.2E
> SourceCaps = 2 S19.2E
> SourceCaps = 3 S28.5E S16.0E S13.0E ...... S43.0W
> <snap>

Something in that direction has already been suggested and will most likely
be implemented in VDR (hopefully during the 1.3.x development).
However, there's more to it than you have outlines here, since it also
needs to take into account cases where switching one DVB card to a particular
source blocks other sources for other DVB cards (the "lnbsharing" patch goes
into that direction).

> 2.) On most orbital positions besides Astra and Hotbird (may be Sirius, Thor,
> Hispa, too) the quality of the broadcasted SI-data is rather low. So
> SID,TID,NID values are not within the specs or totally misleading. This makes
> the default behaviour of VDR: "bool tChannelID::Valid(void) { return (tid &&
> sid); }" a real showstopper for these satellites. Besides that, the idea of a
> unique channel-id won't work, too. So VDR needs a second method of uniqueness
> for channel-ids. I would suggest using a special value of a SID:NID:TID
> triplet and hash value of the channel's name for the RID.
> This would enable VDR to be used for feed hunting and other cool DXing
> stuff :-))

How are any STBs supposed to work if these _basic_ things are not
handled correctly? The DVB standard clearly states that NID, TID and SID
uniquely identify a service. If you absolutely need to receive standard
breaking services, you may want to turn off adding new transponders in VDR
and set the NID/TID values manually.

Klaus


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.