Dépannage

Le tableau de bord est au vert mais aucun téléviseur ne reçoit rien

Toutes les chaînes apparaissent en fonctionnement. Les débits semblent plausibles. Pas un seul téléviseur n’a d’image. C’est de loin la panne la plus fréquente sur une nouvelle installation, et c’est presque toujours la route multicast.

Cause probable

La route du trafic multicast pointe vers la mauvaise interface réseau, ou vers une interface sans porteuse — rien de branché, ou branchée sur un port mort. Les paquets sont correctement produits et remis à une interface qui ne mène nulle part.

Pourquoi c’est invisible depuis le processus

Envoyer un datagramme UDP vers une destination multicast non routable réussit. L’appel au socket retourne sans erreur. Il n’y a aucun ICMP unreachable à observer, aucune connexion qui échoue, aucune nouvelle tentative à compter. En conséquence, chaque compteur du processus de diffusion paraît parfaitement sain alors que rien ne sort du bâtiment.

Aucun moteur de diffusion ne peut le détecter, et aucun redémarrage n’y change rien. Il faut le vérifier par rapport à la table de routage de l’hôte, depuis l’extérieur du processus, et c’est ce que fait Castmux.

Lier le socket de sortie à une adresse source ne résout pas le problème. Le noyau consulte toujours la table de routage pour choisir l’interface de sortie ; l’adresse source ne détermine que ce qui apparaît dans l’en-tête du paquet.

Comment le confirmer

Deux commandes sur l’appareil. Demandez au noyau où partirait réellement un datagramme destiné au groupe de la chaîne, puis regardez quelles interfaces ont une porteuse :

# Substitute the destination group of an affected channel
ip route get 239.10.0.1

# Which interfaces are actually up, and which are merely configured
ip -brief link

La première commande indique l’interface qui sera utilisée. Si ce n’est pas l’interface qui fait face aux téléviseurs, vous avez trouvé la panne. Si c’est la bonne interface mais que ip -brief link la montre DOWN ou sans porteuse, vous avez également trouvé la panne.

Les adresses de liaison locale vous induiront en erreur

Une interface porte souvent à la fois une adresse de liaison locale dans 169.254.0.0/16 et son adresse réelle, et ip -brief liste souvent l’adresse de liaison locale en premier. Si vous identifiez les interfaces par la première adresse affichée, vous conclurez que la carte réseau côté téléviseurs n’est pas celle qu’elle est. Lisez toute la ligne.

Correction

Faites pointer toute la plage multicast vers l’interface qui fait face aux téléviseurs, et faites en sorte que la modification survive à un redémarrage — une commande ip route saisie à la main est perdue au prochain redémarrage de l’appareil, et c’est ainsi que cette panne revient des semaines plus tard sans que personne se souvienne de la première fois. L’installation décrit l’unité de routage fournie, qui réévalue périodiquement la route pour qu’elle suive le câble si la liaison change.

Corrigez la plage, jamais des groupes individuels

Ajouter une route d’hôte pour un groupe — un /32 pour 239.10.0.1 — fait fonctionner cette seule chaîne et laisse 224.0.0.0/4 toujours cassé. Chaque chaîne ajoutée ensuite est silencieusement non routable, et la raison ne sautera pas aux yeux, car les chaînes qui fonctionnaient fonctionnent toujours.

Cette erreur précise a provoqué deux incidents distincts de plusieurs heures. L’un se présentait comme un conteneur redémarrant toutes les quinze minutes pendant des heures ; l’autre comme une chaîne unique redémarrant toutes les trente secondes. Tous deux ont été investigués comme des bugs de moteur et de watchdog. Ils n’en étaient pas. Routez la plage.

Castmux vérifie la table de routage depuis l’extérieur du processus et signale une destination comme non routable lorsqu’elle l’est. Il ne redémarre volontairement pas la chaîne dans ce cas : un redémarrage ne peut pas corriger une panne de routage, et une boucle de redémarrage noierait la seule ligne de journal qui nomme la vraie cause. Voir Supervision.

Pixelisation et saccades sur une chaîne

L’image se décompose en blocs, ou se fige et saute, sur une chaîne alors que les autres sont correctes.

Le plus probable : deux émetteurs sur le même groupe

Deux processus émettent vers la même destination multicast. Les téléviseurs reçoivent les deux flux entrelacés, avec pour résultat une corruption continue. L’origine habituelle est une migration : un ancien service encore actif d’une installation précédente, ou une unité système désactivée mais pas arrêtée, qui tourne à côté du nouveau déploiement. Les deux émetteurs paraissent parfaitement sains de leur propre point de vue, car chacun produit un flux valide.

Confirmez avec l’alerte d’émetteur en double, déclenchée lorsque Castmux observe vers l’une de ses destinations un trafic qu’il n’a pas envoyé, et en recherchant sur l’appareil et sur le réseau un autre processus qui émet vers le même groupe et le même port. Corrigez en arrêtant proprement l’ancien émetteur — désactiver une unité n’empêche pas autre chose de la démarrer, vérifiez donc aussi les tâches planifiées.

À envisager également

