Historial de versiones

versión 2.0.2.423

26.10.2026

• Versión de demostración — edición gratuita para la evaluación técnica, paquete pstreamer-demo: sin clave de protección ni activación, sin límite de tiempo, solo con fines de prueba (el uso comercial está prohibido). Funciones y limitaciones: Versión de demostración.

• Versión de demostración: el campo DVR sin error — en la pestaña «OTT» del editor del flujo, tras elegir el modo «OTT / HLS», ya no aparece bajo el campo «Almacenamiento DVR» el error «No se pudieron cargar los almacenamientos DVR»: el campo solo muestra «No disponible en la demo» (Comparación de ediciones).

• Actualice los transcodificadores junto con el streamer — se necesitan pstreamer-tcnv 1.2.0.128, pstreamer-tcsw 1.2.0.127 y pstreamer-tcivpl 1.1.0.56 o posteriores: un transcodificador de una versión anterior puede terminar de forma anómala al detenerse el servicio, y el logotipo en el transcodificador por software requiere la nueva versión de tcsw. Tras actualizar los transcodificadores, reinicie el servicio (Archivos y verificación de la instalación).

• Inicio automático del servicio al actualizar el paquete — actualizar el paquete rpm ya no desactiva el inicio automático del servicio pss ni lo detiene: antes, tras una actualización así y un reinicio del servidor, el streamer no arrancaba por sí solo. Ahora, también al actualizar desde 2.0.2.408, el inicio automático sigue activado y un servicio en marcha se reinicia con la nueva versión; un servicio que el administrador detuvo o desactivó queda así. Actualizar el paquete deb ya no activa un inicio automático que el administrador desactivó. El usuario del sistema pss ya no se elimina y se vuelve a crear al actualizar. Si una instalación rpm se actualizó antes, compruebe el inicio automático con systemctl is-enabled pss y, si la respuesta es disabled, actívelo: sudo systemctl enable pss (Instalación en sistemas de la familia RHEL).

• Ajustes de OTT, DVR y DRM sin interrumpir la emisión — guardar los ajustes de OTT, DVR y DRM de un flujo en marcha reinicia solo la difusión OTT y la grabación del archivo: las entradas y las salidas (UDP, SRT y otras) siguen funcionando sin interrupción, y el uptime del flujo no se reinicia. Antes, cualquier cambio de este tipo reiniciaba todas las entradas y salidas del flujo, y las salidas tenían una breve interrupción. La profundidad del archivo y la duración objetivo de parte LL se aplican en caliente, sin reinicio. Los ajustes que cambian el propio flujo de transporte (nombre del servicio, programa, filtros PID, correcciones PAT/PMT/PCR, fuente EPG) reinician las entradas y salidas, como antes (OTT y DVR).

• Clonación de flujos — en la interfaz web, un flujo o varios flujos seleccionados se copian junto con sus entradas y salidas: la copia se crea en pausa, con el sufijo -copy en el nombre, y el resumen enumera los puertos y direcciones que coinciden con el flujo de origen (Clonación de flujos).

• Inicio de sesión en la interfaz web sin la ventana del navegador — al abrir la interfaz web desde otro ordenador, el navegador ya no muestra su propia ventana de inicio de sesión antes del formulario de la interfaz web. Una solicitud de la API a una ruta /data/… con la cabecera X-Requested-With: XMLHttpRequest recibe, si se rechaza, 401 sin desafío Digest; los scripts que inician sesión por Digest no deben enviar esta cabecera (Iniciar sesión, Acceso).

• Asistente de reclamaciones en la interfaz web — mientras un flujo SPTS tiene una infracción activa de TR 101 290 o deriva de PCR, en la fila del flujo y en la ventana de estadísticas se muestra el icono «Carta IA»: abre una solicitud lista para un chat de IA, que redactará una carta de reclamación al proveedor. La solicitud solo está disponible para el rol Admin, la carta siempre está en inglés (se ha eliminado la elección de idioma) y, de la fuente, la solicitud solo recoge la dirección de la entrada, sin usuarios, contraseñas ni claves. Sin una infracción activa, el nodo no genera la solicitud (Asistente de reclamaciones).

• Desplazamiento del fotograma ampliado del mosaico — en la ventana del fotograma original la imagen ampliada se puede desplazar con el ratón manteniendo pulsado el botón derecho y, en el teléfono y la tableta, ampliar pellizcando y desplazar con el dedo (Fotograma original).

• Nombre OTT del conjunto adaptativo sin espacios — el campo «Nombre OTT» de un conjunto adaptativo ya no admite espacios: rompían la reproducción y la exportación de la lista de reproducción. El streamer también los elimina, al añadir y modificar un conjunto mediante la API y al cargar la configuración (con una entrada en el registro); el nombre limpio se escribe en el siguiente guardado. Si tras eliminar los espacios coinciden los nombres de dos conjuntos, la configuración se carga igualmente: el segundo nombre no se distribuye y se escribe una advertencia en el registro (antes esa configuración no se cargaba) (Conjunto adaptativo).

• Exportación a M3U: conjuntos adaptativos y DASH — a la lista de reproducción se exportan ahora también los conjuntos adaptativos: la lista maestra HLS y el manifiesto DASH del conjunto, cada uno mientras al menos un flujo del conjunto lo sirva. La opción «Todos los activos» añade después de los flujos todos los conjuntos en funcionamiento, y el nuevo protocolo DASH incluye los manifiestos de los conjuntos y los flujos en modo DASH. Antes no se podían exportar los conjuntos seleccionados (Exportación e importación M3U).

• Logotipo en la imagen del transcodificador — en las salidas del transcodificador NVIDIA y del transcodificador por software (CPU) se puede superponer un logotipo desde un archivo PNG: cada salida tiene su propio archivo, posición, opacidad y desenfoque del fondo bajo el logotipo. El logotipo no se escala; la interfaz web comprueba de inmediato si cabe en el fotograma de salida y muestra una vista previa a escala. Los archivos de logotipo se cargan en la interfaz web y se guardan en el nodo. El backend de un decodificador con logotipo se puede cambiar entre NVIDIA y por software; con los mismos ajustes de tamaño, su fotograma puede diferir en unos pocos píxeles, y el logotipo debe caber en el fotograma del backend seleccionado. Intel no tiene logotipo (Logotipo en la imagen).

• Parada y reinicio rápidos — los transcodificadores, los comandos externos de las entradas y salidas std y el comando de alertas terminan junto con el servicio, y durante la parada el nodo ya no reinicia los transcodificadores. Antes no reaccionaban a la señal de parada, y la parada o el reinicio del servicio esperaba a que el sistema los terminara a la fuerza, normalmente unos 15 segundos.

• Estadísticas del transcodificador — la cola del decodificador y la latencia ya no se congelan después de que el nodo haya reiniciado el transcodificador.

• Alertas por grupos — la pantalla «Alertas» agrupa de forma predeterminada las alertas vigentes por nodo y por código, con el número de filas y la severidad más alta en el encabezado del grupo; los grupos grandes se abren contraídos. Las etiquetas «resync persistente» y «entrada de respaldo» distinguen las recomendaciones de resincronización y los errores de las entradas de respaldo de las averías en curso. La lista anterior sigue disponible con el selector «Lista» (Alertas).

• Alertas sin parpadeo — una alerta sobre los recursos del nodo (CPU, memoria, red, GPU, memoria de vídeo de la GPU, almacenamiento DVR, hilos de trabajo de los adaptadores DVB) se genera solo cuando el valor se mantiene más allá del umbral durante 30 segundos, y se retira tras 60 segundos por debajo del umbral. La alerta de errores del contador de continuidad de un flujo (código 15) se genera solo cuando las pérdidas continúan durante 30 segundos y se retira tras 60 segundos sin pérdidas; el nivel de error se mantiene hasta que el número de errores baja de la mitad del umbral. Antes, una carga que saltaba por encima y por debajo del umbral y los paquetes perdidos aislados producían alertas que aparecían y desaparecían en segundos. Los tiempos se definen en la pantalla «Alertador» (parámetros system-alert-raise-sec, system-alert-clear-sec, stream-cc-raise-sec y stream-cc-clear-sec de la sección alerter); 0 restablece el comportamiento anterior (Ajustes del alerter).

• Alerta de llenado de la memoria de vídeo de la GPU — una nueva alerta de código 64 para cada tarjeta NVIDIA: advertencia cuando la memoria de vídeo está llena al 85 %, error al 95 % (fila «Memoria de vídeo de la GPU» de la pantalla «Alertador», parámetros gpu-mem-warning-pct y gpu-mem-error-pct; 0 desactiva el nivel). Una tarjeta con la memoria de vídeo llena no inicia un nuevo canal de transcodificador, aunque su carga pueda parecer normal. Para las GPU Intel no existe esta alerta. Los datos del monitor del sistema (/data/sysmon) muestran para cada tarjeta NVIDIA la memoria de vídeo ocupada y total y el porcentaje de llenado, y el monitor del sistema de la interfaz web, una barra «Memoria de vídeo»; la antigua barra «Memoria» de una tarjeta NVIDIA se llama ahora «Ancho de banda de memoria». Con la replicación de alertas del sistema activada, los nodos de versiones anteriores del mismo dominio muestran esta alerta sin nombre hasta que se actualizan (Catálogo de códigos de alerta).

