[vdr] Re: Bug in recording CA handling

[s.huelswitt@gmx.de (Stefan Huelswitt)]

On 06 Apr 2003 Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote:

> Stefan Huelswitt wrote:
>> 
>> I think there is a mismatch in the way the CA values from
>> channels.conf are used in device.c/dvbdevice.c.
>> 
>> In many places ca>CACONFBASE is used to detect an encrypted
>> channel (like in cDvbDevice::ProvidesChannel() and
>> cDvbDevice::SetChannelDevice()). On the other side in
>> cDevice::Ca() a != 0 is used.
[...]
> Can you please try this with
> 
>   return cDevice::CanReplay() && Ca() <= MAXDEVICES; // we can only replay if there is no Ca recording going on
> 
> instead of
> 
>   return cDevice::CanReplay() && !Ca(); // we can only replay if there is no Ca recording going on
> 
> in VDR/dvbdevice.c, cDvbDevice::CanReplay()?

Well, I have been pretty busy today and unfortunaly vdr is
recording now...

I'll check this tomorrow. I'm sure that it solves the
problem, even without test, but ...

I think it's more interesting how the Ca value is defined. In the
past I though that any value != 0 would mean an encrypted channel
(with the difference that some are bound to a specific card and
some not). With your change this would change, leaving Ca values
<=MAXDEVICES without the restrictions of encrypted channels.

In the meantime I searched for a temporary solution for myself
and I change the two checks in ProvidesChannel() and
SetChannelDevice() from >CACONFBASE to >0 (leaving these channels
with all restictions of encrypted channels).

And I think that it would be a good idea to use the same value
for the checks everywhere (MAXDEVICES vs. CACONFBASE).

-- 
Stefan Huelswitt
huels@iname.com  | http://home.pages.de/~nathan


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