diff mbox

CAM auto resetting - feature request??

Message ID 20101201152839.GA11017@gentoo.local
State New
Headers

Commit Message

Halim Sahin Dec. 1, 2010, 3:28 p.m. UTC 
  Hi,
On Sun, Dec 06, 2009 at 04:42:02PM +0100, Klaus Schmidinger wrote:
> On 01.09.2009 23:38, Simon Baxter wrote:
> >>> I was afraid that might be the suggestion!
> >>>
> >>> It seems pretty random when the CAM will crash.  It is possible it's
> >>> only on certain channels, and only one of the CAMs - it only happens
> >>> very rarely....
> >>
> >> So you have 2 identical CAMs (Alphacrypt) (with the same firmware?),
> >> and exactly one of them sometimes fails, right?
> >>
> >> Have you tried swapping the two CAMs?
> >> This should tell us whether the problem is with the CAM or with
> >> the CI adapter.
> >>
> >> Klaus
> > 
> > I've discovered this happens to both CAMs, so it's either not a hardware
> > issue, or both CAMs are affected.
> > 
> > Managed to capture the following logs prior to the CAM dropping from
> > "AlphaCrypt" to "CAM Ready" (with no decrypting)
> > 
> > Sep  2 08:17:21 freddy vdr: [27702] switching to channel 11
> > Sep  2 08:17:21 freddy vdr: [1150] transfer thread ended (pid=27702,
> > tid=1150)
> > Sep  2 08:17:21 freddy vdr: [27702] buffer stats: 110356 (5%) used
> > Sep  2 08:17:21 freddy vdr: [6564] transfer thread started (pid=27702,
> > tid=6564)
> > Sep  2 08:17:21 freddy vdr: [1152] TS buffer on device 1 thread ended
> > (pid=27702, tid=1152)
> > Sep  2 08:17:21 freddy vdr: [1151] buffer stats: 75388 (3%) used
> > Sep  2 08:17:21 freddy vdr: [1151] receiver on device 1 thread ended
> > (pid=27702, tid=1151)
> > Sep  2 08:17:21 freddy vdr: [6565] receiver on device 1 thread started
> > (pid=27702, tid=6565)
> > Sep  2 08:17:21 freddy vdr: [6566] TS buffer on device 1 thread started
> > (pid=27702, tid=6566)
> > Sep  2 08:17:23 freddy vdr: [6564] setting audio track to 1 (0)
> > Sep  2 08:17:34 freddy vdr: [27702] switching to channel 1
> > Sep  2 08:17:34 freddy vdr: [6564] transfer thread ended (pid=27702,
> > tid=6564)
> > Sep  2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
> > continuity errors
> > Sep  2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
> > continuity errors
> > Sep  2 08:17:34 freddy vdr: [27702] buffer stats: 63544 (3%) used
> > Sep  2 08:17:34 freddy vdr: [6567] transfer thread started (pid=27702,
> > tid=6567)
> > Sep  2 08:17:34 freddy vdr: [6566] TS buffer on device 1 thread ended
> > (pid=27702, tid=6566)
> > Sep  2 08:17:34 freddy vdr: [6565] buffer stats: 62980 (3%) used
> > Sep  2 08:17:34 freddy vdr: [6565] receiver on device 1 thread ended
> > (pid=27702, tid=6565)
> > Sep  2 08:17:34 freddy vdr: [6568] receiver on device 1 thread started
> > (pid=27702, tid=6568)
> > Sep  2 08:17:34 freddy vdr: [6569] TS buffer on device 1 thread started
> > (pid=27702, tid=6569)
> > Sep  2 08:17:38 freddy vdr: [6567] transfer thread ended (pid=27702,
> > tid=6567)
	> > Sep  2 08:17:38 freddy vdr: [6569] TS buffer on device 1 thread ended
