Error de NCam "No se puede decodificar": Causas& Soluciones

Si estás buscando una solución para el error de ncam no se puede decodificar, lo primero que debes entender es que este error no es un solo problema: son al menos cuatro problemas diferentes que producen el mismo mensaje de registro. Reiniciar NCam y volver a ingresar tu línea es el consejo que encontrarás en la mayoría de los foros. Casi no soluciona nada. Esta guía trabaja a través de la causa real siguiendo el ciclo de vida del ECM desde el análisis de PMT hasta la aplicación de la palabra de control, para que puedas aislar exactamente dónde se está rompiendo tu configuración.

Lo que realmente significa "No se puede decodificar" en NCam

NCam es un fork de OSCam. El directorio de configuración es típicamente/etc/tuxbox/config/ y los archivos siguen la nomenclatura oscam.* —ncam.conf,ncam.server,ncam.dvbapi,ncam.user. Si estás acostumbrado a OSCam, la estructura es idéntica. El comportamiento también es idéntico, incluyendo cómo registra las fallas de decodificación.

El mensaje "no se puede decodificar" significa que NCam recibió una palabra de control (CW) de un lector, pero el descrambler la rechazó, o no llegó ninguna CW a tiempo. La transmisión permanece encriptada. La caja muestra una pantalla negra. Esto es distinto de otros tres estados de falla que verás en los registros:

• sin fuente disponible — ningún lector coincidió con el CAID en absoluto
• sid no encontrado — el ID del servicio no está en la lista de canales de ningún lector
• sin lector coincidente — el CAID existe pero el filtro de proveedor/grupo bloqueó el lector

"No se puede decodificar" implica específicamente que la tubería ECM avanzó más — se contactó a un lector — pero el paso final de decodificación falló. Esa es la distinción que importa.

La línea de registro y dónde aparece

Abre la interfaz web de NCam enhttp://your-box-ip:8888 (o lo que seahttpport que configuraste en[webif]) y ve a Live Log. Estás buscando líneas etiquetadasdvbapi y entradas que muestrenecm hash,sin cw, o el explícitono se puede decodificar cadena. La ruta del archivo de registro se establece en[global] dencam.conf — típicamentelogfile = /var/log/ncam.log o/tmp/ncam.log en sistemas embebidos.

Fallo de decodificación vs. sin solicitud de ECM vs. ECM rechazado

Aquí es donde la mayoría de la solución de problemas falla. "Sin solicitud de ECM" significa que la capa dvbapi nunca pidió un CW — eso es unpmt_mode o problema de socket. "ECM rechazado" significa que el servidor respondió con un error. "No se puede decodificar" significa que un CW llegó pero no funcionó. Estos tres resultados necesitan soluciones completamente diferentes, y se ven superficialmente similares en el registro si no estás leyendo con atención.

Cómo NCam difiere de la nomenclatura dvbapi de OSCam

Casi nada, honestamente. Elncam.dvbapi archivo utiliza la misma sintaxis P:/I:/D: queoscam.dvbapi. Algunas compilaciones colocan configuraciones en/usr/keys/ en lugar de/etc/tuxbox/config/ — verifica tu imagen específica. El puerto webif por defecto es 8888 en la mayoría de las compilaciones de NCam frente al 8888 de OSCam también, así que no hay cambio allí.

Lee los registros antes de cambiar algo

En serio. Cada cambio de configuración que hagas a ciegas añade una nueva variable. Antes de tocar nada, obtén un rastro limpio de lo que NCam está haciendo realmente con un canal específico.

Habilita el registro completo (debug 255) de forma segura

Enncam.conf bajo[global], establecedebug = 255 temporalmente. Esto registra todo: análisis de PMT, selección de PID de ECM, coincidencia de lectores, temporización de CW y llamadas al descrambreador. En un Pi o STB débil, esto inundará el registro y puede ralentizar las cosas lo suficiente como para causar CW tardíos — lo que crea un síntoma que se parece al problema que intentas diagnosticar. Captura 60 segundos de registro para un canal, luego establecedebug = 0 de nuevo. No lo dejes funcionando.

También puedes alternar la verbosidad por lector en el webif sin editar el archivo, lo que es más limpio durante la depuración en vivo.

Rastreando el ciclo de vida del ECM: solicitud, encontrado, cw, decodificar

Un rastro de decodificación exitoso se ve así en orden: dvbapi analiza el PMT y encuentra PID(s) de ECM, NCam selecciona un PID y envía una solicitud de ECM a un lector coincidente, el lector devuelve un CW, NCam entrega el CW al descrambreador, el descrambreador lo aplica y el flujo se descifra. "No se puede decodificar" se rompe en ese último paso — ya sea que el CW nunca llegó, llegó demasiado tarde o llegó incorrecto.

Busca la línea que muestra el tiempo ECM en milisegundos. Algo comotiempo ecm: 340ms está bien. 1800ms en un canal con un período de cifrado de 1.8 segundos significa que el CW está llegando justo al borde y puede estar siendo descartado.

Detectar desajustes de CAID/proveedor/SID en el rastro

Con el depurador 255 activo, verás el par CAID:provid completo que NCam está usando para hacer coincidir un lector. Si tu lector tienecaid = 0500 pero el ECM del canal está etiquetado con el proveedor032830 y losservicios oident de tu lector no incluyen ese proveedor, NCam coincide en CAID pero el lector rechaza el ECM específico. El registro mostrará que el lector intentó pero no devolvió nada válido.

Corrige el enlace dvbapi y el mapeo de PID

Esta es la causa más común de que se necesite una solución de ncam no puede decodificar en una configuración que anteriormente funcionaba: algo en el enlace dvbapi está mal, ya sea por una actualización de imagen, una re sintonización de canal o una configuración que nunca estuvo bien desde el principio.

Sintaxis de ncam.dvbapi: líneas P/I/D, CAID, provid, SID, PID ECM

Elncam.dvbapi archivo controla cómo NCam mapea canales a fuentes de ECM. Aquí hay un ejemplo concreto:

# Preferir proveedor 032830 en CAID 0500

La forma de cuatro camposP: CAID:provid:SID:ecmpid es lo que usas cuando la detección automática elige el PID ECM incorrecto. Esto importa más de lo que la mayoría de las guías reconocen: un canal con múltiples PIDs ECM bajo el mismo CAID hará que NCam adivine, y a menudo adivina mal después de un nuevo escaneo de canal.

boxtype / modo dvbapi (au, pmt_mode, listen_socket)

Enncam.conf, el[dvbapi] bloque necesita coincidir con tu hardware e imagen. Una configuración típica de enigma2 se ve así:

[dvbapi]

Modopmt_mode incorrecto es un asesino silencioso: NCam nunca recibe el PMT, nunca solicita un ECM, y el registro simplemente muestra que no sucede nada para ese canal. La caja parece congelarse sin ningún error. Diferentes imágenes de enigma2 (OpenATV, OpenPLi, OpenViX, E2iPlayer) se comportan de manera diferente aquí.

Forzar el PID ECM correcto cuando la detección automática elige el incorrecto

Esto afecta a las personas más a menudo cuando un canal lleva tanto un ECM primario como un de respaldo, o cuando el audio FTA y encriptado comparten el mismo flujo de transporte. La capa dvbapi de NCam analiza el PMT y ve múltiples PIDs ECM. Con el depurador 255, verás todos ellos listados. El registro muestra algo como:

dvbapi: encontrado 2 ECMpids para SID 0x1234: 0x0640 (CAID 0500) 0x0641 (CAID 0500)

NCam elige el primero. Si solo el segundo es válido para el proveedor de tu lector, recibirás un CW de vuelta pero no se desencriptará. Fíjalo explícitamente con una línea P: de cuatro campos como se muestra arriba. Después de que un canal cambie sus parámetros de transmisión, las líneas de pin antiguas en ncam.dvbapi pueden apuntar a PIDs ECM que ya no existen: el canal silenciosamente no recibe ECM y vuelves a la pantalla negra.

Permisos y la ruta del dispositivo /tmp/camd.socket / dvbapi

En STBs basados en Linux, NCam necesita permiso para escribir en/tmp/camd.socket y leer desde/dev/dvb/adapter0/ca0 (y nodos demux). Si NCam se ejecuta como un usuario no root, verifica que el usuario esté en elgrupo de video y que la ruta del socket sea escribible. Un fallo de permisos aquí hace que NCam no se vincule silenciosamente: obtienes el mismo síntoma de pantalla negra que un desajuste de pmt_mode, pero el registro mostrará un error de vinculación de socket si estás mirando en depuración 255.

Cuando la tarjeta/compartición es el problema, no NCam

Una vez que hayas confirmado que el dvbapi está funcionando y se está solicitando y respondiendo un ECM, pero el canal aún no se decodifica, el problema se ha trasladado aguas arriba. Esta es la segunda mitad de cualquier investigación adecuada sobre la incapacidad de ncam para decodificar.

ECM respondido pero CW inválido: clave incorrecta, AES/CWPK o nivel

Algunos sistemas — variantes de Nagra, ciertas implementaciones de Conax — superponen una clave adicional sobre el CW. El lector devuelve lo que parece ser un CW válido, NCam lo aplica y el descrambler produce basura. Esto es un desajuste de AES o CWPK. La compartición tiene el CAID y proveedor correctos pero una variante de clave diferente a la que requiere tu contenido. Verás que el ECM se completa con éxito en el registro, pero el flujo no se descifra. Solución: verifica la variante exacta de CAID que utiliza tu canal (0500 y 0503 son diferentes) y confirma que la compartición cubre explícitamente esa variante.

El nivel faltante es el otro caso: la tarjeta o cuenta tiene CAID 0500 pero no el paquete de suscripción específico que desbloquea este canal. El ECM es respondido (la tarjeta lo procesa) pero devuelve un CW nulo o inválido. Algunos lectores registran esto explícitamente comocw no encontrado .

BISS, Tunneling (CW constante) y casos especiales de Powervu

