cccam y dvbapi por separado

[hperez]

Versión modificada de cccam 2.1.1 (cccam y dvbapi por separado)

He cogido la versión 2.1.1 (con la 2.1.3 es mucho más difícil hacer esto) y le he hecho una serie de cambios/mejoras.

Normalmente al instalar cccam aparece como camd dvbapiCAS, que arranca tanto cccam como dvbapi_module. Algunos renombran dvbapi_module para que no arranque, pero hay veces que sí es conveniente poder usarlo (ya que por ejemplo cccam+multicas pierde un hop).

En mi modificación dvbapiCAS y cccam aparecen de forma separada, cada uno de los dos se puede activar o desactivar según nos haga falta. cccam por sí solo no sirve de mucho, envía y recibe datos, pero no veremos nada. Hay que usar junto a cccam otra camd, como multicas, mgcamd o dvbapiCAS (dvbapi_module). Lo bueno es que ahora dvbapi_module es opcional, se puede desactivar si no hace falta, por ejemplo si vamos a usar cccam+multicas.

Otro fallo corregido: en las versiones normales (tanto de 2.1.1 como de 2.1.3) cccam (y dvbapi_module) nunca se podían detener. Aunque lo desactivaramos, los procesos seguían ejecutándose, era necesario reiniciar el deco para detenerlos realmente. Ahora esto lo he conseguido solucionar. Los procesos realmente se detienen cuando se desactivan las camd, dejando de consumir memoria y CPU.

Probaré esta versión modificada un par de días para ver si va bien y no surgen problemas imprevistos. Y si interesa, la subiré a algún lado para que la probéis vosotros.

De momento he visto que ahora multicas se conecta más rápido a cccam :D

 

[jc25]

Si usas la version 2.1.1 y multicas, puedes borrar la carpeta Dvbapicas a saco y no te complicas, dejando en module.seq solo MultiCAS

 

[oscar_fl]

Mejor renombrarlo y que no se ejecute por si queremos usarlo mas tarde

 

[hperez]

Lo bueno es que con mi modificación no es necesario renombrar o borrar nada. Con el mando a distancia elegimos si se ejecuta dvbapi o no.

Por cierto, ¿sabéis si es realmente necesario que el nombre acabe en CAS? (dvbapiCAS) Se me ha ocurrido renombrarlo a dvbapi (name = dvbapi en openxcas.conf) y entonces no veía nada. El dvbapi_module se estaba ejecutando, pero no se veía ningún canal. Lo he vuelto a dejar en dvbapiCAS y vuelve a funcionar.

Bueno, seguiré haciendo pruebas y si la cosa va bien esta noche o mañana subiré mis modificaciones.

 

[hperez]

Bueno, si la queréis probar, aquí va. Es la primera versión, puede contener errores.

http://depositfiles.com/files/okuktqsch

Para instalarlo, recomiendo los siguientes pasos:

Hacer copias de seguridad
Copiar vuestros CCcam.cfg, CCcam.channelinfo, CCcam.prio y CCcam.providers a un sitio seguro. O copiar los directorios completos de cccam para poder restaurarlos más tarde si no os gusta esta versión.

Desactivar camd
Entrar por telnet y ejecutar estas órdenes:

sh /tmp/kill_EMUs.sh

(cccam 2.1.1)

killall ld.so.1
killall dvbapi_module

(cccam 2.1.3)

killall CCcam.mipsel
killall dvbapi_module

Borrar cccam
Borrar los directorios de la instalación anterior de cccam.

En la versión 2.1.1 borrar los directorios /PLUGINS/lib/ y /PLUGINS/OpenXCAS/dvbapiCAS.

En la versión 2.1.3 borrar los directorios /PLUGINS/OpenXCAS/dvbapiCAS y /PLUGINS/OpenXCAS/DeformCCC

Instalación
Copiar el fichero cccam-2.1.1-by_hperez_v1.tgz en el deco, por ejemplo a /tmp, y ejecutar estas órdenes:

cd /PLUGINS/OpenXCAS/
tar xvzf /tmp/cccam-2.1.1-by_hperez_v1.tgz

Eso creará dos directorios nuevos, dvbapiCAS y CCcam, dentro de OpenXCAS, con los permisos adecuados.

Una vez hecho esto ya se puede borrar el fichero /tmp/cccam-2.1.1-by_hperez_v1.tgz

Volver a copiar a /PLUGINS/OpenXCAS/CCcam/ vuestros CCcam.cfg, CCcam.prio y CCcam.providers. Si se va a usar multicas, recomiendo dejar el CCcam.channelinfo que va en el paquete, ya que así multicas se conectará muchísimo más rápido a cccam.

Editar CCcam.cfg y cambiar estas rutas:

CAID PRIO FILE : /PLUGINS/OpenXCAS/CCcam/CCcam.prio
PROVIDERINFO FILE : /PLUGINS/OpenXCAS/CCcam/CCcam.providers
CHANNELINFO FILE : /PLUGINS/OpenXCAS/CCcam/CCcam.channelinfo

Activación
Ahora ya os podéis ir en el deco a Plugins, a la opción para elegir las camd y sus prioridades. Ahí, además de dvbapiCAS os deberá aparecer cccam_server.

Poned las camd en este orden:

MultiCAS o dvbapiCAS o mgcamd
cccam_server
SboxCAS o newcs

Por ejemplo, esto es lo que yo tengo:

MultiCAS
#dvbapiCAS
cccam_server
SboxCAS

Y ya está.

MultiCAS+cccam_server os permitirá ver y grabar. Por otro lado con dvbapiCAS+cccam_server sólo podréis ver, no grabar, pero al no perder ningún hop os puede hacer más fácil ver algún canal más.

 

[softjad]

hperez, me puedes decir que RAM dispodible tienes en el modo Multicas + cccam + sbox?

Salu2

 

[hperez]

Pues ahora mismo, con el deco en stand-by:

Mem: 89988K used, 10496K free, 0K shrd, 2120K buff, 38148K cached

 

[pinteno]

Hola, he probado esta modificación y va bien. Seguiré probando.

Muchas gracias por el trabajo!!!

 

[majinga zeto]

Fenomenal trabajo hperez!!!!

Una duda sobre el orden de las camd...suponiendo que no tengamos local y teniendo en cuenta que, tanto Multicas, Mgcamd o dvbapi se conectan al cccam_server para recibir tarjetas y visionar, no sería más conveniente poner el cccam_server el primero de la lista para que arranque antes que los visores?

Otra cosa y abusando de tus conocimientos, sería posible un script o algo parecido que al ejecutarlo nos mostrara un log/trace con todas la peticiones y transacciones que realiza el cccam_server en tiempo real?

Un saludo y gracias por el trabajo en cualquier caso.

 

[hperez]

Fenomenal trabajo hperez!!!!

Una duda sobre el orden de las camd...suponiendo que no tengamos local y teniendo en cuenta que, tanto Multicas, Mgcamd o dvbapi se conectan al cccam_server para recibir tarjetas y visionar, no sería más conveniente poner el cccam_server el primero de la lista para que arranque antes que los visores?

No lo sé. Yo creo que la camd que aparece en primer lugar es la que usa openxcas para ir pasándole los datos a descodificar, y cccam_server carece del código necesario para procesar esos datos (de eso se encarga dvbapi), así que no sé qué pasaría si se pone cccam_server en primer lugar. Quizás la cosa seguiría funcionando, pero tampoco le veo un gran beneficio en hacerlo porque en realidad todas las camd se arrancan más o menos a la vez.

Otra cosa y abusando de tus conocimientos, sería posible un script o algo parecido que al ejecutarlo nos mostrara un log/trace con todas la peticiones y transacciones que realiza el cccam_server en tiempo real?

Si esa información aparece en los mensajes de salida de cccam, quizás fuera posible desviar esos mensajes a un fichero en /tmp de modo que se pudieran visualizar al pulsar >>

 

[majinga zeto]

Si esa información aparece en los mensajes de salida de cccam, quizás fuera posible desviar esos mensajes a un fichero en /tmp de modo que se pudieran visualizar al pulsar >>

Bueno, te adelanto que a la información a la que me refiero es a la misma que cuando arrancas manualmente el cccam_server por telnet, la pega es que sólo se puede hacer matando los procesos del cccam y arrancándolo manualmente, cosa bastante tediosa si tienes el servidor funcionando y no tienes el por qué reiniciarlo para eso exclusivamente.

Sobre el orden de las camd...supongo que no tendrá ningún efecto tal y como dices, además de que siempre tardará más en arrancar el cccam_server, por mucho que lo pongamos el primero, al tener que cargar todas las tarjetas de nuestros Leete las normas. Lo miraré pero no tengo ninguna expectativa al respecto.

Lo primero que he notado al separar el cccam_server del dvpapi es que los HD españoles me han enganchado muchísimo más rápido que con todo junto como lo tenía (2.1.1). Gran trabajo y seguiré reportando cualquier diferencia que aprecie.

 

[hperez]

Bueno, te adelanto que a la información a la que me refiero es a la misma que cuando arrancas manualmente el cccam_server por telnet, la pega es que sólo se puede hacer matando los procesos del cccam y arrancándolo manualmente, cosa bastante tediosa si tienes el servidor funcionando y no tienes el por qué reiniciarlo para eso exclusivamente.

Probablemente mandar la salida de cccam a un fichero sea fácil. Lo que pasa es que habría que conservar sólo las últimas líneas, o de lo contrario el fichero crecería muchísimo (además de que al pulsar >> seguramente se trataría de mostrar todo el fichero completo y sería un caos). No soy un experto en esto de los scripts, aunque quizás con el comando tail se podría hacer...

Sobre el orden de las camd...supongo que no tendrá ningún efecto tal y como dices, además de que siempre tardará más en arrancar el cccam_server, por mucho que lo pongamos el primero, al tener que cargar todas las tarjetas de nuestros Leete las normas. Lo miraré pero no tengo ninguna expectativa al respecto.

Lo primero que he notado al separar el cccam_server del dvpapi es que los HD españoles me han enganchado muchísimo más rápido que con todo junto como lo tenía (2.1.1). Gran trabajo y seguiré reportando cualquier diferencia que aprecie.

Había pensado en tratar de hacer la misma modificación para cccam 2.1.3, pero en los días que llevo usando la v. 2.1.1 para mí que va bastante mejor que la 2.1.3, así que a lo mejor seguiré un tiempo usando la 2.1.1 :D

 

[pinteno]

Hola, una pregunta. ¿Cómo puedo hacer para visionar por dviapi? ¿Simplemente le pongo almohadilla al MultiCAS y se la quito al dvbapiCAS? Es que no me funciona...

 

[hperez]

Hola, una pregunta. ¿Cómo puedo hacer para visionar por dviapi? ¿Simplemente le pongo almohadilla al MultiCAS y se la quito al dvbapiCAS?

Sí.

Es que no me funciona...

Es que tarda un buen rato, al menos 1 minuto o más. Y ves cambiando de canal de vez en cuando, porque si lo dejas fijo parece que no echa a andar.

Casi que he descubierto que tras reiniciar las camd, es mejor poner un canal en abierto, así parece que cccam arranca más rápido.

 

[txemax]

Genial hperez. Con un mísero HD en hops2 y poquísimos cortes.
Gracias.

 

[majinga zeto]

Otro fallo corregido: en las versiones normales (tanto de 2.1.1 como de 2.1.3) cccam (y dvbapi_module) nunca se podían detener. Aunque lo desactivaramos, los procesos seguían ejecutándose, era necesario reiniciar el deco para detenerlos realmente. Ahora esto lo he conseguido solucionar. Los procesos realmente se detienen cuando se desactivan las camd, dejando de consumir memoria y CPU.

hperez, me encuentro con un problema...
Yo alterno mgcamd (para chameleon2) con dvbapi según mis necesidades, entonces, cuando arranco/paro las camd desde el panel con el boton azul start/stop, también se reinicia el cccam_server y eso es un problema. Con la versión sin modificar no me ocurria al no detenerse los procesos.
Alguna sugerencia para evitar el reinicio de server y que se quede siempre en marcha a menos que se reinicie el deco?

 

[hperez]

Modifica el fichero /PLUGINS/OpenXCAS/CCcam/openxcas.conf, donde pone

daemon = ld.so.1

cámbialo a

daemon = launch_cccam.sh

 

[majinga zeto]

ummm, el segundo daemon hace referencia a un script? que script es ese?

 

[majinga zeto]

Ok, ya veo donde está y lo que hace el script...pero yo me refería a que el cccam_server se ejecutara en segundo plano sin que aparezca en el panel de camd. Supongo que poniendo ese script en el arranque del deco y borrando el openxcas.conf de la carpeta cccam será suficiente?

 

[hperez]

Supongo que poniendo ese script en el arranque del deco y borrando el openxcas.conf de la carpeta cccam será suficiente?

Exacto. Borra el openxcas.conf y copia el launch_cccam.sh a /DISK2/etc/start.d/ (igual tienes que renombrarlo a algo como S50Cccam).

De esta manera el cccam_server estará siempre ejecutándose.