• Des pertes côté source. Le serveur d’origine livre un flux endommagé et vous le retransmettez fidèlement. Pour le voir honnêtement, faites tourner la chaîne sur le moteur pass-through : il préserve les compteurs de continuité d’origine, si bien que l’analyse en aval montre les pertes. Le moteur de remultiplexage réattribue les compteurs de continuité, ce qui donne à la sortie une apparence structurellement propre et masque la provenance des dégâts. Voir Moteurs de diffusion.
• Un multiplex sursouscrit, si la chaîne est transportée en DVB-C. Si le débit cumulé des services dépasse ce que la porteuse peut contenir, tout le multiplex se dégrade, pas seulement la chaîne signalée. Voir Multiplexage DVB-C.
• Des switchs sans IGMP snooping. Sans snooping, chaque flux multicast est diffusé sur tous les ports. Une douzaine de chaînes arrivent alors sur chaque téléviseur et sur tous les autres équipements du segment, et les ports d’accès saturent. Le symptôme est généralement une pixelisation sur de nombreuses chaînes à la fois, qui s’aggrave à mesure que vous ajoutez des chaînes.

Une chaîne redémarre en boucle

La durée de fonctionnement ne dépasse jamais une ou deux minutes. Commencez par lire le journal de cette chaîne dans l’interface : la raison de chaque redémarrage y est enregistrée, et elle permet de distinguer la plupart des causes ci-dessous sans autre investigation.

Source injoignable ou intermittente

Le serveur d’origine coupe la connexion, ou n’est disponible que par intermittence. Castmux espace progressivement ses tentatives plutôt que de le marteler, et ce délai est réinitialisé après une période prolongée de bon fonctionnement. Vérifiez le serveur d’origine avant de modifier quoi que ce soit sur l’appareil.

Le serveur d’origine publie une adresse IPv6 que l’appareil ne peut pas joindre

Extrêmement fréquent, rarement soupçonné. Voir Tout est lent à démarrer ci-dessous — cela provoque les deux symptômes.

Latence SRT réglée trop bas

La latence configurée doit couvrir le temps d’aller-retour de la liaison avec de la marge pour les retransmissions. Réglée trop bas, la récupération échoue et la session tombe à répétition.

Un watchdog basé sur une métrique qui n’existe pas pour le moteur

Une supervision externe qui alerte sur les images par seconde ou la vitesse de lecture redémarrera indéfiniment des chaînes pass-through saines, car ces métriques n’existent pas pour ce moteur. Voir l’avertissement dans Supervision.

Une liaison montante sursouscrite au démarrage

Si toutes les chaînes démarrent en même temps, chacune ouvre simultanément sa connexion au serveur d’origine et la liaison montante ne peut pas toutes les servir ; plusieurs expirent, redémarrent et réessaient ensemble. L’échelonnement du démarrage existe précisément pour l’éviter. S’il a été réduit ou désactivé, rétablissez-le.

Une chaîne ne démarre pas du tout

Vérifiez ces points dans l’ordre. La liste est classée selon la fréquence à laquelle chacun s’avère être la réponse, pas selon son intérêt.

1. La chaîne est-elle active ? Une chaîne désactivée n’est pas planifiée du tout.
2. Est-elle à la demande sans spectateurs ? C’est la fausse alerte la plus fréquente de cette page. Une chaîne à la demande que personne ne regarde est censée ne pas tourner. Confirmez en ouvrant son aperçu, qui compte comme un spectateur et la démarre. Voir Diffusion à la demande.
3. La source est-elle joignable depuis l’appareil ? Pas depuis votre ordinateur portable — depuis l’appareil. DNS différent, routage différent, règles de pare-feu différentes, peut-être un VLAN différent. Une source qui se lit parfaitement dans VLC sur votre machine vous dit que le serveur d’origine est vivant, et rien sur la capacité de l’appareil à le joindre.
4. La destination est-elle déjà utilisée par une autre chaîne ? Deux chaînes configurées avec le même groupe et le même port, c’est la même panne d’émetteur en double que ci-dessus, créée localement.
5. En DVB-C, la chaîne a-t-elle pu être sondée ? Un service qui n’a pas pu être sondé ne peut pas être affecté à un multiplex. Voir Multiplexage DVB-C.

Tout est lent à démarrer, et les récupérations prennent des secondes

Les chaînes mettent un temps déraisonnable à démarrer, les récupérations de playlist prennent des secondes, et la lenteur est irrégulière — parfois, la même requête est rapide.

Cause

Le serveur d’origine publie un enregistrement IPv6 AAAA et l’appareil n’a aucune route IPv6 fonctionnelle. La sélection d’adresse privilégie IPv6 ; chaque requête HTTP tente donc d’abord IPv6 et ne se rabat qu’ensuite sur IPv4. Le coût de ce repli dépend entièrement de la manière dont la tentative IPv6 échoue :

Comment la tentative IPv6 échoue	Coût par requête
Refus immédiat	Quelques centaines de millisecondes. Agaçant, supportable.
Route en trou noir	Un délai de connexion complet, sans rien pour l'interrompre plus tôt. C'est de là que viennent les blocages de plusieurs secondes.

Payé à chaque requête de playlist et de segment, cela suffit à faire manquer son timing à une chaîne et à la faire redémarrer. Dans un cas, cela a produit une chaîne redémarrant 765 fois en une seule journée.

Celle-ci est souvent mal diagnostiquée : mesurez-la correctement

Ce même incident a d’abord été attribué à un serveur d’origine lent sur la base d’une seule récupération chronométrée qui avait pris 10.8 secondes. Des répétitions de la même récupération ont pris 0.59 seconde. Un seul échantillon d’une panne qui ne touche un délai d’expiration que de temps en temps vous dira ce que vous pensiez déjà. Lancez la récupération dix fois et regardez la distribution.

Correction

Configurez l’appareil pour qu’il privilégie IPv4 sur IPv6 dans la sélection d’adresse. Faites-le aux deux endroits : sur l’hôte et à l’intérieur du conteneur, qui possède sa propre copie de la politique de sélection d’adresse. Ne corriger que l’hôte laisse inchangé le processus de diffusion — celui qui émet les requêtes —, et le symptôme ne bouge pas du tout, ce que l’on interprète généralement comme un diagnostic erroné.

La chaîne est diffusée mais sans son, ou dans la mauvaise langue

L’image est correcte, l’audio manque, ou une seule langue est disponible alors que la source en transporte plusieurs. Trois causes distinctes :

• Le moteur de remultiplexage ne transmet qu’une seule piste audio. Sa sélection de flux par défaut retient un flux vidéo et un flux audio et écarte le reste. Si le site a besoin de plusieurs langues, faites tourner la chaîne sur le moteur pass-through, qui transporte chaque PID audio avec la table de programme d’origine et ses descripteurs de langue, pour que le téléviseur puisse proposer le choix. Voir Moteurs de diffusion.
• Une échelle HLS démultiplexée. Lorsque le serveur d’origine publie l’audio sous forme de rendus séparés plutôt que multiplexé dans les variantes vidéo, sélectionner une seule variante vidéo mettrait à l’antenne une vidéo muette. La protection des profils de résolution le détecte et conserve l’URL maître précisément pour cette raison, en l’indiquant sur la chaîne. Si vous avez remplacé à la main l’URL source pour pointer vers une variante vidéo d’une telle échelle, c’est là que l’audio a disparu. Voir Profils de résolution.
• La source ne transporte réellement qu’une piste. Aucun réglage du moteur ne crée une piste audio absente de l’entrée. Vérifiez auprès du serveur d’origine avant de chercher autre chose.

Un interrupteur de l’interface contredit le badge qui l’accompagne

Un interrupteur affiche un état alors que le statut affiché à côté, issu de la même valeur, affiche l’autre.

C’est un comportement du navigateur, pas un état de l’application. Lors d’un rechargement simple ou d’un retour arrière, les navigateurs restaurent les contrôles de formulaire dans l’état qu’ils avaient auparavant et ignorent l’état envoyé par le serveur dans la page. Le badge est du texte simple et reflète le serveur ; l’interrupteur est un contrôle et reflète le souvenir qu’a votre navigateur de la page précédente.

Forcez un rechargement complet et les deux concorderont. Si cela se produit sur un produit comme celui-ci, c’est parce que les identifiants de chaîne sont réutilisés après une suppression : créez une chaîne, supprimez-la, créez-en une autre, et la nouvelle occupe l’ancien identifiant — le navigateur restaure alors tranquillement l’interrupteur de la chaîne supprimée sur sa remplaçante.

Les téléviseurs ont perdu leurs numéros de chaîne après une modification de la grille

En DVB-C, les téléviseurs enregistrent les chaînes d’après les identités de service transportées dans le multiplex. Modifier l’ordre des emplacements modifie ces identités ; les téléviseurs ne reconnaissent donc plus ce qu’ils avaient enregistré et doivent refaire une recherche — dans tout le bâtiment, ce qui est précisément la tâche dont personne ne veut.

Tant que l’identité de service ne peut pas être figée indépendamment de l’ordre des emplacements prévu, évitez de réordonner un multiplex en service. Ajoutez les nouveaux services à la fin plutôt que de les insérer, et planifiez l’ordre avant que le parc ne soit réglé plutôt qu’après. Voir Multiplexage DVB-C.

Ce qu’il faut envoyer au support

Les éléments suivants transforment un échange de plusieurs jours en une seule réponse. Rassemblez-les avant de rédiger le message, et non en réponse à une demande.

• Le nom de la chaîne, son URL source, et son groupe et port de destination.
• Le journal de cette chaîne, depuis l’interface.
• La sortie de ip route get <group> pour la destination concernée.
• La sortie de ip -brief link.
• Le fichier de configuration, sans les identifiants.
• Si la panne touche une chaîne ou toutes — ce seul point distingue un problème de source d’un problème réseau.
• Si quelque chose a changé sur le réseau. Un switch remplacé, un VLAN modifié, un câble déplacé, une mise à jour de firmware. La réponse est plus souvent oui qu’on ne le pense.