[vdr] major CI trouble with 1.6.0 on a FF and Alphacrypt Classic CAM/Sky

Hans-Peter Jansen hpj at urpla.net
Sun Nov 14 23:08:47 CET 2010


Hi,

I'm in a desperate crusade to get vdr 1.6.0 working properly _again_ 
with Sky on a FF Nexus-S rev2.3 with original CI/Alphacrypt Classic CAM 
and a betacrypt based Sky subscription. 

Being a long time vdr user (since about 2002), I rearranged my setup to 
better fit my family needs. Since my server is running 24/7 for other 
reasons anyway, I added two WinTV-HVR4000 and a Nexus-S 2.3 with CI/CAM 
to it. OS is a openSUSE 11.1/i586 with a collection of newer kernels: 
2.6.34.5, 2.6.34.7, 2.6.36, the sat input is from a Kathrein EXR 508/T 
switching matrix, located nearby the server and feeded by a Quad-LNB. 
The sat installation was done completely by a professional.

Before the switch to server based vdr, I used older vdr versions with 
older SuSEs in a single "home video theater" setup (apart from NFS 
based recording), and after some fiddling, it worked great for many 
years (it took unloading and reloading the dvb drivers on startup 
before running vdr in order to get the CAM operational reliably). We 
never used another set top box for TV watching since the very 
beginning. Even my wife fully acknowledged the system (which is quite 
hard to archive for _any_ electronic equipment, BTW..).

Since the very first server setup, I have stability problems with Sky 
recordings. It manifests in either:
 1) no proper CAM detection: VDR shows CAM exists/vorhanden instead of 
    AlphaCrypt (no recordings possible at all)
 2) proper CAM detection: but totally distorted recordings with many PES
    error messages in vdr log
 3) dropouts in recordings (vdr restarts with no apparent reason) until
    final break-down with behaviour as described in 1)

1) could be alleviated with the dvb driver unload/reload trick (I'm 
using an init script, that loads a given list of dvb drivers on start 
and unloads them in reverse order on stop. The driver list is not 
complete due to a bug in cx8802, that cannot be unloaded until the 
newest kernel versions, but that only affects the (at the moment 
uninteresting) WinTV-HVR4000 part: 
http://www.mail-archive.com/linux-media%40vger.kernel.org/msg23580.html)
Sometimes a pull/push of the CAM fixes it for a certain time, but this 
is not an acceptable concept for obvious reasons.

2) This might be due using to an older AlphaCrypt firmware, and didn't 
happen anymore after update to 3.20. 

3) happens massively now. See VDR log link below.

I already tried to lay the 80 wire ribbon optimally between the Nexus 
and the CI (no kinks, etc).  

My AlphaCrypt settings:
CAM 1: 'AlphaCrypt 3.20 (c) Mascom GmbH'
CAM 1: 'Modul Einstellungen'
CAM 1: 'Sprache/Language: DEUTSCH'
CAM 1: 'Smartkarten Meldungen: AUS'

Slot 1: <== Text Last (5) 'CA-Systeme: SINGLE (nur von Smartkarte)'
Slot 1: <== Text Last (5) 'CA-Anmeldung: DYNAMIC (immer erneuern)'
Slot 1: <== Text Last (5) 'Erzwinge Lesen originale PMT: AUS'
Slot 1: <== Text Last (5) 'CA-PMT L366schzeit: 0 s '
Slot 1: <== Text Last (5) 'CI-Fehler374berwachung: 1500 ms '
Slot 1: <== Text Last (5) 'dbox Kompatibilit344t: EIN '

The vdr version, I using here is available here:
https://build.opensuse.org/project/show?project=home%3Afrispete%3Avdr
It's using the usual patches 1.6.0-{1,2} from Klaus, and the usual 
adjustments due to gcc and kernel compatibility. Don't let the 
vdr-1.6.0-2_extensions.diff.gz perturb you, the problems happen with 
and without applying it. My build does enable DebugProtocol in ci.c 
(with sed in the spec)..

Today, we tried to enjoy Sebastian Vettels thriller/victory on Sky, but 
miserably failed due to continued drop outs and multiple break-downs.
The full disaster is reflected by the logs below.

In short, the logs are flooded with countless messages like:

Nov 14 21:46:46 tyrex vdr: [8632] Slot 1: no module present
Nov 14 21:46:46 tyrex vdr: [8632] CAM 1: no module present
Nov 14 21:46:47 tyrex vdr: [8632] Slot 1: module present
Nov 14 21:46:47 tyrex vdr: [8632] CAM 1: module present
Nov 14 21:46:59 tyrex vdr: [8632] Slot 1: no module present
Nov 14 21:46:59 tyrex vdr: [8632] CAM 1: no module present
Nov 14 21:46:59 tyrex vdr: [8632] Slot 1: module present
Nov 14 21:46:59 tyrex vdr: [8632] CAM 1: module present
Nov 14 21:47:16 tyrex vdr: [8643] streamdev-server: Detaching current 
receiver
Nov 14 21:47:16 tyrex vdr: [8643] streamdev-server: Detaching current 
receiver
Nov 14 21:47:16 tyrex vdr: [8643] streamdev-server: Detaching current 
receiver

and peppered with:

Nov 14 22:07:31 tyrex vdr: [25348] cAudioRepacker(0xC1): skipped 1148 
bytes while syncing on next audio frame
Nov 14 22:07:31 tyrex vdr: [25348] cAudioRepacker(0xC0): skipped 1148 
bytes while syncing on next audio frame

only finally leading to a vdr restart, that results in state 1).

What am I do wrong? Is this really such a dead road as it looks right 
now? I considered switching to 1.7, but if I'm unable to get this to 
work properly within a pure SD environment, how can additional HD and 
other complexity solve this (without adding a lot of others issues all 
over the plate). 

DVB driver reload: ftp://urpla.net/dvb.log
VDR log: ftp://urpla.net/vdr.log 
VDR log from 12:00 to 22:16 today: ftp://urpla.net/vdr-full.log
full boot log: ftp://urpla.net/boot.msg

Let me know, if I can provide more infos. 

Any hints to solve this problem are highly appreciated.

TIA,
Pete



More information about the vdr mailing list