• Reserva averiada en una sola alerta — la nueva alerta de código 65 (nivel «advertencia», una por flujo) enumera las entradas que están en error mientras el flujo pasa por otra entrada. Esas entradas ya no mantienen sus propias filas de código 1, y el código 1 es ahora siempre crítico: el flujo ha perdido su fuente. Un destino externo recibe la retirada de las filas de código 1 y la generación del código 65 en lugar de la antigua actualización «crítico» → «error». Se configura en el bloque «Entradas de respaldo (código 65)» de la pantalla «Alertador» (Catálogo de códigos de alerta).

• Alertas de resincronización más discretas — la alerta de código 61 (ruptura de PCR sin pérdidas) es ahora informativa y está desactivada por defecto; su umbral es una clave propia stream-sync-absorbed-count. Los códigos 58, 59 y 61 se retiran tras dos horas por debajo del umbral en lugar de seis horas sin un solo evento, y la fila de la entrada desde la que el flujo conmutó se retira de inmediato. Los umbrales y el número de horas tranquilas se fijan en el nuevo bloque «Resincronización de entrada (códigos 58, 59, 61)» de la pantalla «Alertador» (Catálogo de códigos de alerta).

• La alerta ACME se resuelve sola — la alerta de error de emisión del certificado por un problema en el nodo (no hay servidor HTTPS con el nombre del host, el puerto de validación HTTP-01 está ocupado, la clave de la cuenta) se resuelve tras el primer intento que supera ese paso; antes se mantenía hasta desactivar la emisión automática (Catálogo de códigos de alerta).

• Alertas externas: generación y resolución en pareja — el umbral de severidad mínima de los canales «Proceso», Telegram y e-mail se aplica al incidente, no a cada mensaje. Un incidente cuya gravedad subió hasta el umbral se notifica en el momento de la subida, y la resolución llega siempre que se notificó la generación. Antes, al cambiar la gravedad respecto al umbral, llegaba una resolución sin generación o una generación sin resolución (Cuándo se ejecuta el script).

• Scripts de alerta y stderr — la salida de errores del script se lee mientras el script se ejecuta: una salida abundante a stderr ya no provoca un tiempo de espera agotado, y un proceso dejado en segundo plano no retrasa las alertas siguientes. Solo un código de salida distinto de cero se considera un error de entrega; al registro van los últimos 4 KB de stderr (Resultado, tiempo de espera y registro).

• Meshwork: protección del intercambio entre nodos — un nodo comprueba que la respuesta de un vecino está firmada con el mismo secreto o con la clave del dominio, es decir, que procede de un participante auténtico de la red, y rechaza un mensaje de un vecino grabado antes y enviado de nuevo, así como un mensaje dirigido a otro nodo. La clave del dominio se transmite cifrada: un intercambio grabado y repetido más tarde no la obtiene. Antes, quien respondía a la conexión (un enlace interceptado por HTTP o TLS sin verificación del certificado) podía suplantar los datos de los nodos, las sesiones de inicio de sesión y la clave del dominio. No hace falta configurar nada (Vecinos y secretos).

• Meshwork: los relojes de los nodos deben estar sincronizados — a un nodo cuyo reloj difiere del de un vecino en más de 5 minutos lo rechaza ese vecino, y el enlace se muestra como no disponible. Ambos nodos escriben en el registro una advertencia con el nombre del vecino y el tamaño de la diferencia; la primera advertencia aparece ya a la mitad de la tolerancia. La tolerancia la define un nuevo parámetro opcional, cluster-hello-window-sec (300 segundos por defecto, 0–86400); 0 desactiva la comprobación de los relojes para los nodos cuyos relojes no se pueden sincronizar, y los mensajes repetidos se rechazan incluso entonces. Antes de actualizar, compruebe que NTP funciona en todos los nodos (Requisitos y accesibilidad).

• Actualización y reversión de Meshwork — si es posible, actualice todos los nodos del dominio a la vez. Si no es posible, actualice primero los nodos a los que se conectan los demás (nodos centrales y nodos con direcciones públicas) y después los nodos detrás de NAT. Mientras en el dominio funcionan nodos de versiones distintas, el intercambio de datos tiene limitaciones, y los mensajes de los nodos de versiones anteriores todavía se pueden repetir. A un nodo devuelto a una versión anterior lo rechazan sus vecinos con la nueva versión hasta que se reinician: revierta el dominio completo o reinicie los nodos de la nueva versión después de revertir (Actualización de los nodos del dominio).

• Más silencio en los reinicios planificados de nodos Meshwork — la alerta de nodo inaccesible (código 26) se genera tras un minuto de silencio y no a los 15 segundos, por lo que un reinicio rápido de un vecino no despierta a todo el dominio. Un nodo que se detiene o se reinicia intencionadamente avisa primero a sus vecinos (los nodos de versiones anteriores no reciben el aviso), y estos no generan la alerta para él durante 5 minutos, mientras en la tabla de nodos figura como «Reiniciando (N s)». Los tiempos se definen con los campos del bloque «Contacto de Meshwork (avanzado)» de la configuración del servidor (parámetros cluster-node-down-sec y cluster-leave-grace-sec de la sección cluster, Catálogo de códigos de alerta). Corregido: un nodo podía mostrarse dos veces en la red y repetir sus propias alertas como si vinieran de un vecino.

• Cambio de los ajustes de Meshwork — guardar los ajustes ya no quita los nodos descubiertos automáticamente del mapa de red ni cancela por error sus alertas «un nodo de la red se quedó en silencio» (Catálogo de códigos de alerta).

• Inicio de sesión automático desde otro nodo del dominio — una sesión de inicio de sesión automático que llega desde otro nodo del dominio recibe el rol Viewer en un nodo donde no existe esa cuenta. Si la cuenta existe en el nodo, se aplica su rol, como antes (Servidor web y cuentas).

• Facturación externa y nodos vecinos — los servidores de facturación ya no reciben la solicitud de inicio de sesión de un nodo Meshwork vecino que el propio nodo ya ha rechazado.

• Secretos en las respuestas de la API y su reescritura — la respuesta al añadir o modificar un registro mediante la API (POST a /config/…) ya no repite las contraseñas ni otros secretos, tampoco para el rol Admin: llegan como ********; la lectura de la configuración (GET) no ha cambiado. Un secreto o una línea de comandos enviados en una escritura como ******** conservan el valor guardado, igual que una dirección oculta con el rastro <hidden>: la respuesta recibida se puede devolver sin perder contraseñas. ******** en sí ya no se puede establecer como contraseña (Gestión mediante la API HTTP).

• Direcciones en las respuestas para los roles Viewer y Restricted admin — en el flujo de eventos /data/events (la dirección de la entrada activa del flujo y los textos de error), en los textos de eventos de /data/dbstat y en el motivo reason de /data/cert/acme/status, los usuarios, contraseñas y parámetros secretos de las direcciones están ocultos, como en el XML de /data. Para el rol Admin no cambia nada.

• Un cambio de configuración rechazado no modifica nada — si el nodo rechaza un cambio de un flujo, una entrada, una salida o de la configuración del servidor (por ejemplo, un nombre de nodo no válido), el objeto queda como estaba. Antes, las claves ya aplicadas en el momento del rechazo seguían vigentes hasta el reinicio (Cómo llegan los errores).

• Estadísticas de la base sin las tablas que faltan — la solicitud /data/dbstat con el parámetro missing=skip omite las tablas que no existen, en lugar de rechazar toda la solicitud.

• Archivos de configuración cerrados a la lectura — pss.json y sus copias de seguridad solo los puede leer el usuario del servicio. El exportador de métricas pss-metrics, ejecutado con otro usuario, se conecta al puerto 43971; si el servidor web usa otro puerto, defina PSS_URL, también en el archivo /etc/pss-metrics.conf. Corregido: el exportador se conectaba al puerto 8808 si en pss.json no había puerto del servidor web, y no tenía en cuenta PSS_URL de ese archivo (Archivos y servicios, Configuración).

• Cuentas de dirección IP y clientes IPv6 — la conexión de un cliente por IPv6 ya no provoca un error al comprobar las cuentas de dirección IP: ese cliente simplemente no coincide con las direcciones IPv4 (Usuarios / Inicios de sesión).

• Flujos permitidos de un login local — un login local al que, al iniciarse el nodo, no le queda ninguno de los flujos de la lista «Flujos permitidos» no recibe ningún flujo. Antes, ese login podía ver todos los flujos (Usuarios / Inicios de sesión).

• Habilitación y deshabilitación del servidor EPG — «Habilitar el servidor EPG» ahora controla los dos puertos, HTTP y HTTPS, y actúa de inmediato, sin reinicio: un servidor deshabilitado no abre ningún puerto. Antes, un servidor deshabilitado ocupaba igualmente sus puertos al iniciarse el servicio (las conexiones se quedaban colgadas), deshabilitarlo en marcha reiniciaba el puerto HTTP y el puerto HTTPS no tenía en cuenta el indicador (Entrega de XMLTV).