> > (pid=27702, tid=6569)
> > Sep  2 08:17:38 freddy vdr: [6568] buffer stats: 193828 (9%) used
> > Sep  2 08:17:38 freddy vdr: [6568] receiver on device 1 thread ended
> > (pid=27702, tid=6568)
> > Sep  2 08:17:39 freddy vdr: [27702] switching to channel 1
> > Sep  2 08:17:39 freddy vdr: [27702] buffer stats: 116748 (5%) used
> > Sep  2 08:17:39 freddy vdr: [27702] info: Channel not available!
> > Sep  2 08:17:41 freddy vdr: [27702] switching to channel 9
> > Sep  2 08:17:41 freddy vdr: [6570] transfer thread started (pid=27702,
> > tid=6570)
> > Sep  2 08:17:41 freddy vdr: [6570] setting audio track to 1 (0)
> > Sep  2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
> > device 0: Input/output error
> > Sep  2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
> > device 0: Input/output error
> > Sep  2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
> > device 0: Input/output error
> > Sep  2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
> > initialised successfully
> 
> This looks more like a driver bug to me.

Well maybe but unfortunately responds to my mails in linux-dvb /
linux-media mailinglist for that problem.

@Klaus: 
If that problem happens, a manual reset of the cam under vdr's
menu->settings->ci brings the cam back.

What about trying to reset a cam automatically when it's Status is !=
msReady?

Like this:

Comments

