Contacter le support technique

Cette section aide à préparer une demande de sorte que l’analyse puisse commencer immédiatement, sans échange de questions de clarification. Elle se compose d’un questionnaire auquel il convient de répondre avant de prendre contact et de la liste des éléments à joindre à la demande.

Les demandes sont envoyées par e-mail ; l’adresse du support est indiquée sur le site https://pstreamer.tv/.

Une demande ne doit contenir aucune information privée : mots de passe, clés, secrets, adresses et noms de vos systèmes et abonnés, informations sur le client. Le questionnaire est conçu de sorte qu’aucune réponse n’exige de telles données, et les éléments sont nettoyés avant l’envoi selon les règles de la section Données privées.

Questionnaire

Répondez aux questions dans l’ordre. Si vous ne connaissez pas une réponse, indiquez-le : c’est aussi une information, et elle fait gagner du temps.

Nœud

  1. Quelle version du build est installée ? Elle est affichée sur l’écran À propos dans la section « Build et bibliothèques » ; en ligne de commande, /usr/local/bin/pss -v l’affiche avec les versions des bibliothèques intégrées.

  2. Quel système d’exploitation et quelle version ? Le nœud fonctionne-t-il sur un serveur physique ou dans une machine virtuelle ?

  3. Quel matériel est impliqué dans le problème : modèle de processeur et quantité de mémoire, modèles de cartes réseau, de cartes graphiques et de cartes DVB ?

  4. Le nœud fonctionne-t-il seul ou fait-il partie d’un domaine Meshwork ? S’il est dans un domaine, combien de nœuds celui-ci compte-t-il et exécutent-ils tous la même version du build ?

  5. Quel est le type de licence et est-elle valide ? Écran Licence. L’identifiant de la clé et les fichiers C2V/V2C ne sont pas joints à la demande tant que le support ne les réclame pas.

Ce qui se passe

  1. Qu’est-ce qui était attendu et que se passe-t-il à la place ? Décrivez ce que vous observez, et non la cause supposée : « sur la sortie HLS, l’image se fige toutes les quelques minutes », et non « le transcodeur est en panne ».

  2. Quand le problème est-il apparu pour la première fois et quand s’est-il manifesté pour la dernière fois ? Indiquez les heures avec le fuseau horaire. Par défaut, le journal main.log écrit l’heure en UTC et sans l’année (Journal du service) — faites correspondre l’un et l’autre.

  3. Le problème est-il permanent, périodique ou ne s’est-il produit qu’une fois ? S’il est périodique, à quelle fréquence et y a-t-il une régularité : heure de la journée, charge, une source donnée ?

  4. Le problème est-il reproductible pas à pas ? Si oui, énumérez les étapes.

  5. Qu’est-ce qui a changé peu avant l’apparition du problème : mise à jour du build ou du système d’exploitation, modification des réglages, remplacement de matériel, changements dans le réseau ou du côté de la source ?

Flux concernés

  1. Quels flux sont concernés — les numéros des flux sur le nœud ? Tous les flux sont-ils concernés, une partie ou un seul ?

  2. Quel transport est utilisé en entrée et en sortie du flux concerné, s’agit-il de SPTS ou de MPTS ? Le transcodage est-il utilisé, et si oui, quel backend et quelle version (Backends et codecs, écran À propos, section « Transcodeurs ») ?

  3. Quels codecs et quel débit la source présente-t-elle ? Si vous disposez d’un rapport d’analyseur (Éléments à joindre), il répond à cette question.

  4. Le problème se situe-t-il côté entrée ou côté sortie ? Est-il visible dans les statistiques du flux (Statistiques du flux) — erreurs de continuité, basculements vers l’entrée de secours, réinitialisations du tampon ?

  5. Comment la même source se comporte-t-elle en contournant le nœud ou sur un autre nœud ? Comment une autre source se comporte-t-elle sur le même flux ?

Service et ressources

  1. Le service a-t-il été redémarré pendant l’intervalle du problème ? Sur l’écran Journaux, chaque démarrage est marqué par une ligne « Démarrage du streamer » ; une exécution terminée sans arrêt normal est signalée à part.

  2. Quelles alertes sont actives sur le nœud (Alertes) ?

  3. Quelle est la charge du processeur, de la mémoire et des interfaces réseau au moment du problème ? Écran Moniteur système, bloc « Historique ».

Ce qui a déjà été fait

  1. Quelles actions ont déjà été entreprises et lesquelles ont donné un résultat : redémarrage du flux ou du service, changement d’entrée, modification des réglages ?

Chronologie de l’incident

  1. Décrivez le déroulement des événements dans l’ordre, avec les horodatages et le fuseau horaire :

    • le dernier moment où tout fonctionnait comme prévu ;

    • les modifications apportées après ce moment — sur le nœud, dans le réseau, du côté de la source ou du destinataire ;

    • la première manifestation du problème et la manière dont il a été détecté : alerte, plainte d’un abonné, observation personnelle ;

    • comment le problème a évolué ensuite : il s’est aggravé, a disparu de lui-même, s’est répété ;

    • chaque action entreprise et ce qui a changé ensuite ;

    • l’état actuel au moment de la demande.

    La chronologie relie les réponses aux questions précédentes en une seule image et permet de confronter les événements au journal du nœud ligne par ligne.

Éléments à joindre

Joignez ce qui se rapporte au problème. La liste ci-dessous présente les éléments les plus courants, et non un ensemble obligatoire.

Le journal du service pour l’intervalle du problème — voir Journal du service.

Les journaux du transcodeur, si le transcodage intervient dans le problème — avant tout le « Journal précédent » du processus, ainsi que le dernier code de sortie et le journal actuel. Ils ne sont conservés que dans la mémoire du nœud et se perdent lors des redémarrages ; relevez-les donc en premier — voir Journaux du transcodeur.

Les entrées de l’écran Journaux, filtrées par flux concerné et par plage de dates. Le texte complet d’une entrée se copie avec le bouton « Copier le message ».

Des captures d’écran des statistiques du flux concerné (Statistiques du flux) et du moniteur système pour le même intervalle.

Les réglages du flux concerné — uniquement après nettoyage (Données privées). Une sauvegarde complète de la configuration depuis l’écran Maintenance contient en clair les mots de passe et les clés de tous les objets du nœud ; ne la joignez que si le support la demande, et également après nettoyage.

Un rapport d’analyseur sur la source, si le problème ressemble à un défaut du flux lui-même : l’utilitaire TS Analyze Perfect Streamer Toolkit v2.3 — TR 101 290 lit de l’UDP ou un fichier et produit un rapport texte ou XML.

Sortie de diagnostic selon la nature du problème :

Journal du service

Le service écrit son journal dans le fichier main.log. Le répertoire est défini par la clé log-dir du fichier pss.properties, par défaut /var/log/pss. Le fichier fait l’objet d’une rotation quotidienne : les jours précédents se trouvent à côté, dans des fichiers main.log.<horodatage> ; pour un intervalle passé, il faut donc le fichier de ce jour-là et non le main.log actuel.

Dans les lignes du journal, l’heure est indiquée sans l’année et, par défaut, en UTC ; l’heure locale s’active avec la clé log-time-local du même fichier.

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

Les deux dernières commandes ne sont pas équivalentes. Si le service n’a pas démarré du tout, la cause peut se situer avant le journal lui-même — son répertoire est inaccessible, pss.properties est illisible — et main.log n’en contiendra alors pas une ligne : le fichier peut subsister de l’exécution précédente et montrer d’anciennes données. Le service imprime une telle cause dans une ligne commençant par !!!, et elle est visible dans le journal système, c’est-à-dire dans la sortie de journalctl -u pss. Les lignes ordinaires du journal n’y parviennent que si log-to-console ou log-to-syslog est activé dans pss.properties.

Le niveau de journalisation se règle sur l’écran Paramètres du serveur — un niveau général et des niveaux distincts pour les bibliothèques SRT, RIST et FFmpeg. Les entrées et sorties de certains transports disposent de leur propre traçage — le champ Trace (Champs d’entrée et de sortie par transport). N’augmentez le niveau ou n’activez le traçage que lorsque le support le demande, et rétablissez la valeur précédente après la collecte : un journal détaillé grossit vite.

Journaux du transcodeur

Si le transcodage intervient dans le problème, le journal du processus du transcodeur est l’élément principal de la demande : la cause d’une défaillance d’encodage ou de décodage n’y est presque toujours visible qu’à cet endroit.

Le processus du transcodeur tient toujours un journal détaillé ; il n’est pas nécessaire d’activer le traçage séparément. Mais ce journal n’est pas écrit dans un fichier : le nœud n’en garde en mémoire que la fin, les derniers 256 Ko, et seulement pour deux exécutions du processus — l’actuelle et la précédente. Le journal s’ouvre dans la fenêtre Instance de transcodeur (écran Transcodeurs), dans le bloc « Journal du processus » : « Journal actuel », « Journal précédent » et « Dernier code de sortie ». Chaque journal se récupère avec le bouton « Copier ».

Le « Journal précédent » est le plus précieux. Le processus défaillant a généralement déjà été redémarré — par le chien de garde (watchdog) ou par le nœud lui-même — et c’est alors le journal précédent qui contient l’exécution terminée, avec les messages qui ont précédé la défaillance. Le journal actuel décrit déjà la nouvelle exécution et montre seulement si le problème se répète.

Il en découle les règles de collecte suivantes :

  • Copiez le « Journal précédent » dès que vous remarquez le problème. Chaque nouvelle exécution du processus — redémarrage par le watchdog, arrêt puis nouveau démarrage du flux — décale les journaux d’une position : l’actuel devient le précédent, et l’ancien précédent est effacé. Si la défaillance se reproduit avant que le journal ait été copié, la trace de la première défaillance sera perdue. Le redémarrage du service ou du nœud efface les deux journaux.

  • Ne redémarrez ni le flux ni le service avant d’avoir copié le journal — même si le redémarrage rétablit le fonctionnement.

  • Joignez avec lui le dernier code de sortie et le journal actuel.

  • Pour un processus qui tourne depuis longtemps, le début du journal a déjà été évincé. Si le moment du démarrage est important — par exemple le choix du périphérique et du pilote — reproduisez le problème après avoir redémarré le flux et copiez le journal immédiatement.

Une ligne sur la fin du processus subsiste aussi dans le journal du service : lorsque le transcodeur se termine de lui-même, le nœud écrit dans main.log un avertissement avec son dernier message et son code de sortie. Ces lignes survivent au redémarrage du service et permettent de retrouver le moment de la défaillance, même si le journal du processus lui-même est déjà perdu :

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

Joignez aux journaux du transcodeur le type et la version du backend relevés sur l’écran À propos (section « Transcodeurs ») ainsi que la sortie de diagnostic du périphérique — nvidia-smi ou vainfo (Éléments à joindre).

Données privées

Les journaux, les réglages et les captures d’écran contiennent des données qui ne doivent pas figurer dans une demande. Remplacez-les avant l’envoi :

  • les mots de passe, phrases secrètes, clés et secrets — la liste complète des clés de configuration qui les stockent figure dans la section Des valeurs à ne pas transmettre ;

  • les adresses contenant des identifiants directement dans le lien — pour la source d’une entrée et pour l’adresse de publication sur une plateforme externe ;

  • les adresses IP et noms d’hôte des sources, des destinataires et des abonnés, ainsi que les adresses du nœud lui-même ;

  • les noms des abonnés, les identifiants des comptes, les noms des chaînes et les informations sur le client, s’ils révèlent à eux seuls des informations.

Remplacez de manière cohérente : une même valeur d’origine partout par une même substitution (10.0.0.5 → HOST-A). Le journal nettoyé montre alors toujours quelles lignes se rapportent à un même nœud et lesquelles à des nœuds différents, et l’analyse garde son sens.

Ne transmettez pas dans une demande les identifiants de connexion au nœud ou à son interface web. Si un accès est nécessaire pour l’analyse, la manière de le fournir est convenue séparément.