• Exportación EPG completa con datos de vinculación — la nueva ruta /xmltv-src del servidor EPG (y /xmltv-src.gz) devuelve los canales de todas las fuentes o de las seleccionadas con los datos para vincular los canales emitidos: el número y el nombre de la fuente y el identificador del canal en el archivo XMLTV; se puede exportar solo el catálogo de canales o añadir días pasados. Acceso: para una cuenta del servidor EPG con el indicador «Todos los canales en /xmltv-src» (all-channels) o desde el propio nodo (Exportación completa con datos de vinculación, Ajustes de EPG).

• Clasificación por edad en la guía de programación — la programación diaria del canal en JSON para middleware OTT devuelve la clasificación por edad del programa (la edad y el sistema de clasificación, por ejemplo 16+), tomada del archivo XMLTV o de la clasificación parental de DVB EIT; en la programación del canal en la interfaz web se muestra con una insignia (Programación diaria en JSON, Base de datos EPG).

• Subtítulo del programa en un campo aparte — el subtítulo del archivo XMLTV (<sub-title>, por ejemplo el título del episodio) en el idioma del título o sin idioma indicado se devuelve en la programación diaria del canal en JSON como campo sub independiente, y en la exportación completa /xmltv-src como elemento <sub-title>; allí el título del programa va sin subtítulo. La entrega habitual /xmltv no ha cambiado. Los subtítulos aparecen tras la siguiente actualización de cada fuente (Programación diaria en JSON).

• Descarga de EPG por turnos — los archivos XMLTV grandes se descargan y procesan de uno en uno mientras los demás esperan en la cola, y al iniciarse el servicio las descargas se escalonan en el tiempo: el pico de memoria al reiniciar con varios archivos grandes es el de uno solo. Una descarga fallida se reintenta a los 2, 5 y 15 minutos y después cada 30 minutos, en lugar de tras el intervalo de actualización completo. En la interfaz web, una fuente en cola está marcada, y la pestaña «Estado de las fuentes» muestra los campos «Próximo intento» y «Descargas fallidas seguidas» (Cola de descargas y reintentos, Base de datos EPG).

• Tiempo de espera de descarga de una fuente EPG — el nuevo parámetro de la fuente «Tiempo de espera de descarga, s» (fetch-timeout) para las fuentes lentas que generan el archivo bajo petición; por defecto, como antes, 30 segundos (Configuración de las fuentes).

• Fuentes EPG — al modificarla, «URL / ruta de la fuente» debe ser una dirección http o https o una ruta absoluta a un archivo; de lo contrario, el cambio se rechaza. Las Cookies de la fuente ahora sí se envían — en la cabecera estándar Cookie y solo al host configurado; antes la cabecera se llamaba Cookies y los servidores no la tenían en cuenta. Tras modificar una fuente activada (por ejemplo, su dirección), los datos se cargan de inmediato y no al vencer el intervalo de actualización (Configuración de las fuentes).

• Eliminación de un conjunto de canales EPG — el contenido de un conjunto se elimina junto con el conjunto y solo si la eliminación se ha completado. Antes, el contenido de un conjunto sin cuentas quedaba en la base de datos, y una eliminación rechazada de un conjunto asignado a una cuenta podía borrar su contenido.

• EPG: programas que cruzan la medianoche — un programa que transcurre a través de la medianoche (UTC) se muestra en ambos días de la programación, y su marca en la lista de reproducción OTT se encuentra también después de la medianoche. Antes, ese programa desaparecía de ambos días.

• Corregido: en la exportación /xmltv un programa podía repetirse si dos fuentes entregan un canal con el mismo identificador; la guía de programación procedente del EIT de los flujos muestra de inmediato un programa modificado, y no su texto o clasificación anteriores.

• Corregido: «Limpiar automáticamente canales huérfanos» podía eliminar los canales de una fuente EPG cuyo archivo XMLTV no había cambiado; los cambios de la programación en las fuentes externas ahora se reconocen de forma más fiable, y las ediciones de nombres de canales hechas en la interfaz web se conservan (Base de datos EPG).

• EIT — el servicio ya no se cierra de forma inesperada al generar la EIT desde XMLTV si un evento tiene dos o más clasificaciones por edad o una descripción larga en polaco, checo, húngaro, croata o bosnio: un texto demasiado largo se divide en varios descriptores. Una descripción larga en cirílico y otros alfabetos no latinos ya no se divide en fragmentos de un byte, la numeración de los descriptores es correcta y un evento con descripción larga conserva su clasificación por edades (Generador EIT).

• NIT — el nodo sigue la versión de la NIT también después de un reinicio (antes, la lista de números lógicos de canal podía quedar vacía) y aplica solo la NIT de su propia red (actual).

• Tipo de servicio automático — con Service type 0, un programa H.264 se considera HD (tipo 0x19) a partir del nivel 3.1. Antes, el umbral era el nivel 3.0, y el SD 576i/480i de ese nivel se marcaba como HD; ahora, como SD (0x16) (Parámetros de los programas).

• Recepción multicast en la interfaz de bucle — una entrada UDP o RTP con la interfaz lo o 127.0.0.1 se une al grupo multicast solo en la interfaz de bucle y recibe el grupo que se envía en este mismo nodo. Antes, la entrada se unía al grupo en la interfaz externa y no recibía nada. Para recibir un grupo desde la red, indique una interfaz de red o deje el campo vacío (Entrada).

• Reincorporación al grupo multicast — en las entradas UDP, RTP y Pro-MPEG el período de repetición está limitado a 3600 segundos: el nodo no acepta un valor mayor y al arrancar lo reduce a 3600. Antes, un valor superior a 4294 segundos hacía que la entrada repitiera la reincorporación continuamente. Ahora un intento fallido se repite tras el período, en lugar de detener las repeticiones hasta que la entrada se reconecte; una entrada Pro-MPEG también vuelve a suscribirse a los flujos FEC (Entrada).

• Comprobación de la dirección de las entradas UDP y RTP — al modificarla, una dirección que no es una dirección IPv4 (por ejemplo, 999.999.1.1) se rechaza con el mensaje Incorrect IPv4 address. Los ajustes guardados anteriormente no se vuelven a comprobar al iniciar (Entrada).

• Entrada RIST multicast — se une al grupo en la interfaz de la columna Interface; antes siempre se usaba la ruta por defecto. En la salida RIST multicast la interfaz sigue sin actuar: el tráfico sale por la ruta del sistema hacia el grupo (La lista de peers).

• RIST sin caídas — un emisor RIST cuyo tamaño de bloque de datos no es múltiplo de 188 bytes ya no detiene el servicio: esos bloques se descartan, y el registro lo anota como máximo una vez por minuto. Sustituir todas las entradas o salidas de un flujo con un solo cambio mientras funciona una entrada o salida RIST tampoco provoca ya la caída del servicio.

• Entrada RTSP — al cambiar la dirección, al pausar, al pasar a una entrada de reserva o al reconectarse, la entrada cierra de verdad la sesión anterior. Antes podía seguir recibiendo el flujo de la fuente antigua.

• DVB: sin cortes periódicos del flujo — una lectura incompleta de datos del dispositivo DVB ya no provoca el reinicio de la entrada ni la reconfiguración del sintonizador, que hacían que el flujo DVB-T/S se interrumpiera periódicamente (Receptor DVB).

• Receptor lento de las salidas file, pipe y std — si el receptor se queda atrás respecto al flujo durante mucho tiempo, la salida pasa al error Output queue full y se reinicia, igual que las salidas de otros tipos; los datos transmitidos llegan en orden. Antes, en esta situación, los paquetes TS se perdían y se desordenaban sin aviso (Aplicaciones externas (std)).

• Salida std con stderr abundante — una aplicación que escribe mucho en stderr ya no se detiene tras 64 KB de salida ni se reinicia en bucle. En caso de fallo, el final de su stderr se muestra en el texto del error (Aplicaciones externas (std)).

• Tablas dañadas en el flujo de entrada — el nodo descarta las secciones dañadas de PAT, PMT, CAT, NIT, EIT y TOT y los descriptores que contienen; ya no pueden provocar el cierre inesperado del servicio.

• Marca ESCR en PES — los flujos con la marca ESCR en las cabeceras PES se analizan correctamente; antes, su análisis se interrumpía con un error.

• Añadir un flujo con transcodificador — añadir un flujo cuya entrada transcoder está conectada a un decodificador que ya está en funcionamiento ya no provoca el cierre inesperado del servicio (Conexión).

• HTTP/3: respuestas en streaming sin daños — por HTTP/3, MPEG-TS over HTTP (/http/) y las partes de LL-DASH en directo se transmiten completos, igual que por HTTP/1.1. Antes, el cuerpo de una respuesta así llegaba dañado: no empezaba en un límite de paquete TS, los fragmentos se perdían o se repetían y los reproductores perdían la sincronización. El error no afectaba a los segmentos HLS y DASH ni a otros archivos (HTTP/3 (QUIC)).

• OTT — la entrega de DASH y LL-HLS se reanuda tras cambiar el PID de vídeo en el flujo (antes, solo tras reiniciar OTT); la distribución de MPEG-TS over HTTP ya no reinicia la entrada ante una ralentización breve del disco DVR.

• Eliminar una entrada o una salida no detiene la grabación DVR — tras eliminar una entrada o una salida de un flujo, el archivo DVR sigue grabándose. Antes, la grabación se detenía hasta el siguiente cambio de la configuración OTT del flujo.

• DVR: registro de índice dañado — si un único registro del índice del archivo está dañado (por ejemplo, tras un corte de alimentación), el nodo lo omite y carga el resto del archivo; solo se pierde ese fragmento. Antes, todo lo grabado después de él desaparecía del archivo en cada reinicio, y luego se borraban los ficheros (Almacenes DVR).

• DVR: limpieza de los archivos MP4 — al superarse el límite de uso del disco, también se eliminan los segmentos más antiguos de los archivos MP4 (DASH y LL-HLS). Antes solo se limpiaba el archivo TS, y un disco con solo archivos MP4 seguía desbordado.

• DVR: subtítulos — el archivo de subtítulos WebVTT se conserva al reiniciar; antes se perdía (Subtítulos WebVTT).

• DVR: espacio libre de emergencia — el campo «Espacio libre de emergencia, GiB» de los almacenes DVR nunca influyó ni influye en el funcionamiento: el valor se guarda, pero la grabación no se detiene por el espacio libre. Ahora el campo se describe como reservado; el disco lo mantiene dentro del límite la limpieza por espacio, que no toca el archivo más reciente que el mínimo protegido (Almacenes DVR).

• Otras mejoras y correcciones de errores.

versión 2.0.2.408

19.10.2026

• Un disco DVR averiado no detiene la difusión en directo: un disco DVR lleno, de solo lectura o con fallos ya no detiene la difusión en directo de un flujo por HLS y DASH. Antes, un error de escritura del archivo, sin entrada en el registro, detenía tanto la difusión en directo como el archivo hasta el reinicio, y borrar el archivo no servía de nada. Ahora el registro marca el inicio y el fin de un fallo de escritura, y una vez resuelta la avería el archivo vuelve a grabarse, también después de borrar el archivo del flujo (Estadísticas del flujo). Lo mismo se aplica al archivo de subtítulos.

• Cambiar los ajustes no bloquea la API: la edición de un flujo (un parámetro, una salida, la eliminación del flujo) ya no puede quedarse colgada con una entrada caída o inactiva, ni bajo carga. Antes, junto con ella dejaban de responder todas las solicitudes de configuración y la lista de flujos en la interfaz web.

• Guardado de los ajustes sin pérdidas: un cambio realizado justo antes de una parada normal o de un reinicio del servicio ya no se pierde; una escritura fallida del archivo de configuración se reintenta cada 10 segundos, y el registro indica la causa; un cambio realizado antes del reinicio automático tras una restauración desde una copia de seguridad ya no sobrescribe la configuración restaurada.

• Reconexión de entradas y salidas: tras un reintento de conexión, una entrada o salida ya no puede quedarse colgada en un intento de arranque sin haber abierto nada, hasta reiniciar el servicio o editar los ajustes. Ocurría con más frecuencia con una entrada SRT en modo listener; también afectaba a PS1, RTMP/RTMPS, RTSP, la entrada HLS, TCP y el transcodificador.

• SRT: una frase de contraseña incorrecta no bloquea la entrada: las partes que se conectan una y otra vez a un puerto SRT en modo listener con una frase de contraseña incorrecta, o sin ella, ya no ocupan todas las plazas de conexión: un emisor con la frase correcta se conecta de inmediato.

• Repositorio de paquetes por HTTPS y firmado: el repositorio funciona por HTTPS, y los paquetes y metadatos están firmados con la clave del repositorio. Los nuevos comandos para añadirlo están en Instalación en sistemas de la familia RHEL y Instalación en sistemas de la familia Debian; un repositorio añadido antes sigue funcionando.

• Creación de un flujo con un valor no válido: una solicitud para crear un flujo a través de la API HTTP con un valor de parámetro no válido se rechaza por completo, y el flujo no se crea. Antes el valor se descartaba y el flujo se creaba (Cómo llegan los errores).

• El orden de la clave ``mpts`` no importa: mpts se aplica antes que las demás claves de una entrada de flujo, esté donde esté. Los parámetros OTT y otros ajustes de un flujo de un solo programa transmitidos al crear un flujo a través de la API HTTP sin mpts, o escritos en el archivo de configuración por encima de ella, ya no se pierden (El orden de las claves dentro de un objeto importa).

• SIGHUP es una parada normal: la señal SIGHUP detiene el servicio igual que SIGTERM. Los flujos se detienen y el último cambio de ajustes se guarda. Antes el proceso terminaba de inmediato.

• Entrada Pro-MPEG en el catálogo de Meshwork: una entrada Pro-MPEG que recibe un grupo multicast se anuncia en el catálogo de recursos compartido del dominio igual que las entradas UDP y RTP (Catálogo común de recursos).

• Otras mejoras y correcciones de errores.

versión 2.0.2.399

01.10.2026

• Búfer T-STD: solo métrica: el modelo del búfer de vídeo daba falsos positivos en flujos sanos, por lo que su indicador se mantiene en las estadísticas para el diagnóstico, pero ya no genera una alarma (código 11) ni entra en el veredicto global de TR 101 290 (código 49) (Catálogo de códigos de alerta).

• OTT sin relleno CBR: los paquetes NULL con los que se completa la tasa de bits constante no se entregan a ningún cliente OTT, tampoco en la distribución por HTTP sin segmentador. La tasa de bits constante se mantiene solo en las salidas de transporte: UDP, SRT, PS1, RIST.

• Partes LL-HLS por fotogramas clave: cada IDR abre una nueva parte con el indicador INDEPENDENT, de modo que un reproductor que se conecta en el borde en directo encuentra un punto de entrada dentro de un solo GOP.

• Muchas entradas HLS en un nodo: las entradas HLS descargan los segmentos a través de un pool común; una entrada abierta ya no mantiene hilos de trabajo propios y, cuando el pool está ocupado, la descarga de un segmento se aplaza en lugar de reiniciar la entrada.

• Otras mejoras y correcciones de errores.

versión 2.0.2.362

06.09.2026

• Menú del módulo CI: se lee el menú propio del módulo: el estado de la tarjeta, las suscripciones, el número de serie, la introducción del PIN y los elementos de servicio están disponibles directamente desde la pantalla de hardware, lo mismo que el módulo mostraría en la pantalla del televisor. Allí mismo apareció el pasaporte del módulo —fabricante, código de producto y tipo de aplicación EN 50221— y el nodo decodifica su nombre, de modo que los nombres cirílicos ya no llegan distorsionados (Menú del módulo).

• Desencriptado por un módulo CI aparte: un módulo alojado en un lector de tarjetas independiente atiende cualquier entrada de un flujo, y no solo la recepción desde una tarjeta DVB; por él pasa todo el transporte de la entrada, mientras que la lista de programas solo indica cuáles desencriptar. La ranura se asigna en la propia entrada, y ahí mismo se ve qué entrada la ocupa (CI/CAM en la entrada de un flujo).

• Varias ranuras CI en una misma entrada: el multiplex se conduce sucesivamente a través de varios módulos, con su propio conjunto de programas para cada ranura. La frecuencia de reloj del bus CI se elige según el bitrate real de la entrada, y una ranura que haya quedado ocupada se libera bajo petición desde la pantalla de hardware.

• Tablas de servicio en el demultiplexado: las tablas de red y de hora y los demás PID de servicio del multiplex de origen obedecen ahora a las mismas claves mpegts-filter-nit, mpegts-filter-tdt, mpegts-filter-unnecessary y mpegts-filter-cat que en las demás rutas, en lugar de descartarse incondicionalmente. Con ello ha cambiado el valor por defecto: un flujo extraído de un multiplex lleva las tablas de red y de hora que antes no llevaba; un receptor situado tras ese flujo, y un módulo CI en primer lugar, espera verlas. El comportamiento anterior se recupera con mpegts-filter-nit.

• Una discontinuidad de PCR ya no vacía el búfer de jitter: una entrada que ha captado un salto de PCR hacia delante desplaza el punto de sincronización sobre la marcha, sin drenar la cola, de modo que la discontinuidad cuesta un único tropiezo en lugar de volver a llenar el búfer. La ventana a partir de la cual un salto cuenta como discontinuidad se elige automáticamente (Sincronización).

• Arranque rápido de una entrada HLS: una lista de reproducción en directo se retoma por la cola; a la cola entran solo los últimos segmentos necesarios para el jitter configurado, y no toda la ventana, de modo que la entrada sale al aire con un retardo de un par de segmentos en lugar de una ventana entera de la lista. Una lista de reproducción finalizada (VOD) sigue reproduciéndose desde el principio.

• Supresión de la oscilación de alertas: una alerta que se levanta y se resuelve una y otra vez se pliega en un único incidente; el nodo la mantiene durante la calma y la cierra solo cuando la oscilación ha cesado de verdad. Una tormenta de repeticiones no se propaga ni por el registro ni por los canales externos. Una fuente oscilante identificada una vez lo sigue siendo tras la calma: su siguiente serie se mantiene desde la primera repetición.

• Edición de un canal de EPG: al canal se le asignan un identificador XMLTV independiente del nombre mostrado y denominaciones por idioma, y un canal que ya no hace falta se elimina por completo: con él se van sus denominaciones, sus eventos y su pertenencia a los conjuntos.

• Otras mejoras y correcciones de errores.

versión 2.0.2.335

27.08.2026

• Meshwork (multidominio) — varios servidores se agrupan en dominios con nombre, y el dominio sirve de frontera de aislamiento: la pertenencia de los nodos, el catálogo de recursos y las alertas se propagan únicamente dentro de su propio dominio y entre dominios no se transmite nada. Un nodo puede pertenecer a varios dominios a la vez sin mezclar sus datos. Más información — Meshwork.

• Autodescubrimiento de nodos — basta con indicar el dominio y un único punto de entrada: los nodos intercambian listas de vecinos y construyen por sí mismos una red totalmente mallada de enlaces directos. La clave común del dominio se genera automáticamente y se transmite solo por un canal protegido — TLS o un segmento de confianza de la red local.

• Biblioteca distribuida de recursos — las salidas UDP, RTP, Pro-MPEG y RIST, las entradas multicast UDP, RTP y RIST, así como los enlaces PS1 y SRT se publican en el catálogo común del dominio (/data/library): una lista única de grupos multicast, puertos, VLAN, fuentes SSM y enlaces punto a punto con indicación del nodo y del flujo. El catálogo muestra qué direcciones y puertos están ya ocupados, y una entrada nueva se conecta directamente desde él — eligiendo un flujo que ya se emite en otro nodo del dominio, sin introducir la dirección a mano.

• Vista general de los nodos del dominio — de cada nodo se muestran el estado, la hora del último contacto, el rol, la región, la versión de la compilación, el tiempo de funcionamiento desde el arranque, la carga de CPU, el tráfico por interfaz física y el número de flujos al aire, y de cada enlace entre nodos PS1 o SRT, la tasa de bits, el RTT, la proporción de retransmisiones y pérdidas y un veredicto sobre su estado. Un nodo caído no desaparece de la lista: permanece en ella como inaccesible junto con su alerta durante siete días, y uno retirado del servicio se quita de la vista general con un comando propio.

• Funcionamiento a través de NAT — un nodo situado detrás de NAT participa plenamente en el dominio y sin redirección de los puertos entrantes: se conecta por sí mismo, su punto de acceso público se deduce de la dirección realmente observada y del puerto anunciado, y su estado lo retransmiten los vecinos un salto más allá — el nodo es visible incluso para quienes no pueden dirigirse a él directamente.

• Nombre del nodo tomado del certificado — un nodo sin nombre de host configurado anuncia a sus pares el nombre que cubre su propio certificado, y solo después de que ese nombre se resuelva de vuelta a él; el resultado de la comprobación se ve en los datos del servidor como cert-host y cert-host-refused.

• Inicio de sesión automático de los enlaces dentro del dominio — para los enlaces PS1 y SRT entre nodos de un mismo dominio no hace falta crear un usuario y una contraseña para cada enlace: en el lado que llama (entrada PS1, entrada SRT, salida SRT en modo caller) basta con activar el ajuste «Meshwork peer auth» y la autorización se realiza con el secreto común del dominio. El nodo par confirmado y su flujo se ven en la biblioteca de recursos y en la lista de sesiones.

• Low-Latency HLS y MPEG-DASH sobre CMAF — nuevo modo de difusión «OTT / LL-HLS / DASH»: el multiplexor integrado genera MP4 fragmentado (CMAF), sobre el que se sirven MPEG-DASH en /dash y Low-Latency HLS en /llhls; los paquetes adaptativos se ensamblan también para estos formatos. Más información — Modos de difusión.

• Baja latencia de LL-HLS — la lista de reproducción de medios se divide en partes y se aplican la recarga bloqueante de la lista de reproducción y la sugerencia de precarga, por lo que el reproductor comienza la reproducción sin esperar a que esté listo el segmento completo. Los segmentos CMAF llevan Producer Reference Time, el manifiesto DASH anuncia UTCTiming y la latencia objetivo, y el ajuste «Duración objetivo de la parte LL (ms)» se aplica en caliente, sin reiniciar el flujo.

• HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS y MPEG-TS over HTTP se entregan sobre QUIC en un puerto UDP propio, con 0-RTT opcional; el cliente solicita el paso a QUIC con el parámetro ?h3. QUIC solo funciona sobre TLS: con TLS desactivado el escuchador no se levanta ni se ofrece al cliente, y su estado real se ve en los datos del servidor HTTP y no solo en el ajuste. Las rutas administrativas siguen únicamente en TCP.

• Alineación de los segmentos con IDR — el segmentador distingue un IDR de un fotograma I ordinario: en las fuentes con closed-GOP cada segmento comienza con un punto de entrada completo, por lo que el reproductor abre el flujo en cualquier segmento; en las fuentes con open-GOP la frontera es el fotograma I más próximo.

• Protección de contenidos (DRM) — la difusión OTT de un flujo se puede cifrar: HLS AES-128 con una clave del propio servidor o de un servidor de claves externo y con rotación opcional por ventanas temporales, o bien MPEG Common Encryption (ISO/IEC 23001-7) con los esquemas cenc y cbcs para CMAF y DASH. El cifrado se realiza una sola vez, en el momento de formar el segmento, por lo que el archivo DVR se almacena cifrado y sobrevive a cualquier número de rotaciones de clave. Más información — Protección de contenidos (DRM).

• Cada conexión MPEG-TS over HTTP es una sesión propia — la lista de clientes del flujo tiene ahora una fila por conexión con su propio sess-id, los detalles están disponibles en /data/stream/http-clients/<sess-id>, una conexión concreta se cierra con POST /data/kick?sess-id=<id> y el límite max-conn se respeta también con valores mayores que uno.

• DVR (archivo en red) — cada canal OTT se escribe en disco en paralelo con la difusión, con la misma segmentación y sin un grabador aparte; en el modo de baja latencia el archivo se mantiene en dos líneas, MPEG-TS y CMAF, por lo que la grabación está disponible en el mismo contenedor que la emisión en directo. Más información — DVR.

• Reproducción del archivo (VOD) — el archivo se sirve por las mismas URL HLS, DASH y LL-HLS que la emisión en directo: t=<tiempo> activa el modo VOD y fija el comienzo de la ventana, d=<segundos> — su duración. La lista de reproducción HLS es entonces cerrada, el manifiesto DASH es estático y las interrupciones de la grabación se presentan como periodos separados; los paquetes adaptativos reproducen el archivo con los mismos parámetros.

• Catch-up por EPG — en lugar de t y d basta con pasar epg=<tiempo>: el propio servidor localiza en el canal EPG asociado el programa que se emite en ese momento y toma su comienzo y su duración como límites de la ventana de reproducción.

• Subtítulos en el archivo — las pistas WebVTT se escriben en disco junto con los segmentos y se reproducen en VOD por las mismas URL; las ventanas sin diálogos no ocupan espacio en disco.

• Almacenes DVR — puede haber varios almacenes, cada uno con su propio límite de llenado y su propio orden de limpieza. La profundidad del archivo («Retención (horas)», hasta 90 días) y el mínimo protegido se definen por separado para cada flujo, y la limpieza por espacio libre no toca ni el mínimo protegido ni las ventanas de las sesiones VOD abiertas.

• Monitor DVR — una pantalla específica muestra el estado y el llenado de los almacenes, el volumen y la profundidad del archivo por flujo y las latencias de lectura y de escritura, mientras que el histograma de cobertura (/data/dvrstat) señala no solo los huecos del archivo, sino también su causa — la caída de la entrada, un cambio de PMT, el scrambling, la ejecución de la limpieza. Desde esa misma pantalla se borran el archivo de un flujo concreto y los directorios de los flujos eliminados.

• Un fallo de disco del archivo ya no detiene el nodo — un error al dar servicio al archivo DVR se limita al almacenamiento y al paso donde se produjo: el resto de los flujos y el resto de las líneas de grabación siguen funcionando, y el archivo afectado se marca como necesitado de reconstrucción.

• Alerter — nuevo servicio de notificaciones: cada fallo se convierte en un incidente que se genera, se actualiza y se resuelve automáticamente, mientras que el conjunto activo deduplicado muestra únicamente lo que está ocurriendo ahora. La gravedad se define con una escala única — desde informativa hasta la que exige la intervención del administrador; un incidente de ese tipo se resuelve con la confirmación del operador. Más información — Alertas (alerter).

• Catálogo de códigos de alerta — más de cincuenta tipos de incidente en una única lista: los flujos y sus entradas y salidas, las infracciones de TR 101 290, los recursos del nodo, los almacenes y la salud de la grabación DVR, la recepción DVB y CI/CAM, los transcodificadores, OTT, los certificados y los nodos del dominio. Los umbrales de disparo se configuran en la sección de alertas.

• Entrega externa de las alertas — las alertas salen fuera de la consola web: por correo mediante SMTP (STARTTLS, implicit TLS, AUTH), por mensaje a Telegram y mediante la ejecución de un comando arbitrario, al que el incidente se le entrega en variables de entorno y como JSON completo por la entrada estándar. Cada canal tiene su propio interruptor y su propio umbral de gravedad.

• Alertas de todo el dominio — el operador de guardia ve las alertas de cualquier nodo desde cualquier otro: el conjunto activo se propaga junto con el keep-alive y se retira en cuanto desaparece en el origen, y cada fila indica el nodo de origen. Las alertas de hardware y de sistema permanecen locales de forma predeterminada y se elevan al ámbito del dominio con un ajuste específico.

• Registro en base de datos — los mensajes del servicio se escriben en SQLite: entradas tipificadas con la fuente y el nivel de gravedad, agrupación de las repeticiones consecutivas en una sola fila con un contador y limitación de la retención por plazo y por volumen. A diferencia del conjunto activo de alertas, el registro sobrevive a un reinicio.

• Interruptor general de las notificaciones — con enable desactivado en los ajustes del alertador, el nodo no genera alertas propias ni envía nada al exterior, incluidas las alertas recibidas de sus pares del dominio; en la lista y en el flujo de eventos solo quedan las alertas de los pares distribuidas por el dominio.

• La gravedad de una alerta de entrada/salida sigue a las consecuencias — una entrada que falla mientras no lleva el flujo se marca como Error, mientras que una entrada portadora, cualquier salida y un fallo sin emisión se marcan como Critical; la valoración se recalcula mientras la alerta está abierta y sigue al cambio a la reserva.

• Color en las notificaciones externas — al texto del mensaje se ha añadido un marcador de color del nivel (rojo para los errores, amarillo para los avisos, verde para la retirada, azul para los informativos), y el correo sale en dos variantes a la vez: texto plano y HTML con una franja de color.

• Las notificaciones de Telegram sobreviven a una tormenta — las alertas acumuladas se combinan en el menor número de mensajes que permite el límite de 4096 caracteres, y ante una respuesta de limitación de frecuencia el nodo espera el tiempo indicado y repite el envío en lugar de descartar la notificación.

• El retardo de la notificación se extiende a la entrada de reserva — el aviso de que un flujo funciona en su entrada de reserva solo se levanta si la situación ha durado más que alert-delay, de modo que una fuente que se recupera y vuelve a caer ya no produce una sucesión de altas y bajas; con alert-delay igual a cero el comportamiento es el anterior.

• Monitor TR 101 290 — control continuo de la conformidad del flujo de entrada con el estándar: un veredicto único («Normal», «Problema», «Comprobando…») y un informe estructurado por prioridades 1, 2 y 3, en el que para cada indicador se indican la cláusula del estándar, el valor medido y el límite. El multiplex MPTS se evalúa en su conjunto — por todos los PID, programas y tablas SI. El flujo se clasifica automáticamente como CBR o VBR, y las comprobaciones que solo tienen sentido con una tasa de bits constante no se evalúan en una fuente VBR y no producen falsos disparos. Más información — Monitor TR 101 290.

• Deriva del oscilador de referencia — la desviación sistemática de la frecuencia de reloj de la fuente se mide por regresión lineal en ppm con la tolerancia de ±30 ppm de ISO/IEC 13818-1 y se publica como una métrica aparte. La desviación lenta se compensa con microdesplazamientos suaves del punto de sincronización («Compensación de la deriva de sincronización», activada por defecto), por lo que en la salida no hay saltos.

• Modelo de búfer T-STD — análisis del búfer de vídeo del decodificador de referencia según ISO/IEC 13818-1 con contadores de desbordamiento y de vaciado para MPEG-2, H.264 y HEVC; el cómputo se lleva con el reloj PCR y la velocidad de drenaje se ajusta a la tasa de bits real del vídeo. Se activa con el ajuste «Analizar el búfer de vídeo T-STD».

• Análisis para la inserción de publicidad — análisis de las secciones SCTE-35 con eventos de empalme, puntos de empalme de la capa de transporte con antelación configurable y marcas de acceso aleatorio. Los datos se muestran en las estadísticas del flujo cuando el análisis profundo está activado.

• Asistente de reclamaciones — para un flujo con infracciones persistentes se genera un texto listo para un chat de IA, a partir del cual este redacta una carta formal de reclamación al proveedor del flujo: la relación de infracciones persistentes, los valores medidos, las cláusulas del estándar y el impacto sobre el decodificador. El texto se obtiene con la petición GET /data/stream/<id>/ai-complaint-prompt; el nombre del flujo y la dirección de la fuente no se incluyen en el texto.

• CI/CAM (EN 50221) — host Common Interface integrado: detección del módulo, lectura de su nombre y de la lista de CA_system_id admitidos, selección de los programas que se van a descifrar y envío de CA_PMT para cada uno de ellos. Un módulo combinado con el receptor DVB descifra en línea los programas seleccionados del multiplex recibido, varios a la vez; el estado de las ranuras y el veredicto de cada programa se ven en la interfaz.

• Descifrador por software BISS-1 / BISS-E — se aplica no solo a la recepción desde una tarjeta DVB, sino a cualquier entrada de flujo: la clave se define para todo el SPTS o por programas del multiplex y se cambia en caliente, sin reiniciar la entrada. En la recepción desde una tarjeta DVB el resultado se verifica además con el propio flujo, de modo que una clave incorrecta no aparece como un descifrado correcto, sino que genera una alerta específica.

• Limpieza del acceso condicional en la recepción DVB — del multiplex recibido por una tarjeta DVB se eliminan, mediante un ajuste específico del adaptador, los PID ECM y EMM, y del PMT, los descriptores CA de los programas abiertos: por el resto del trayecto circula un flujo FTA limpio. Si se pierde la clave, la señalización de acceso condicional se restablece para que un receptor situado más abajo en la cadena pueda volver a solicitar el acceso.

• Telemetría del transcodificador — de cada codificador se publica la información de medios de la salida recodificada: el formato del fotograma, el códec de vídeo, el conjunto de códecs de audio y la tasa de bits actual, y de cada proceso — la carga de CPU y la memoria ocupada.

• RTMP y RTMPS — un canal se publica en cualquier receptor RTMP, incluidos YouTube y Facebook: vídeo H.264 o HEVC (HEVC mediante Enhanced RTMP) y una pista AAC; para rtmps:// el nodo se conecta como cliente TLS. En sentido inverso, la entrada obtiene por sí misma el flujo de una fuente rtmp:// o rtmps:// y remultiplexa FLV a MPEG-TS.

• Conmutación de fuente sin cortes — al cambiar la entrada activa en el transmisor, los peers PS1 receptores no se reconectan: la numeración y las marcas de tiempo se mantienen continuas, el pico de la cola se amortigua descartando los paquetes más antiguos y el hueco se completa con la retransmisión habitual.

• Retransmisión adaptativa PS1 — el receptor mide el RTT real hasta el transmisor y ajusta a él por sí mismo los intervalos de las peticiones de repetición; el RTT medido, el intervalo actual de repetición de la petición y el indicador de latencia demasiado baja se muestran en las estadísticas del enlace. La latencia del túnel de recepción se define directamente en milisegundos, en lugar del anterior multiplicador del RTT.

• Estados «Reconectando» y «Acción de administrador» — una entrada o una salida que ha perdido su fuente se reabre en el sitio y permanece en el estado «Reconectando» durante todo el tiempo de los intentos, generando un único aviso por episodio en lugar de un mensaje en cada intento. Una causa que no se resuelve repitiendo — un puerto ocupado, una interfaz ausente, datos que no son MPEG-TS, un fallo de SRT por el cifrado — hace que el nodo la pase al estado «Acción de administrador» con una alerta persistente, mientras que una modificación de los ajustes se aplica de inmediato.

• Fecha del último error — junto al texto del último error de una entrada o de una salida se publica su hora (last-error-ts, el mismo campo está también en el flujo de eventos), de modo que una causa antigua que ha quedado en una entrada en pausa se ve por separado del fallo actual.

• Diagnóstico cuando el contenido de la entrada es inservible — el mensaje sobre la pérdida de sincronización MPEG-TS nombra la causa probable: se han encontrado paquetes pero están desplazados un número conocido de bytes, o bien no hay estructura MPEG-TS en absoluto; para las entradas PS1 y Pro-MPEG se añade una indicación sobre la frase de contraseña del cifrado.

• Tamaño real del búfer de recepción — la entrada publica socket-buffer-actual, el tamaño concedido por el núcleo, mientras que socket-buffer-size sigue siendo solo una petición y el límite del sistema la recorta; la discrepancia se ve así de inmediato en lugar de manifestarse como pérdidas con una tasa de bits alta.

• Multiplexor MPTS: identidad original — los programas pueden conservar sus PID originales y el orden de los programas en la PAT, la SDT y la NIT se define manualmente, por lo que un multiplex se migra a Perfect Streamer sin cambiar la identidad del flujo para el equipamiento receptor. Los programas con scrambling de TS se migran con sus marcas de tiempo originales.

• Numeración automática de PID para SPTS — enable-autopid junto con autopid-base traslada todo el programa a una ventana previsible de 64 identificadores, empezando por la PMT y siguiendo con el vídeo, el audio y el resto de flujos elementales en el orden de la tabla original; un programa que no cabe en la ventana conserva íntegramente sus PID originales.

• El tamaño del datagrama se fija en todas las salidas — el ajuste packets se aplica ahora no solo en SRT, sino también en las salidas UDP, RTP, Pro-MPEG y RIST, y en la salida a un archivo y al flujo estándar establece el tamaño del bloque escrito. Los valores por defecto coinciden con el comportamiento anterior, por lo que una configuración en la que la clave nunca se fijó no cambia; un valor guardado distinto del predeterminado lo ignoraban las compilaciones anteriores y ahora entra en vigor en el primer reinicio: compruébelo antes de actualizar.

• Integración con una facturación externa — cada sesión de espectador se autoriza en un sistema externo de facturación o CRM, se mantiene mediante una reautorización periódica y, al terminar, se le notifica a ese mismo sistema: un ciclo de vida Start / Interim / Stop al estilo de RADIUS, y la revocación de la suscripción corta la sesión en mitad de la visualización. Se cubren OTT, el peering PS1 y las salidas SRT, y la propia facturación se conecta con plantillas de petición y de análisis de la respuesta, sin modificar el software.

• Cliente ACME integrado (Let’s Encrypt) — emisión y renovación automática de los certificados para el servidor web, el servidor HTTP/OTT y el servidor EPG: el certificado se solicita para cada nombre de host configurado, la renovación se comprueba a diario y, si falla, se genera una alerta. Se admiten una autoridad de certificación arbitraria y la vinculación externa de la cuenta, y el certificado nuevo se aplica sin reiniciar el servicio.

• Parada rápida del servicio — la detención ya no espera a un cliente que ha dejado de leer datos: con la misma carga el nodo termina en 2–4 segundos en lugar de aproximadamente un minuto, por lo que un reinicio dura segundos y no deja la emisión sin señal.

• pss_lic 2.0 — la utilidad de consola para gestionar la licencia ha pasado a los comandos apply, c2v, fingerprint, recipient, keys, detach, rehost y cancel con opciones largas: aplica una actualización de licencia recibida, exporta el estado de la clave para el proveedor y traslada la licencia de un nodo a otro, también de forma temporal, y acepta cualquier archivo por la entrada estándar y escribe en la salida estándar. En detalle — pss_lic.

• Edición manual del archivo de configuración — junto con la documentación se publica un JSON Schema para pss.json (estricto y compatible) y una guía paso a paso para editar y trasladar el archivo: la configuración de un nodo detenido se puede editar ahora directamente y trasladar entre instalaciones y versiones tras comprobar el resultado con el esquema, mientras que antes la API HTTP era la única vía admitida. En detalle — El archivo de configuración pss.json.

• Nueva interfaz web — la gestión del nodo se ha trasladado a una consola nueva que se abre en la dirección del nodo (la ruta /admin): vista general, flujos, monitorización del sistema, DVB, DVR, transcodificadores, clientes, registro, alertas y todos los ajustes del servidor. Unos diagramas específicos muestran la topología del dominio Meshwork y el trayecto del flujo seleccionado desde las entradas hasta las salidas. La interfaz anterior se conserva en la dirección /classic. Más información — Interfaz web.

• Inicio de sesión único en el dominio — a una cuenta se le puede permitir el inicio de sesión automático: tras un único inicio con contraseña, el navegador abre el panel de este nodo sin formulario de inicio durante 14 días y sobrevive a un reinicio. Seguir un enlace desde ese panel traslada la sesión a un nodo vecino del dominio si se cumplen las condiciones del traspaso (Servidor web y cuentas); una dirección de un vecino escrita a mano no traslada la sesión. Un script o un panel de terceros presenta la misma clave en la cabecera X-Auth-Token o en el parámetro auth-token, y un administrador revoca el inicio automático en todo el dominio de una vez.

• CORS para la API administrativa — los nodos de un mismo dominio Meshwork están permitidos sin ninguna configuración, el resto de orígenes se enumeran en web-server/cors-origin (el valor * permite cualquier origen, none desactiva el mecanismo), de modo que la interfaz de un nodo se dirige a la API de otro; una petición entre dominios debe llevar el token de forma explícita: la cookie y Digest no actúan en ella.

• Token de la sesión propia — GET /data/auth-token devuelve al cliente su propio token y el plazo absoluto de validez, y en /data/server se ha añadido el campo web-login-expires, de modo que la interfaz muestra hasta cuándo es válido el inicio de sesión sin leer el propio token.

• Cierre de una sesión de inicio automático — POST /data/auth-tokens/revoke?login=<login> cierra todas las sesiones activas de una cuenta, y ?id=<hex> cierra una por el identificador de la lista de sesiones; en la respuesta llega el número de sesiones cerradas, y la revocación se propaga por todo el dominio.

• Motivo del rechazo al pasar a un nodo vecino — si el paso no ha dado un inicio de sesión automático, el nodo devuelve en la dirección un parámetro jump con el valor no-session, foreign-domain, autologin-off o token-refused, en lugar de mostrar en silencio el formulario de contraseña.

• Actualización en tiempo real — el nodo publica su estado como un flujo de eventos en /data/events: al conectarse llega una instantánea completa y, a partir de ahí, una vez por segundo se actualizan los marcos de los flujos, de los recursos del sistema, de los clientes y de los adaptadores DVB, mientras que las alertas y los cambios de estado llegan como eventos. La interfaz y los paneles externos funcionan sin sondeo periódico.

• Ayuda contextual — cada pantalla y cada ventana importante de la nueva interfaz disponen de una llamada a la ayuda que abre la sección de la documentación correspondiente exactamente a lo que está abierto en ese momento: el botón general de ayuda, para la pantalla; el botón «?» del encabezado de la ventana, para esa ventana. La sección se abre en el idioma de la interfaz.

• Idiomas, temas y disposiciones — la interfaz está traducida a seis idiomas (ruso, inglés, alemán, francés, español y portugués), admite un aspecto claro y otro oscuro y ajusta por sí misma la densidad de la disposición al teléfono, la tableta, la estación de trabajo y el videowall.

• Acceso sin límite del número de conexiones — los límites de conexiones del receptor han ganado un tercer estado, «Sin límite», junto a «Protocolo prohibido» y «Como máximo» con un número; antes el acceso ilimitado se representaba con un número deliberadamente grande. El cero sigue significando la prohibición del protocolo, de modo que el sentido de los ajustes guardados no cambia tras la actualización. En detalle — Usuario: añadir y editar.

• La edición del acceso a los flujos no afecta a sesiones ajenas — añadir un flujo a la lista de permitidos y volver a una lista vacía no rompen ninguna sesión, y estrechar la lista cierra las sesiones PS1 y SRT solo en los flujos que han salido de ella. Antes, cualquier edición de la lista desconectaba la cuenta por completo en todos los protocolos.

• Activación de la licencia desde la interfaz web — la pantalla «Licencia» ha ganado una sección «Activación»: la exportación del estado de la clave para el proveedor —como archivo C2V o al portapapeles— y la aplicación de la clave V2C recibida, mediante archivo o pegando el texto. La aplicación de la clave reinicia el nodo. En detalle — Licencia.

• Aviso de caducidad de la licencia — el nodo genera una alerta dos semanas antes del fin del plazo y la eleva al nivel que requiere intervención cuando el plazo se ha cumplido. La alerta se replica por el dominio, por lo que la licencia que caduca de un vecino se ve desde cualquier nodo (Alertas (alerter)).

• Una licencia considerada no auténtica detiene el nodo — un nodo cuya licencia se considera no auténtica levanta una alerta que requiere acción del administrador, reinicia el servicio y el arranque se rechaza: el servicio permanece detenido hasta que en el nodo haya una licencia auténtica. La alerta se replica por el dominio (Alertas (alerter)).

• Vuelta a la última configuración operativa — el nodo guarda una copia de los ajustes con los que arrancó limpiamente la última vez y, cuando pss.json es inaceptable, arranca con ella — con todos sus flujos, y no con los ajustes por defecto, que no contienen flujos. El archivo de ficheros rechazados se ha puesto en orden: nombres en UTC, sufijo numérico en lugar de sobrescribir cuando dos fallos caen en el mismo segundo, las veinte copias más recientes; la alerta nombra directamente la ruta de la copia archivada. En detalle — Comportamiento en el arranque y ante errores de configuración.

• La prioridad de las entradas se edita con el ratón y con el teclado — un administrador puede reordenar las entradas de un flujo arrastrando o con Alt+↑ y Alt+↓, en la pestaña «Entradas» del editor y en la fila desplegada de la lista de flujos (en el teléfono el orden solo se muestra); una entrada añadida se coloca siempre la última y nunca sustituye a la principal (Flujos).

• El número de una entrada es su lugar en la lista de redundancia — un mismo número figura ahora en la fila del flujo, en la fila desplegada, en el editor y en el texto de la alerta. Las entradas con el mismo valor de prioridad conservan el orden en que están registradas, también en las modificaciones posteriores de los ajustes (Redundancia de fuentes).

• El fallo de una entrada abandonada se lee como historial — la entrada que el flujo dejó al pasar a la de reserva se detiene, pero conserva su causa: la interfaz la muestra como una línea atenuada con su antigüedad, y no como un fallo actual, y la alerta sobre el error de esa entrada se retira. La causa es entonces la suya propia, de transporte, si la entrada llegó a comunicarla ella misma (Redundancia de fuentes).

• Ordenación de la lista de clientes — en la pantalla «Clientes» el encabezado de una columna ordena la lista: las columnas numéricas se abren en orden descendente, las de texto de la A a la Z, y una tercera pulsación devuelve el orden del nodo. Se ordena toda la lista encontrada, no la página mostrada (Clientes).

• Salto al flujo desde la pantalla de transcodificadores — la fila del decodificador y de cada codificador ha ganado un botón que abre la lista de flujos en el flujo en cuestión. Disponible en cualquier rol (Transcodificadores).

• El programa del demultiplexor se elige de una lista también para un adaptador DVB — un adaptador en marcha publica su multiplex, y el campo «PNR» ofrece sus programas con sus nombres, incluidos los programas internos T2-MI bajo sus números compuestos (Demultiplexor (demuxer)). El adaptador de una entrada dvb también se elige por su nombre en lugar de introducirse como número de registro (Adaptador DVB (dvb)).

• La recepción DVB ya no depende de la compilación — el tipo de entrada dvb y la sección de adaptadores DVB están disponibles en cualquier nodo; la única condición es un frontend detectado y un controlador que permita al servicio abrirlo (Receptor DVB).

• El escáner DVB cede el sintonizador a un adaptador configurado — un multiplex encontrado puede aplicarse sin esperar al final de la pasada: el adaptador toma el sintonizador y arranca en aproximadamente un segundo, mientras que la exploración termina como cancelada y conserva sus resultados en pantalla. Una pasada se detiene con el botón «Parar» y al cerrar la ventana (Escaneo).

• Los paneles del resumen del nodo siguen la presencia del subsistema — «Transcodificadores» y «Adaptadores DVB» aparecen en el resumen allí donde existe el propio equipamiento o las instancias, o donde hay un fallo que comunicar. En un nodo sin transcodificadores y sin sintonizador estos paneles no están, y tampoco la entrada a sus secciones desde el resumen (Resumen del nodo).

• Direcciones de las interfaces en el monitor del sistema — la tarjeta «Red» y los gráficos de historial llevan la dirección IPv4 de la interfaz cuando el nodo la comunica, incluidas las VLAN anidadas (Monitor del sistema).

• La ruta de un almacenamiento DVR se escribe sin separador final — la interfaz y la API HTTP rechazan ese valor: dos escrituras de un mismo directorio pasarían la comprobación de unicidad como dos almacenamientos distintos (Almacenes DVR).

• El paquete necesita el servicio de protección 10.33 o más reciente — pstreamer suministra las bibliotecas de nueva generación del sistema de protección, y un aksusbd más antiguo no las acepta (Requisitos del sistema). El servicio está en el mismo repositorio y se instala junto con el paquete, pero su actualización es irreversible, sea cual sea el tipo de llave — el procedimiento y sus consecuencias se describen en las páginas de instalación (Instalación en sistemas de la familia RHEL, Instalación en sistemas de la familia Debian).

• Selección explícita del PLP en DVB-T2 — el campo «Stream id (ISI/PLP)» ha ganado un valor «auto» (-1): no se aplica ningún filtro, el sintonizador toma el flujo por defecto del controlador y un adaptador nuevo se crea justamente así. Un cero explícito ha pasado con ello a ser una selección real del flujo cero y no «sin definir», de modo que un adaptador con el cero guardado en sus ajustes pasará, tras actualizar el nodo, a recibir solo ese flujo (Adaptadores).

• El escáner encuentra los PLP — el campo «Sondear PLP hasta» recorre los PLP de los transpondedores DVB-T2 y muestra cada uno de los encontrados en una fila aparte con su propia lista de programas; el número se traslada al adaptador creado, y las estadísticas del adaptador han ganado una línea «PLP / ISI» (Escaneo).

• Búsqueda en los catálogos del escáner — cientos de satélites y bandas regionales están ordenados por nombre y se filtran con una cadena de búsqueda; una fila ya seleccionada no desaparece de la lista, se escriba lo que se escriba (Escaneo DVB).

• Corrección de la referencia al PCR en la PMT — un nuevo ajuste MPEG-TS para fuentes cuya tabla no declara un PCR utilizable: el nodo declara en la PMT el PID en el que el PCR se transmite realmente (Modificación del flujo).

• Reconstrucción del búfer de jitter tras una caída de la fuente — una entrada que ha sobrevivido a una parada de su fuente ya no continúa con una cola casi vacía trasladando a las salidas cada nuevo tropiezo: el nodo reconstruye el búfer una sola vez, al precio de un único corte (Sincronización).

• Modo de control del bitrate del codificador de vídeo — el transcodificador ha ganado la elección entre una velocidad constante y dos modos variables: el número indicado se lee como el bitrate medio (los picos llegan a una vez y media ese valor) o como un techo estricto (la velocidad media resulta entonces dos tercios de él). El número sigue siendo uno solo — el codificador deduce él mismo el segundo límite de una relación fija pico/media de 1,5. En los modos variables el codificador deja de rellenar el flujo elemental, de modo que el ahorro de banda solo se obtiene allí donde el flujo receptor no vuelve a nivelar el bitrate (Ajustes del codificador).

• El reinicio del transcodificador se explica en el registro — cada reinicio del proceso hijo nombra su causa y su código de salida en el nivel «Aviso», y no en silencio en la traza. Además, el nodo ha dejado de reabrir indefinidamente un canal que no responde: tras dos intentos fallidos solicita un proceso nuevo (Supervisión del funcionamiento).

• Un flujo eliminado se ve en el editor abierto — si un flujo se elimina del nodo mientras su editor o su esquema de procesamiento está abierto, el nodo lo comunica en una línea aparte y guardar deja de estar disponible con la misma razón indicada junto al botón. Antes, todas las listas de ese flujo simplemente se vaciaban, lo que parecía un flujo sin entradas ni salidas configuradas (Configurar flujo).

• Un guardado rechazado nombra su causa — en lugar de una única frase general para todos los casos, el formulario indica qué lo impidió exactamente: un tiempo de espera de respuesta agotado, una prohibición por rol o el propio rechazo del nodo, con sus mismas palabras.

• Etiquetas y selección de PID en las reglas de filtrado — cada número lleva su tipo y su códec y, en un multiplex, también el programa al que pertenece; la fila de adición ha ganado la lista de los PID que la fuente transporta realmente. La introducción manual se mantiene: el transporte puede llevar un PID sobre el que no se ha decodificado nada (Editor de entrada y salida).

• Las pantallas DVB muestran el número de programa direccionable — para un servicio dentro de una portadora T2-MI, la lista de programas del adaptador y sus estadísticas llevan el PNR compuesto, el mismo con el que el programa se direcciona en la selección del demultiplexor, de BISS y de CAM. Su número propio dentro de la portadora se repite en cada portadora de un transpondedor con grupos en espejo y no apunta a nada (Estadísticas del adaptador).

• Un slot BISS siempre se ofrece como lista — los programas en claro se han añadido en último lugar, marcados con · clear ·, de modo que en un multiplex sin un solo programa cifrado la lista ya no queda vacía: la clave suele introducirse por adelantado, y un feed de eventos está en claro entre eventos (Desaleatorización).

• De las estadísticas del flujo al transcodificador y a su fuente — si la entrada activa de un flujo la creó un transcodificador, su valor se ha convertido en un enlace a la pantalla de transcodificadores con la fila de la instancia correspondiente desplegada, y junto a él ha aparecido una placa con el nombre del flujo que esa instancia decodifica. Ambos enlaces están disponibles en cualquier rol (Estadísticas del flujo).

• Límites de las ejecuciones en el registro — cada arranque del servicio está marcado en el hilo con una línea propia que lleva el instante del arranque y la compilación con la que la ejecución se levantó: la actual muestra al lado su tiempo de funcionamiento, las pasadas indican cuánto trabajó la ejecución y cuánto estuvo parado el nodo hasta el siguiente arranque, y una ejecución terminada sin parada normal se marca aparte. El separador se coloca también con el filtro por gravedad activado (Registros).

• Límite de tamaño de la base de estadísticas — la base de métricas está acotada no solo por la ventana de retención, sino también por el tamaño. El nodo informa de la última limpieza — cuánto historial queda, cuál es el tamaño de la base y cuánto duró la limpieza — y dice expresamente si el límite de tamaño ha resultado más estricto que la ventana configurada (Configuración del servidor).

• Los valores recortados al cargar se anuncian de inmediato — si el nodo, al leer los ajustes, llevó un valor hasta el límite admisible, lo comunica en pantalla justo después del arranque y no solo con una línea en el registro (Comportamiento en el arranque y ante errores de configuración).

• Una licencia de una generación obsoleta no se acepta — un nodo con una licencia auténtica de la generación anterior no arranca y levanta una alerta propia. No es un plazo vencido ni una falsificación: la generación 2 solo se acepta como licencia de prueba temporal, por lo que una licencia perpetua de esa generación se rechaza de inmediato en lugar de vivir hasta su fecha (Catálogo de códigos de alerta).

• El relleno automático calcula su objetivo a partir del contenido — en el modo automático de bitrate el nodo parte de la velocidad real del contenido y no de su propia salida, de modo que el objetivo ya no sube sin regresar y vuelve a bajar en cuanto el contenido cabe de nuevo en la velocidad configurada (Control de la tasa de bits).

• La ventana de compensación de deriva es proporcional al búfer — la ventana blanda está limitada a un cuarto del tamaño objetivo del búfer de jitter, pero nunca por debajo de 100 ms: una entrada con el búfer estándar ya no funciona sin margen, la compensación recupera la sincronización antes y la reconstrucción de emergencia del búfer al vaciarse por fin se dispara (Sincronización).

• Otras mejoras y correcciones de errores.