Re: [vdr] CAM auto resetting - feature request??

2010-12-27 Thread Simon Baxter
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).



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-26 Thread Oliver Schinagl


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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-25 Thread Halim Sahin
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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-23 Thread Oliver Schinagl

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-22 Thread Simon Baxter

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. 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-22 Thread Oliver Schinagl


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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-22 Thread Halim Sahin
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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-22 Thread Simon Baxter

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... 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-18 Thread Marco Skambraks

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-12 Thread Klaus Schmidinger
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-12 Thread Simon Baxter

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


Re: [vdr] CAM auto resetting - feature request??

2010-12-01 Thread Halim Sahin
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())) {



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2009-12-13 Thread Klaus Schmidinger
On 08.12.2009 18:36, Simon Baxter wrote:

 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)


 This looks more like a driver bug to me.

 Klaus
 
 
 Can I do a CAM Reset from svdrp?

There is no direct SVDRP command for this, but you could
send the appropriate HITK command sequence.
Or you write a plugin that implements a CAM reset command
(see PLUGINS/src/svdrpdemo for an example).

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2009-12-08 Thread Simon Baxter


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)



This looks more like a driver bug to me.

Klaus



Can I do a CAM Reset from svdrp?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2009-12-06 Thread Klaus Schmidinger
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.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2009-09-01 Thread Simon Baxter

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



I've done the usual select and reset the CAM 3 times from VDR and it's 
back in action.


Any ideas on how to further debug this?AND   any suggestions on how I 
should configure VDR to send an email alert when this problem occurs?  I 
could probably hack dvbci.c to send an email or something??



Thanks
Simon



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2009-08-18 Thread Klaus Schmidinger
On 16.08.2009 21:38, Simon Baxter wrote:
 Occasionally one of the CAMs seems to crash and if I go into Setup 
 CAM one of the CAMs changes from Alphacrypt to CAM Ready - and will
 no longer decrypt channels.  I then correspondingly get a bunch of timer
 conflicts, as 1/2 my CAM resources have vanished.  Only ever one CAM
 fails, never both.

 I rectify this by selecting the CAM, and then hitting reset (sometimes
 a couple of times) - and it comes back.

 Unless I go into the Setup  CAM menu, I'm unaware that the CAM has
 crashed.


 My request is..
 Is there a way I can either
 1)Automatically reset a CAM if it falls into this state

 or

 2)Be notified, by generating a console/kernel message, so I can know to
 come in and fix this.


 Any ideas?

 I would prefer alternative 3: find out why the CAM crashes and fix
 that ;-)

 Klaus
 
 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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2009-08-16 Thread Klaus Schmidinger
On 03.08.2009 22:54, Simon Baxter wrote:
 Hello
 
 My v 1.6.0 system has 2x Alphacrypt multi-CAMs.
 
 Occasionally one of the CAMs seems to crash and if I go into Setup 
 CAM one of the CAMs changes from Alphacrypt to CAM Ready - and will
 no longer decrypt channels.  I then correspondingly get a bunch of timer
 conflicts, as 1/2 my CAM resources have vanished.  Only ever one CAM
 fails, never both.
 
 I rectify this by selecting the CAM, and then hitting reset (sometimes
 a couple of times) - and it comes back.
 
 Unless I go into the Setup  CAM menu, I'm unaware that the CAM has
 crashed.
 
 
 My request is..
 Is there a way I can either
 1)Automatically reset a CAM if it falls into this state
 
 or
 
 2)Be notified, by generating a console/kernel message, so I can know to
 come in and fix this.
 
 
 Any ideas?

I would prefer alternative 3: find out why the CAM crashes and fix that ;-)

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2009-08-16 Thread Simon Baxter

Occasionally one of the CAMs seems to crash and if I go into Setup 
CAM one of the CAMs changes from Alphacrypt to CAM Ready - and will
no longer decrypt channels.  I then correspondingly get a bunch of timer
conflicts, as 1/2 my CAM resources have vanished.  Only ever one CAM
fails, never both.

I rectify this by selecting the CAM, and then hitting reset (sometimes
a couple of times) - and it comes back.

Unless I go into the Setup  CAM menu, I'm unaware that the CAM has
crashed.


My request is..
Is there a way I can either
1)Automatically reset a CAM if it falls into this state

or

2)Be notified, by generating a console/kernel message, so I can know to
come in and fix this.


Any ideas?


I would prefer alternative 3: find out why the CAM crashes and fix that 
;-)


Klaus


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




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2009-08-10 Thread Marco Göbenich
Hi!

Got the same problem here, would be nice to have  at least a possibility
to check for crashed CAM's per SVDRP and maybe the possibility to reset it.

Regards

Marco


Simon Baxter schrieb:
 Hello

 My v 1.6.0 system has 2x Alphacrypt multi-CAMs.

 Occasionally one of the CAMs seems to crash and if I go into Setup 
 CAM one of the CAMs changes from Alphacrypt to CAM Ready - and
 will no longer decrypt channels.  I then correspondingly get a bunch
 of timer conflicts, as 1/2 my CAM resources have vanished.  Only ever
 one CAM fails, never both.

 I rectify this by selecting the CAM, and then hitting reset
 (sometimes a couple of times) - and it comes back.

 Unless I go into the Setup  CAM menu, I'm unaware that the CAM has
 crashed.


 My request is..
 Is there a way I can either
 1)Automatically reset a CAM if it falls into this state

 or

 2)Be notified, by generating a console/kernel message, so I can know
 to come in and fix this.


 Any ideas?

 ___
 vdr mailing list
 vdr@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


-- 
Needful GbR  Rheinstraße 60a  Telefon +49 (0) 26 24 / 95 29 301
 56203 Hoehr-Grenzhausen  Telefax +49 (0) 26 24 / 95 29 303
 http://www.needful.deE-Mail  m...@needful.de


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr