Heikki Manninen wrote:
> Klaus Schmidinger wrote:
>> Heikki Manninen wrote:
>>> On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote:
>>>
Your CAM doesn't respond to the QUERY that VDR sends to it.
So VDR can't ask the CAM whether it is able to decrypt a certain
channel (in addi
Klaus Schmidinger wrote:
Heikki Manninen wrote:
On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote:
Your CAM doesn't respond to the QUERY that VDR sends to it.
So VDR can't ask the CAM whether it is able to decrypt a certain
channel (in addition to others it is already decrypting).
So i
Klaus Schmidinger wrote:
> Heikki Manninen wrote:
>
>>On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote:
>>
>>
>>>Your CAM doesn't respond to the QUERY that VDR sends to it.
>>>So VDR can't ask the CAM whether it is able to decrypt a certain
>>>channel (in addition to others it is already
Heikki Manninen wrote:
> On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote:
>
>> Your CAM doesn't respond to the QUERY that VDR sends to it.
>> So VDR can't ask the CAM whether it is able to decrypt a certain
>> channel (in addition to others it is already decrypting).
>> So it's a hard-/f
On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote:
> Your CAM doesn't respond to the QUERY that VDR sends to it.
> So VDR can't ask the CAM whether it is able to decrypt a certain
> channel (in addition to others it is already decrypting).
> So it's a hard-/firmware restriction of your CAM
Klaus Schmidinger wrote:
Petri Helin wrote:
But anyway, now it works, though only for one channel at time as stated
in the vdr's log. Is that a hardware specific restriction?
Your CAM doesn't respond to the QUERY that VDR sends to it.
So VDR can't ask the CAM whether it is able to decrypt a ce
Petri Helin wrote:
> Klaus Schmidinger wrote:
>> Petri Helin wrote:
>>> But anyway, now it works, though only for one channel at time as stated
>>> in the vdr's log. Is that a hardware specific restriction?
>>
>> Your CAM doesn't respond to the QUERY that VDR sends to it.
>> So VDR can't ask the CA
Petri Helin wrote:
> Klaus Schmidinger wrote:
>...
>> Please set the CA parameter of these channels to 0 (FTA) and tune to
>> them again.
>> VDR should automatically insert the correct CA values then.
>>
>>> From the HISTORY:
>>
>> - Ca values in the range 0...F in channels.conf can still be used t
Klaus Schmidinger wrote:
Petri Helin wrote:
Klaus Schmidinger wrote:
Petri Helin wrote:
Klaus Schmidinger wrote:
Petri Helin wrote:
Klaus Schmidinger wrote:
Looks like the CAM is recognized all right.
Please enable the lines
static bool DumpTPDUDataTransfer = false;
static bool DebugProto
Petri Helin wrote:
> Klaus Schmidinger wrote:
>> Petri Helin wrote:
>>> Klaus Schmidinger wrote:
Petri Helin wrote:
> Klaus Schmidinger wrote:
>> Looks like the CAM is recognized all right.
>>
>> Please enable the lines
>>
>> static bool DumpTPDUDataTransfer = false;
>>
Klaus Schmidinger wrote:
Petri Helin wrote:
Klaus Schmidinger wrote:
Petri Helin wrote:
Klaus Schmidinger wrote:
Looks like the CAM is recognized all right.
Please enable the lines
static bool DumpTPDUDataTransfer = false;
static bool DebugProtocol = false;
static bool DumpPolls = false;
st
Petri Helin wrote:
> Klaus Schmidinger wrote:
>> Petri Helin wrote:
>>> ...
>>> BTW: I have been patching the device.c in 1.4.* series so that my other
>>> card, TT budget DVB-C v1.0, is always preferred for FTA channel
>>> recordings. Otherwise the precious CAM could be wasted in an FTA
>>> record
Petri Helin wrote:
> Klaus Schmidinger wrote:
>> Petri Helin wrote:
>>> Klaus Schmidinger wrote:
Looks like the CAM is recognized all right.
Please enable the lines
static bool DumpTPDUDataTransfer = false;
static bool DebugProtocol = false;
static bool DumpPolls
Klaus Schmidinger wrote:
Petri Helin wrote:
Klaus Schmidinger wrote:
Looks like the CAM is recognized all right.
Please enable the lines
static bool DumpTPDUDataTransfer = false;
static bool DebugProtocol = false;
static bool DumpPolls = false;
static bool DumpDateTime = false;
in ci.c by ch
Klaus Schmidinger wrote:
Petri Helin wrote:
...
BTW: I have been patching the device.c in 1.4.* series so that my other
card, TT budget DVB-C v1.0, is always preferred for FTA channel
recordings. Otherwise the precious CAM could be wasted in an FTA
recording. I understood that you are planning o
Petri Helin wrote:
> Klaus Schmidinger wrote:
>>
>> Looks like the CAM is recognized all right.
>>
>> Please enable the lines
>>
>> static bool DumpTPDUDataTransfer = false;
>> static bool DebugProtocol = false;
>> static bool DumpPolls = false;
>> static bool DumpDateTime = false;
>>
>> in ci.c by
Klaus Schmidinger wrote:
Looks like the CAM is recognized all right.
Please enable the lines
static bool DumpTPDUDataTransfer = false;
static bool DebugProtocol = false;
static bool DumpPolls = false;
static bool DumpDateTime = false;
in ci.c by changing them to 'true' and compile/run VDR aga
Petri Helin wrote:
> ...
> BTW: I have been patching the device.c in 1.4.* series so that my other
> card, TT budget DVB-C v1.0, is always preferred for FTA channel
> recordings. Otherwise the precious CAM could be wasted in an FTA
> recording. I understood that you are planning on restructuring th
Petri Helin wrote:
> Klaus Schmidinger wrote:
>> VDR developer version 1.5.0 is now available at
>> ...
> with a quick test with this new version I was unable to get the
> decrypting to work. I have a Technotrend C1500 budget card with budget
> CI and a Dual CAM Irdeto + Conax (Conax is used). This
Klaus Schmidinger wrote:
VDR developer version 1.5.0 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.0.tar.bz2
A 'diff' against the latest stable version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-1.5.0.diff
WARNING:
This is a *developer* v
20 matches
Mail list logo
