Si tienes OSCam bien configurado, aunque estén chupando de tu tarjeta 4 primas solo va a haber una lectura de ECM real, el resto se sirven como cache siempre que se estén solicitando a la vez (o hasta que se genere otra ECM).
Si sirve para hacerte una idea, esta es mi Raspi:
Como podrás ver, una media de apenas un 3% de carga utilizándola como servidor con OSCam (unos 16 readers con sus users) y almacenamiento en la nube. Nadie que no quiera destinarla para algo más que simplemente compartir, la va a saturar.
Dudo mucho que exista una tabla o algo que especifique lo que comentas, pero todo es posible en esta vida.... xD
Sobre lo que comentas del número de solicitudes y porque no lo capa... eso solo te lo puede responder el operador jejeje Si no recuerdo mal, en Francia ya se aplica una medida de ese tipo.
Te pego directamente la explicación del compañero Lucifer, que hizo en un
hilo acojonante que se curró hace un tiempo:
Una Plataforma por ejemplo Canal + satelite, pues envia a nuestros receptores la señal de video y audio encryptada, evidentemente lo hacen para que solo vean esta señal de video unas personas concretas o sea los que pagan.
Este flujo de datos (video y audio) lo codifican con una clave secreta que es neceseria conocerla para poder desencryptar el video+audio y asi obtener el visionado, esta clave secreta recibe el nombre de CONTROL WORD cuya abreviatura se conoce como CW.
Evidentemente como es normal y para que no se tenga acceso a esa clave secreta, pues esta la cifran, y ademas de cifrarla pues la van cambiando cada poco tiempo 10-15 segundos por ejemplo, y que es lo que se utiliza para cifrar la clave secreta pues con lo que se conoce como ENTLITEMENT CONTROL MESSAGE cuya abreviatura seria ECM.
¿Por lo tanto como se produciria el visionado? pues el abonado necesitaria disponer un receptor satelite para recibir el video+audio encryptado, y ademas pues de una utilidad para poder conocer la CW y asi desencryptar y obtener el visionado, pues esa utilidad por ejemplo seria la tarjeta de abonado, por lo tanto la funcion de la la tarjeta de abonado seria desencryptar la ECM para tomar la CW y asi poder desencryptar la señal de video+audio y obtener el visionado, para controlar que la tarjeta de abonado pueda realizar esta accion pues esta debe estar autorizada para realizar este proceso, para ello la plataforma por ejemplo canal + satelite envia cada cierto tiempo unos derechos para mantener la tarjeta de abonado autorizada, estas por asi llamarlas autorizaciones se envia a traves de lo que se conoce como ENTLITEMENT MANAGENT MESSAGE, cuya abreviatura se le conoce como EMM.
En este caso vamos hacer mencion que existen 3 grupos de EMM que nos interesa sobre todo conocer, las cuales serian:
EMM-G: EMM globales, estan son recibidas por todas las tarjetas de abonado de la plataforma a las que estamos suscritos, se utilizan para hacer modificaciones en los abonos como sus propio nombre indica globales, o sea para todos los abonados.
EMM-S: EMM shared, estan son enviado a un grupo concreto de abonados, como por ejemplo a todo lo abonado que tengan el c+ total pues le vamos a regalar el canal champion league, pues para esta suscripccion se enviaria esta emm-s que recibirian solo el grupo de abonados con c+ total.
EMM-U: EMM unicas, estas son enviadas unicamente a una sola tarjeta de abonado, y se utilizan cuando por ejemplo compramos una pelicula en taquilla de canal + satelite, pues se nos envaria solo a nuestra tarjeta los derechos para poder visualizarla.
Lo dicho seria a groso modo, para que se entienda ciertos conceptos, que debemos tener como base para que sirven y como hemos visto seria:
CW---> El encargado de desencryptar la señal de video y audio.
ECM--> Es el encargado de cifrar el CW
TARJETA ABONADO--> La encargada de descifrar la ECM, cojer la CW y asi obtener el visionado
EMM--> El encargado de mantener la autorizacion a la tarjeta de abonado para realizar el proceso de descifrar ECM.
Bien pues teniendo en cuenta esto pues el proceso seria:
http://**********.us/a/img90/5939/sinnombrec.png
Que observando el esquema estilo cutre que he hecho seria
1º La plataforma envia la señal en bruto donde viaja audio, video, ecm, emm, etc...
2º La señal en bruto es recojida por nuestra antena parabolica
3º La antena parabolica envia la señal en bruto al fronted
4º El fronted que consta de sintonizador y demulador convierte la señal en bruto en flujo TS
5º Este flujo TS pasa por el modulo llamado CA (CONDICIONAL ACCESS) que en este caso actua nuestra tarjeta de abonado y se desencrypta las ecm dandonos la CW.
6º Luego pasa el demuxer donde este TS ya desencryptado se separa por ejemplo en datos audio y video
7º El demuxer lo pasa al televisor y obtenemos el visiando.
Pues bueno he puesto el esquema y estos 7 pasos para que comprendais que en LINUX lo que permite controlar estos componentes (fronted, tarjeta de abonado, demux...) recibe el nombre de DVBAPI, que veremos mas adelante la importancia del DVBAPI para visionar con OSCAM.
En este ejemplo estariamos utilizando nuestra tarjeta de abonado, que se introduce en la ranura del receptor, esta ranura encargada de leer nuestra tarjeta de abonado recibiria el nombre de internal Slot y su abreviatura se conoceria como SCI
Explicarlo más simple es dificil, de la misma manera que canalpus sabe que la ID (por llamarlo de alguna manera) de una tarjeta está al corriente de pago, sabe que esa tarjeta ha comprado un evento o tienen contratados X canales. Da la casualidad de que si al hacer una compra ya sea por tlfno o con el deco de la plataforma, tienes mal configurada la emu para recibir ese "paquete mágico", has gastado dinero a lo tonto... ya que ese "paquete mágico" no se envía constantemente desde el satélite. Resumiendo, el proceso sería el siguiente:
Tu llamas para contratar X evento. La operadora da orden para que desde el satélite se envíe el paquete mágico que solo a tí te permita decodificar ese evento. Si tu emu no está atenta para coger ese paguete mágico, lo pierdes porque "pasa de largo".
No me sé explicar mejor, lo siento.