Klaus Schmidinger Dec. 12, 2010, 3:40 p.m. UTC | #1 
On 01.12.2010 16:28, Halim Sahin wrote:
> Hi,
> On Sun, Dec 06, 2009 at 04:42:02PM +0100, Klaus Schmidinger wrote:
>> On 01.09.2009 23:38, Simon Baxter wrote:
>>>>> I was afraid that might be the suggestion!
>>>>>
>>>>> It seems pretty random when the CAM will crash.  It is possible it's
>>>>> only on certain channels, and only one of the CAMs - it only happens
>>>>> very rarely....
>>>>
>>>> So you have 2 identical CAMs (Alphacrypt) (with the same firmware?),
>>>> and exactly one of them sometimes fails, right?
>>>>
>>>> Have you tried swapping the two CAMs?
>>>> This should tell us whether the problem is with the CAM or with
>>>> the CI adapter.
>>>>
>>>> Klaus
>>>
>>> I've discovered this happens to both CAMs, so it's either not a hardware
>>> issue, or both CAMs are affected.
>>>
>>> Managed to capture the following logs prior to the CAM dropping from
>>> "AlphaCrypt" to "CAM Ready" (with no decrypting)
>>>
>>> Sep  2 08:17:21 freddy vdr: [27702] switching to channel 11
>>> Sep  2 08:17:21 freddy vdr: [1150] transfer thread ended (pid=27702,
>>> tid=1150)
>>> Sep  2 08:17:21 freddy vdr: [27702] buffer stats: 110356 (5%) used
>>> Sep  2 08:17:21 freddy vdr: [6564] transfer thread started (pid=27702,
>>> tid=6564)
>>> Sep  2 08:17:21 freddy vdr: [1152] TS buffer on device 1 thread ended
>>> (pid=27702, tid=1152)
>>> Sep  2 08:17:21 freddy vdr: [1151] buffer stats: 75388 (3%) used
>>> Sep  2 08:17:21 freddy vdr: [1151] receiver on device 1 thread ended
>>> (pid=27702, tid=1151)
>>> Sep  2 08:17:21 freddy vdr: [6565] receiver on device 1 thread started
>>> (pid=27702, tid=6565)
>>> Sep  2 08:17:21 freddy vdr: [6566] TS buffer on device 1 thread started
>>> (pid=27702, tid=6566)
>>> Sep  2 08:17:23 freddy vdr: [6564] setting audio track to 1 (0)
>>> Sep  2 08:17:34 freddy vdr: [27702] switching to channel 1
>>> Sep  2 08:17:34 freddy vdr: [6564] transfer thread ended (pid=27702,
>>> tid=6564)
>>> Sep  2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
>>> continuity errors
>>> Sep  2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
>>> continuity errors
>>> Sep  2 08:17:34 freddy vdr: [27702] buffer stats: 63544 (3%) used
>>> Sep  2 08:17:34 freddy vdr: [6567] transfer thread started (pid=27702,
>>> tid=6567)
>>> Sep  2 08:17:34 freddy vdr: [6566] TS buffer on device 1 thread ended
>>> (pid=27702, tid=6566)
>>> Sep  2 08:17:34 freddy vdr: [6565] buffer stats: 62980 (3%) used
>>> Sep  2 08:17:34 freddy vdr: [6565] receiver on device 1 thread ended
>>> (pid=27702, tid=6565)
>>> Sep  2 08:17:34 freddy vdr: [6568] receiver on device 1 thread started
>>> (pid=27702, tid=6568)
>>> Sep  2 08:17:34 freddy vdr: [6569] TS buffer on device 1 thread started
>>> (pid=27702, tid=6569)
>>> Sep  2 08:17:38 freddy vdr: [6567] transfer thread ended (pid=27702,
>>> tid=6567)
> 	> > Sep  2 08:17:38 freddy vdr: [6569] TS buffer on device 1 thread ended
>>> (pid=27702, tid=6569)
>>> Sep  2 08:17:38 freddy vdr: [6568] buffer stats: 193828 (9%) used
>>> Sep  2 08:17:38 freddy vdr: [6568] receiver on device 1 thread ended
>>> (pid=27702, tid=6568)
>>> Sep  2 08:17:39 freddy vdr: [27702] switching to channel 1
>>> Sep  2 08:17:39 freddy vdr: [27702] buffer stats: 116748 (5%) used
>>> Sep  2 08:17:39 freddy vdr: [27702] info: Channel not available!
>>> Sep  2 08:17:41 freddy vdr: [27702] switching to channel 9
>>> Sep  2 08:17:41 freddy vdr: [6570] transfer thread started (pid=27702,
>>> tid=6570)
>>> Sep  2 08:17:41 freddy vdr: [6570] setting audio track to 1 (0)
>>> Sep  2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
>>> device 0: Input/output error
>>> Sep  2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
>>> device 0: Input/output error
>>> Sep  2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
>>> device 0: Input/output error
>>> Sep  2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
>>> initialised successfully
>>
>> This looks more like a driver bug to me.
> 
> Well maybe but unfortunately responds to my mails in linux-dvb /
> linux-media mailinglist for that problem.
> 
> @Klaus: 
> If that problem happens, a manual reset of the cam under vdr's
> menu->settings->ci brings the cam back.
> 
> What about trying to reset a cam automatically when it's Status is !=
> msReady?
> 
> Like this:
> diff --git a/device.c b/device.c
> index 681049b..7904de2 100644
> --- a/device.c
> +++ b/device.c
> @@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView
>    if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
>       for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) {
>           SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used
> +         if (CamSlot->ModuleStatus() == msPresent) 
> +            CamSlot->Reset();
>           if (CamSlot->ModuleStatus() == msReady) {
>              if (CamSlot->ProvidesCa(Channel->Caids())) {
>                 if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {

Have you tested this?
Did it actually work?

Klaus
Linux TV Dec. 13, 2010, 1:04 a.m. UTC | #2 
>>>> Sep  2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
>>>> device 0: Input/output error
>>>> Sep  2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
>>>> initialised successfully
>>>
>>> This looks more like a driver bug to me.
>>
>> Well maybe but unfortunately responds to my mails in linux-dvb /
>> linux-media mailinglist for that problem.
>>
>> @Klaus:
>> If that problem happens, a manual reset of the cam under vdr's
>> menu->settings->ci brings the cam back.
>>
>> What about trying to reset a cam automatically when it's Status is !=
>> msReady?
>>
>> Like this:
>> diff --git a/device.c b/device.c
>> index 681049b..7904de2 100644
>> --- a/device.c
>> +++ b/device.c
>> @@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, 
>> int Priority, bool LiveView
>>    if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
>>       for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = 
>> CamSlots.Next(CamSlot)) {
>>           SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it 
>> can't be used
>> +         if (CamSlot->ModuleStatus() == msPresent)
>> +            CamSlot->Reset();
>>           if (CamSlot->ModuleStatus() == msReady) {
>>              if (CamSlot->ProvidesCa(Channel->Caids())) {
>>                 if 
>> (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), 
>> CamSlot->SlotNumber())) {
>
> Have you tested this?
> Did it actually work?
>
> Klaus

Will give it a try and report back....
Marco Skambraks Dec. 18, 2010, 5:33 p.m. UTC | #3 
hello Klaus,

I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650
I used a alphacrypt light and I also tried the classic module

always the same behavior - if I zap from encrypted channel to encrypted 
channel in some situations vdr says "channel not available"
if I reset the cam manually it works again immediately
I also tried vdr 1.4 with my old tt ff c2300 and I had no problems

maybe its a general vdr 1.7.x cam handling problem

any idea - what I can do or test to identify where the problem is?

thanks

marco



On Mon, 13 Dec 2010, Simon Baxter wrote:

>>>>> Sep  2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
>>>>> device 0: Input/output error
>>>>> Sep  2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
>>>>> initialised successfully
>>>> 
>>>> This looks more like a driver bug to me.
>>> 
>>> Well maybe but unfortunately responds to my mails in linux-dvb /
>>> linux-media mailinglist for that problem.
>>> 
>>> @Klaus:
>>> If that problem happens, a manual reset of the cam under vdr's
>>> menu->settings->ci brings the cam back.
>>> 
>>> What about trying to reset a cam automatically when it's Status is !=
>>> msReady?
>>> 
>>> Like this:
>>> diff --git a/device.c b/device.c
>>> index 681049b..7904de2 100644
>>> --- a/device.c
>>> +++ b/device.c
>>> @@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, 
>>> int Priority, bool LiveView
>>>    if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
>>>       for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = 
>>> CamSlots.Next(CamSlot)) {
>>>           SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it 
>>> can't be used
>>> +         if (CamSlot->ModuleStatus() == msPresent)
>>> +            CamSlot->Reset();
>>>           if (CamSlot->ModuleStatus() == msReady) {
>>>              if (CamSlot->ProvidesCa(Channel->Caids())) {
>>>                 if 
>>> (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), 
>>> CamSlot->SlotNumber())) {
>> 
>> Have you tested this?
>> Did it actually work?
>> 
>> Klaus
>
> Will give it a try and report back.... 
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

--------------------------------------------------
AMMEC - Accessible MultiMedia Entertainment Center

http://www.ammec.de
Support Telefon: +49 6421 968255
Linux TV Dec. 22, 2010, 11:14 p.m. UTC | #4 
> hello Klaus,
>
> I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650
> I used a alphacrypt light and I also tried the classic module
>
> always the same behavior - if I zap from encrypted channel to encrypted 
> channel in some situations vdr says "channel not available"
> if I reset the cam manually it works again immediately
> I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
>
> maybe its a general vdr 1.7.x cam handling problem
>
> any idea - what I can do or test to identify where the problem is?
>
> thanks

I had assumed this was due to some problem with CAM keys from the provider 
expiring, or something.  I still intermittantly get "channel not available", 
but haven't found any way to recreate the problem at will.

I also occasionally have a CAM crash - where the status in goes from 
"ALPHACRYPT" to "CAM PRESENT" or "CAM READY".  A manual reset (or multiple) 
fixes this, but I get no decryption during a "crash".

...problems I've had to live with for months.  Gave up asking and installed 
an FTA satellite dish for 50% of my mostly watched channels.
Olliver Schinagl Dec. 23, 2010, 12:45 a.m. UTC | #5 
On 12/23/10 00:14, Simon Baxter wrote:
>> hello Klaus,
>>
>> I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect
>> ct-3650
>> I used a alphacrypt light and I also tried the classic module
>>
>> always the same behavior - if I zap from encrypted channel to
>> encrypted channel in some situations vdr says "channel not available"
>> if I reset the cam manually it works again immediately
>> I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
>>
>> maybe its a general vdr 1.7.x cam handling problem
>>
>> any idea - what I can do or test to identify where the problem is?
>>
>> thanks
>
> I had assumed this was due to some problem with CAM keys from the
> provider expiring, or something.  I still intermittantly get "channel
> not available", but haven't found any way to recreate the problem at
> will.
I have exactly this aswel. It happens from 'surfing channels'. Never
happens while watching the same channel continuously. Cannot say for
sure it doesn't happen when surfing within the same bouquet.
>
> I also occasionally have a CAM crash - where the status in goes from
> "ALPHACRYPT" to "CAM PRESENT" or "CAM READY".  A manual reset (or
> multiple) fixes this, but I get no decryption during a "crash".
Yep, also this, only for "Conax Conditional Acess". Resetting it works
best when using an FTA channel it seems.
>
> ...problems I've had to live with for months.  Gave up asking and
> installed an FTA satellite dish for 50% of my mostly watched channels.
I'm looking at an oscam solution right now, but need to get a proper
card reader, or try to get my old towitoko chipdrive going.
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Halim Sahin Dec. 23, 2010, 3:08 a.m. UTC | #6 
Hi,
This Problem is really strange. I have also tested it with different kind
of hw combinations and got always the same result.
I don't like the answers like use and ... plugin etc.
I have asked many times in vdr-portal's irc channel about this problem
and got not one useful answer.

Well except the ff card I have now tried all available dvb-c cards which
support a ci interface.

@Klaus:
It would be really nice if you can have a look into this.
Regards
Halim
Linux TV Dec. 23, 2010, 3:48 a.m. UTC | #7 
> On 12/23/10 00:14, Simon Baxter wrote:
>>> hello Klaus,
>>>
>>> I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect
>>> ct-3650
>>> I used a alphacrypt light and I also tried the classic module
>>>
>>> always the same behavior - if I zap from encrypted channel to
>>> encrypted channel in some situations vdr says "channel not available"
>>> if I reset the cam manually it works again immediately
>>> I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
>>>
>>> maybe its a general vdr 1.7.x cam handling problem
>>>
>>> any idea - what I can do or test to identify where the problem is?
>>>
>>> thanks
>>
>> I had assumed this was due to some problem with CAM keys from the
>> provider expiring, or something.  I still intermittantly get "channel
>> not available", but haven't found any way to recreate the problem at
>> will.
> I have exactly this aswel. It happens from 'surfing channels'. Never
> happens while watching the same channel continuously. Cannot say for
> sure it doesn't happen when surfing within the same bouquet.

I have multiple cards, 2x DVB-C+CAM, 2xDVB-S FTA.  I sometimes get these 
messages when watching FTA too, when encrypted channels are recording and 
changing in the background.


>>
>> I also occasionally have a CAM crash - where the status in goes from
>> "ALPHACRYPT" to "CAM PRESENT" or "CAM READY".  A manual reset (or
>> multiple) fixes this, but I get no decryption during a "crash".
> Yep, also this, only for "Conax Conditional Acess". Resetting it works
> best when using an FTA channel it seems.
>>
>> ...problems I've had to live with for months.  Gave up asking and
>> installed an FTA satellite dish for 50% of my mostly watched channels.
> I'm looking at an oscam solution right now, but need to get a proper
> card reader, or try to get my old towitoko chipdrive going.

Don't know anything about oscam...
Olliver Schinagl Dec. 23, 2010, 8:59 p.m. UTC | #8 
On 12/23/10 04:48, Simon Baxter wrote:
>> On 12/23/10 00:14, Simon Baxter wrote:
>>>> hello Klaus,
>>>>
>>>> I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect
>>>> ct-3650
>>>> I used a alphacrypt light and I also tried the classic module
>>>>
>>>> always the same behavior - if I zap from encrypted channel to
>>>> encrypted channel in some situations vdr says "channel not available"
>>>> if I reset the cam manually it works again immediately
>>>> I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
>>>>
>>>> maybe its a general vdr 1.7.x cam handling problem
>>>>
>>>> any idea - what I can do or test to identify where the problem is?
>>>>
>>>> thanks
>>>
>>> I had assumed this was due to some problem with CAM keys from the
>>> provider expiring, or something.  I still intermittantly get "channel
>>> not available", but haven't found any way to recreate the problem at
>>> will.
>> I have exactly this aswel. It happens from 'surfing channels'. Never
>> happens while watching the same channel continuously. Cannot say for
>> sure it doesn't happen when surfing within the same bouquet.
>
> I have multiple cards, 2x DVB-C+CAM, 2xDVB-S FTA.  I sometimes get
> these messages when watching FTA too, when encrypted channels are
> recording and changing in the background.
>
>
>>>
>>> I also occasionally have a CAM crash - where the status in goes from
>>> "ALPHACRYPT" to "CAM PRESENT" or "CAM READY".  A manual reset (or
>>> multiple) fixes this, but I get no decryption during a "crash".
>> Yep, also this, only for "Conax Conditional Acess". Resetting it works
>> best when using an FTA channel it seems.
>>>
>>> ...problems I've had to live with for months.  Gave up asking and
>>> installed an FTA satellite dish for 50% of my mostly watched channels.
>> I'm looking at an oscam solution right now, but need to get a proper
>> card reader, or try to get my old towitoko chipdrive going.
>
> Don't know anything about oscam...
oscam is a softcam, it requires a smartcard reader and your smartcard,
so its nothing illegal, also you can use 1 smartcard on more than 1 dvb
card, even CI-less cards.
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Halim Sahin Dec. 25, 2010, 8:48 a.m. UTC | #9 
Hello,
On Thu, Dec 23, 2010 at 09:59:19PM +0100, Oliver Schinagl wrote:
> so its nothing illegal, also you can use 1 smartcard on more than 1 dvb
> card, even CI-less cards.

I don't think that it's legal in germany or in other countries.
Please don't spam this thread with such suggestions.
The is a problem which can be reproduced 
by other vdr users as well so that should be fixed in core vdr.
Suggesting these plugins will not help everyone.
BR.
Halim
Olliver Schinagl Dec. 27, 2010, 7:54 a.m. UTC | #10 
On 12/25/10 09:48, Halim Sahin wrote:
> Hello,
> On Thu, Dec 23, 2010 at 09:59:19PM +0100, Oliver Schinagl wrote:
>> so its nothing illegal, also you can use 1 smartcard on more than 1 dvb
>> card, even CI-less cards.
> I don't think that it's legal in germany or in other countries.
I don't think softcams are illegal, using cardsharing services is ..
legally debatable, but a softcam, in combination with your own
smartcard, should be legal.

> Please don't spam this thread with such suggestions.
Hardly spam, just a suggestion/workaround to get a workable legal solution. And with all the CI-less hardware out there, from PCI cards to USB cards and even WinTV offering a cardreader only (I belive they might be using a softcam in their win-ware) this may be the only solution to some.

>The is a problem which can be reproduced 
>by other vdr users as well so that should be fixed in core vdr.
Is this problem only to VDR? or has anybody noticed this same behaviour with, say Myth or something else. Could it be a kernel bug?

It seems/feels like the cam is crashing and that's why it needs to be reset, as sometimes the cam menu brings a 'CAM: -' message, indicating it isn't initialized any longer. Unrelated btw, I sometimes have a horribly A/V sync issue when changing encrypted channels. E.g. the video runs fine, but the audio is first missing, then slowly starts dripping in, kinda like how a torrents work, until after about 10 seconds all the sound runs smoothly. It only happens occasionally though ... very strange, but could be related.

>Suggesting these plugins will not help everyone.
It very well may help people until this bug is solved. :(


Btw, I'm not sure if I mentioned, but this is happening in VDR 1.6, and I belive Halim has it on 1.7? So it has been around for quite a while. I can try patches if needed, as it should be pretty straight forward applying them on Gentoo, but 1.6 would be prefered.


>BR.
>Halim
Linux TV Dec. 27, 2010, 9:14 a.m. UTC | #11 
> Btw, I'm not sure if I mentioned, but this is happening in VDR 1.6, and I 
> belive Halim has it on 1.7? So it has been around for quite a while. I can 
> try patches if needed, as it should be pretty straight forward applying 
> them on Gentoo, but 1.6 would be prefered.

Yip - I've been experiencing this since 1.6, and kernels from 2.6.24 thru 
2.6.33.

Have tried manipulating the kernel source (dvb_ca_en50221.c) and adding 
breaks to extend wait times between READ/WRITE transactions to the CAM 
(multiple 'msleep(1);' commands).  Used to help with earlier kernels, but 
has no affect for the past 2 years.

As I've mentioned before, I don't know what else to try.

Here's the problems I have with my CAM decryptions

* intermittant CAM crash, going from 'Alphacrypt' to 'CAM Ready'
* intermittant CAM lock out.  Can't access CAM menu, but CAM still displays 
'Alphacrypt'

Both respond to reset (or multiple, up to 10 resets) and CAM comes back.

My system has 2 identical CAMs.  Problem only affects one at a time, but 
does affect both.

Also occurs in CAM versions 3.09 thru 3.16 (tried upgrading/downgrading).
diff mbox

Patch

diff --git a/device.c b/device.c
index 681049b..7904de2 100644
--- a/device.c
+++ b/device.c
@@ -239,6 +239,8 @@  cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView
   if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
      for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) {
          SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used
+         if (CamSlot->ModuleStatus() == msPresent) 
+            CamSlot->Reset();
          if (CamSlot->ModuleStatus() == msReady) {
             if (CamSlot->ProvidesCa(Channel->Caids())) {
                if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {