Contacto con el soporte técnico

Esta sección ayuda a preparar la solicitud de modo que el análisis pueda empezar de inmediato, sin un intercambio de preguntas aclaratorias. Consta de un cuestionario que conviene responder antes de dirigirse al soporte y de una lista de los materiales que se adjuntan a la solicitud.

Las solicitudes se envían por correo electrónico; la dirección del soporte figura en el sitio web https://pstreamer.tv/.

La solicitud no debe contener información privada: contraseñas, claves, secretos, direcciones y nombres de sus sistemas y abonados, datos del cliente. El cuestionario está diseñado de modo que ninguna respuesta requiera tales datos, y los materiales se depuran antes del envío según las reglas de la sección Datos privados.

Cuestionario

Responda a las preguntas por orden. Si no conoce una respuesta, indíquelo: también es información y ahorra tiempo.

Nodo

  1. ¿Qué versión de compilación está instalada? Se muestra en la pantalla Acerca del sistema, en la sección «Compilación y bibliotecas»; desde la línea de comandos, /usr/local/bin/pss -v la muestra junto con las versiones de las bibliotecas integradas.

  2. ¿Qué sistema operativo y qué versión? ¿El nodo funciona en un servidor físico o en una máquina virtual?

  3. ¿Qué hardware interviene en el problema: modelo de procesador y cantidad de memoria, modelos de tarjetas de red, tarjetas gráficas y tarjetas DVB?

  4. ¿El nodo funciona solo o forma parte de un dominio Meshwork? Si está en un dominio, ¿cuántos nodos tiene y ejecutan todos la misma versión de compilación?

  5. ¿Qué tipo de licencia es y está vigente? Pantalla Licencia. El identificador de la clave y los archivos C2V/V2C no se adjuntan a la solicitud mientras el soporte no los pida.

Qué ocurre

  1. ¿Qué se esperaba y qué ocurre en su lugar? Describa lo que observa, no la causa supuesta: «en la salida HLS la imagen se congela cada pocos minutos», no «se ha estropeado el transcodificador».

  2. ¿Cuándo apareció el problema por primera vez y cuándo se manifestó por última vez? Indique las horas con la zona horaria. De forma predeterminada, el registro main.log escribe la hora en UTC y sin el año (Registro del servicio): haga corresponder una con otra.

  3. ¿El problema es permanente, periódico o ocurrió una sola vez? Si es periódico, ¿con qué frecuencia y hay algún patrón: hora del día, carga, una fuente determinada?

  4. ¿Se puede reproducir el problema paso a paso? Si es así, enumere los pasos.

  5. ¿Qué cambió poco antes de que apareciera el problema: una actualización de la compilación o del sistema operativo, un cambio de ajustes, una sustitución de hardware, cambios en la red o en la fuente?

Flujos afectados

  1. ¿Qué flujos están afectados: los números de flujo en el nodo? ¿Están afectados todos los flujos, una parte o uno solo?

  2. ¿Qué transporte hay en la entrada y en la salida del flujo afectado, y se trata de SPTS o MPTS? ¿Se utiliza transcodificación y, en tal caso, qué backend y qué versión (Backends y códecs, pantalla Acerca del sistema, sección «Transcodificadores»)?

  3. ¿Qué códecs y qué tasa de bits tiene la fuente? Si dispone de un informe del analizador (Qué adjuntar), este responde a la pregunta.

  4. ¿El problema está en el lado de la entrada o de la salida? ¿Se ve en las estadísticas del flujo (Estadísticas del flujo): errores de continuidad, conmutaciones a la entrada de reserva, reinicios del búfer?

  5. ¿Cómo se comporta la misma fuente sin pasar por el nodo o en otro nodo? ¿Cómo se comporta otra fuente en el mismo flujo?

Servicio y recursos

  1. ¿Se reinició el servicio durante el intervalo del problema? En la pantalla Registros, cada arranque está marcado con la línea «Arranque del streamer»; una ejecución que terminó sin una parada normal se señala por separado.

  2. ¿Qué alertas están activas en el nodo (Alertas)?

  3. ¿Cuál es la carga del procesador, la memoria y las interfaces de red en el momento del problema? Pantalla Monitor del sistema, bloque «Historial».

Qué se ha hecho ya

  1. ¿Qué acciones se han emprendido ya y cuáles dieron resultado: reinicio del flujo o del servicio, cambio de entrada, modificación de ajustes?

Cronología del incidente

  1. Describa el desarrollo de los hechos por orden, con marcas de tiempo y zona horaria:

    • el último momento en que todo funcionaba como se esperaba;

    • los cambios realizados después, en el nodo, en la red, en la fuente o en el receptor;

    • la primera manifestación del problema y cómo se detectó: una alerta, la queja de un abonado, la observación propia;

    • cómo evolucionó después el problema: se agravó, desapareció por sí solo, se repitió;

    • cada acción emprendida y qué cambió después;

    • el estado actual en el momento de la solicitud.

    La cronología une las respuestas a las preguntas anteriores en un único cuadro y permite cotejar los hechos con el registro del nodo línea por línea.

Qué adjuntar

Adjunte lo que guarde relación con el problema. La lista siguiente recoge los materiales más habituales, no un conjunto obligatorio.

El registro del servicio del intervalo del problema: consulte Registro del servicio.

Los registros del transcodificador, si la transcodificación interviene en el problema: ante todo el «Registro anterior» del proceso, así como el último código de salida y el registro actual. Solo se guardan en la memoria del nodo y se pierden con los reinicios, por lo que conviene obtenerlos en primer lugar: consulte Registros del transcodificador.

Las entradas de la pantalla Registros, filtradas por el flujo afectado y el intervalo de fechas. El texto completo de una entrada se copia con el botón «Copiar mensaje».

Capturas de pantalla de las estadísticas del flujo afectado (Estadísticas del flujo) y del monitor del sistema del mismo intervalo.

Los ajustes del flujo afectado, solo después de depurarlos (Datos privados). Una copia de seguridad completa de la configuración desde la pantalla Mantenimiento contiene en texto plano las contraseñas y claves de todos los objetos del nodo; adjúntela solo si el soporte la solicita, y también después de depurarla.

Un informe del analizador sobre la fuente, si el problema parece un defecto del propio flujo: la utilidad TS Analyze Perfect Streamer Toolkit v2.3 — TR 101 290 lee UDP o un archivo y genera un informe de texto o XML.

Salida de diagnóstico según el tipo de problema:

Registro del servicio

El servicio escribe su registro en el archivo main.log. El directorio lo fija la clave log-dir del archivo pss.properties; de forma predeterminada, /var/log/pss. El archivo rota a diario: los días anteriores están al lado, en archivos main.log.<marca de tiempo>, por lo que para un intervalo pasado se necesita el archivo de ese día y no el main.log actual.

La hora de las líneas del registro se indica sin el año y, de forma predeterminada, en UTC; la hora local se activa con la clave log-time-local del mismo archivo.

$ ls -l /var/log/pss/
$ tail -n 200 /var/log/pss/main.log
$ journalctl -u pss -n 50

Los dos últimos comandos no son equivalentes. Si el servicio no llegó a arrancar, la causa puede estar antes del propio registro (su directorio no está accesible, pss.properties no se puede leer) y entonces main.log no tendrá ni una línea al respecto: el archivo puede haber quedado de la ejecución anterior y mostrar contenido antiguo. El servicio imprime esa causa en una línea que empieza por !!!, y se ve en el diario del sistema, es decir, en la salida de journalctl -u pss. Las líneas ordinarias del registro llegan allí también solo si en pss.properties está activado log-to-console o log-to-syslog.

El nivel de registro se establece en la pantalla Configuración del servidor: uno general y otros aparte para las bibliotecas SRT, RIST y FFmpeg. Las entradas y salidas de determinados transportes tienen su propio trazado: el campo Trace (Campos de entrada y salida por transporte). Suba el nivel o active el trazado solo cuando lo pida el soporte, y restablezca el valor anterior tras la recogida: un registro detallado crece deprisa.

Registros del transcodificador

Si la transcodificación interviene en el problema, el registro del proceso del transcodificador es el material principal de la solicitud: la causa de un fallo de codificación o decodificación casi siempre solo se ve en él.

El proceso del transcodificador mantiene siempre un registro detallado; no hace falta activar el trazado aparte. Pero este registro no se escribe en un archivo: el nodo guarda en memoria solo su final, los últimos 256 KB, y solo de dos ejecuciones del proceso: la actual y la anterior. El registro se abre en la ventana Instancia de transcodificador (pantalla Transcodificadores), en el bloque «Registro del proceso»: «Registro actual», «Registro anterior» y «Último código de salida». Cada registro se obtiene con el botón «Copiar».

Lo más valioso es el «Registro anterior». El proceso que falló normalmente ya se ha reiniciado, por el temporizador watchdog o por el propio nodo, y entonces es precisamente el registro anterior el que contiene la ejecución que terminó, junto con los mensajes que precedieron al fallo. El registro actual describe ya la nueva ejecución y solo muestra si el problema se repite.

De ello se derivan las siguientes reglas de recogida:

  • Copie el «Registro anterior» en cuanto note el problema. Cada nueva ejecución del proceso (un reinicio por watchdog, la parada y el nuevo arranque del flujo) desplaza los registros una posición: el actual pasa a ser el anterior, y el anterior previo se borra. Si el fallo se repite antes de copiar el registro, se perderá la constancia del primer fallo. Reiniciar el servicio o el nodo borra ambos registros.

  • No reinicie el flujo ni el servicio antes de copiar el registro, aunque el reinicio restablezca el funcionamiento.

  • Adjunte junto con él el último código de salida y el registro actual.

  • En un proceso que lleva mucho tiempo en marcha, el principio del registro ya se ha desplazado. Si importa el momento del arranque (por ejemplo, la elección del dispositivo y del controlador), reproduzca el problema tras reiniciar el flujo y copie el registro de inmediato.

En el registro del servicio también queda una línea sobre la finalización del proceso: cuando el transcodificador termina por sí solo, el nodo escribe en main.log una advertencia con su último mensaje y su código de salida. Estas líneas sobreviven al reinicio del servicio y permiten encontrar el momento del fallo aunque el propio registro del proceso ya se haya perdido:

$ grep -i 'transcoder' /var/log/pss/main.log

Adjunte a los registros del transcodificador el tipo y la versión del backend de la pantalla Acerca del sistema (sección «Transcodificadores») y la salida de diagnóstico del dispositivo: nvidia-smi o vainfo (Qué adjuntar).

Datos privados

Los registros, los ajustes y las capturas de pantalla contienen datos que no deben llegar a la solicitud. Sustitúyalos antes del envío:

  • contraseñas, frases de paso, claves y secretos: la lista completa de las claves de configuración que los almacenan figura en la sección Valores que no se deben enviar;

  • direcciones con credenciales directamente en el enlace: en la fuente de una entrada y en la dirección de publicación en una plataforma externa;

  • direcciones IP y nombres de host de fuentes, receptores y abonados, así como las direcciones del propio nodo;

  • nombres de abonados, inicios de sesión de cuentas, nombres de canales y datos del cliente, si por sí mismos revelan información.

Sustituya de forma coherente: un mismo valor original, en todas partes por una misma sustitución (10.0.0.5 → HOST-A). Así, en el registro depurado sigue viéndose qué líneas corresponden a un mismo nodo y cuáles a nodos distintos, y el análisis no pierde sentido.

No incluya en la solicitud las credenciales de acceso al nodo o a su interfaz web. Si para el análisis hace falta acceso, la forma de facilitarlo se acuerda por separado.