Los canales cifrados con BISS y los canales de CW constante (tunneling) no utilizan ECMs en absoluto. Si intentas descifrar un canal BISS a través de la ruta normal de ECM, obtendrás un "no se puede decodificar" perpetuo porque no hay ECM para responder. Las claves BISS van enncam.keys oSoftCam.Key dependiendo de tu imagen, utilizando el formato estándar para el SID. PowerVU es similar: necesita un manejo específico y el archivo de clave correcto, no un lector de compartición de tarjetas.

Si tu canal es BISS y lo estás depurando como un fallo de ECM, estás depurando completamente la cosa equivocada.

Latencia, tiempo de espera de ecm y fallos de decodificación 'cw demasiado tarde'

En[global] dencam.conf,ctimeout = 1500 establece los milisegundos máximos que NCam espera por un CW. Si la compartición tarda 1600 ms en responder, el CW llega después de ctimeout y se descarta. El registro muestracw demasiado tarde o similar. El canal permanece negro aunque la clave era técnicamente correcta.

Sintonización: puedes aumentarctimeout a 2500 ms como prueba, pero la solución real es una compartición más rápida o menos saltos. En lectores CCC,cccmaxhops controla cuántos nodos de re-compartición atraviesa el ECM: cada salto añade latencia. Configúralo en 1 o 2 si puedes.ccckeepalive = 1 previene la latencia de renegociación de conexión en servidores capaces de keepalive.

Coincidencia de lectores: localcards, lector ccc/cccam, grupo/servicios

Losservicios de NCam ygrupo filtros enncam.server yncam.user puede bloquear silenciosamente un SID de un lector. Si configuras una lista blanca de servicios o una tabla de SID enncam.services (sidtab) y el canal actual no está en ella, NCam no enviará el ECM a ese lector. El lector aparece como en línea. El CAID coincide. Pero el SID se filtra antes de que el ECM sea enviado. Verificaservicios = ygrupo = líneas en la configuración de tu lector y verifica que el SID del canal esté permitido.

Lista de verificación de diagnóstico paso a paso

Ejecuta estos pasos en orden. Cada paso te dice exactamente qué capa está rota. Este es el proceso sistemático de solución de problemas de que ncam no puede decodificar — no saltes pasos incluso si crees que conoces la respuesta.

Confirma que el lector está en línea y tiene el CAID correcto

1. Abre webif → Lectores. Confirma que el estado es verde/conectado, no rojo.
2. Verifica que la lista de CAID del lector incluya el CAID exacto de tu canal. 0500 ≠ 0503 ≠ 0504.
3. Si usas un lector CCC/CCcam enncam.server, verificaprotocolo = cccam, host/puerto correctos, y queusuario/contraseña coincidan exactamente con el lado del servidor — incluyendo mayúsculas.
4. Verificagrupo = en el lector ygrupo = en la cuenta de usuario. Deben compartir al menos un número de grupo.

Confirma que dvbapi solicita el ECM (no silencioso)

1. Establecedebug = 255, sintoniza el canal que falla, verifica el registro en vivo dentro de 10 segundos.
2. Buscadvbapi: got PMT o equivalente. Si está ausente, NCam no está recibiendo el PMT — modopmt_mode o ruta de socket incorrecta.
3. Busca la línea PID ECM que muestra el CAID y el PID seleccionados por NCam. Si está ausente después de ver el PMT, verifica las líneas I: enncam.dvbapi que bloquean ese CAID.
4. Confirma que el socket/tmp/camd.socket existe y es escribible por el proceso de NCam.

Confirma que un CW regresa y su temporización

1. En el registro, encuentra la línea de solicitud ECM, luego busca la línea de respuesta CW que muestra la temporización (por ejemplo,tiempo ecm: 342ms).
2. Si no hay respuesta CW: el lector recibió el ECM pero no pudo responder. Verifica el nivel/suscripción en la tarjeta, o la discrepancia CAID:provid en un compartido.
3. Si existe respuesta CW pero la temporización es >1500ms: estás alcanzandoctimeout.Prueba conctimeout = 3000 en[global] temporalmente.
4. Si la respuesta CW es rápida y limpia pero el canal aún no se decodifica: discrepancia AES/CWPK, PID ECM incorrecto, o canal BISS/CW constante siendo mal manejado.

Aísla un canal/CAID a la vez

1. Prueba con un canal conocido en el mismo CAID que debería funcionar. Si eso también falla, el problema es el lector/compartido, no el canal específico.
2. Si solo un canal falla: verifica si hay una situación única de PID ECM o un SID que está en un nivel de suscripción diferente.
3. Si todos los canales en un CAID fallan: el lector está conectado pero no autorizado para ese CAID.
4. Si todos los canales en todos los CAIDs fallan: la vinculación dvbapi está rota a nivel de socket/pmt_mode.

Si cada paso anterior está correcto — lector en línea, CAID correcto, ECM solicitado, CW rápido devuelto — pero la decodificación aún falla, estás enfrentando un problema de clave/nivel/transmisión, no un problema de configuración de NCam. La solución está del lado de la fuente, no en tus archivos de configuración.