“TV noire / IPTV qui gèle” : guide de diagnostic terrain (multicast, IGMP, uplinks, Wi‑Fi, STB, WAN)

Illustration générée par IA — visuel conceptuel.

Une TV « noire », une image qui gèle ou un zapping soudainement lent en hôtel peuvent avoir des causes très différentes : problème local (STB, câble, port switch), souci d’uplink (erreurs / congestion), configuration multicast (IGMP snooping / querier), ou dépendance WAN (si OTT/unicast). L’objectif de ce guide est de passer du symptôme à la cause probable en quelques minutes, puis de lancer les tests les plus discriminants — ceux qui permettent de trier rapidement, sans « refaire le réseau ».

Pour replacer ce dépannage dans une architecture globale, vous pouvez aussi lire notre guide sur l’architecture réseau IP d’un hôtel. Et si vous souhaitez aller plus loin sur la validation (recette), l’article Recette multicast/IGMP (IPTV & AV-over-IP) : checklist de tests et symptômes complète ce diagnostic terrain.

Avant de commencer : 3 minutes de qualification (qui évitent les fausses pistes)

1) Le périmètre de l’incident (une chambre, un étage, ou tout l’hôtel ?)

• Une seule chambre / une seule TV : suspectez d’abord STB/TV, câble HDMI/Ethernet, prise murale, port switch, mauvais VLAN, ou un défaut d’alimentation locale.
• Un couloir / un étage / une baie : suspectez un switch d’accès, un uplink (erreurs / négociation), une boucle, ou un problème multicast local à un VLAN (IGMP/querier).
• Tout le site : suspectez la distribution/cœur, la chaîne TV (headend/serveur/middleware), ou le WAN (si TV OTT). Dans ce cas, évitez de « corriger » chambre par chambre : collectez d’abord des preuves au niveau réseau.

2) Filaire ou Wi‑Fi ? (test comparatif simple)

• Filaire OK / Wi‑Fi KO : piste Wi‑Fi (capacité radio, multicast sur WLAN, optimisation multicast→unicast, roaming, SSID/VLAN).
• Wi‑Fi OK / filaire KO : piste LAN (ports, VLAN/tagging, uplink, IGMP).
• Les deux KO : remontez dans la chaîne (DHCP/DNS, cœur, headend, WAN) au lieu d’insister sur l’accès.

3) Multicast (IPTV interne) ou unicast (OTT) ?

• IPTV “interne” (tête de réseau / plateforme sur site) : fréquemment multicast (zapping = abonnements IGMP).
• TV/applications OTT (Internet) : souvent unicast (dépendance WAN, DNS, firewall, latence/pertes).

Astuce exploitation : si vous ne savez pas quel mode est utilisé, ne « supposez » pas. Posez une question simple à l’intégrateur/éditeur (ou vérifiez sur un port miroir) : voyez-vous des flux UDP multicast sur le VLAN TV, et des messages IGMP lors d’un zapping ?

Tableau de triage : symptômes → causes probables → tests rapides (terrain)

Symptôme observé	Causes probables (pistes à vérifier)	Tests rapides (réalisables)	Limites / pièges
TV noire (pas de chaîne, écran noir)	Pas d’IP/DHCP, mauvais VLAN, port/câble, STB bloqué, headend/middleware indisponible	Vérifier lien/LED, IP STB, bail DHCP, swap STB, test sur un autre port	Une TV noire peut être un symptôme applicatif (DRM/middleware) autant que réseau
Image figée / macro‑blocs / audio qui coupe	Perte paquets (drops), uplink saturé/instable, flooding multicast, Wi‑Fi multicast, erreurs physiques	Compteurs erreurs/drops/CRC (ports + uplinks), tester même chaîne sur filaire, vérifier si plusieurs flux arrivent au même port	Sur multicast UDP, l’absence de retransmission masque parfois la cause (ça “passe” puis gèle)
Zapping lent (ou instable)	IGMP snooping/querier absent, tables multicast incohérentes, Wi‑Fi sans optimisation, STB sur mauvais segment	Observer IGMP queries + joins/leaves, vérifier tables IGMP snooping, comparer filaire vs Wi‑Fi	Très dépendant des équipements et timers (ne concluez pas sans preuve)
Dégradation “en cascade” (TV + Wi‑Fi + VoIP)	Tempête/flooding (multicast/broadcast), boucle L2, uplink en erreur	Utilisation uplinks, CPU/alertes switch, taux d’erreurs, spanning-tree/loop‑guard (si visibles)	Attention au « faux corrélat » : un incident WAN peut aussi impacter plusieurs services
Uniquement OTT qui gèle (apps Internet)	WAN saturé/pertes, DNS, firewall, politique QoS, CDN/DRM	Mesurer latence/pertes vers Internet, vérifier saturation firewall, test sur un autre lien si failover	Ne pas chercher IGMP si le service est unicast OTT

Cas n°1 : “TV noire” (aucune image / aucun flux)

Étape A : prouver que le STB/TV est “sur le bon réseau”

• Lien physique : LED port switch/prise murale, état du câble Ethernet.
• Adresse IP : le STB obtient-il une IP ? (menu réseau, diagnostic STB, ou supervision si disponible)
• Bail DHCP : voyez-vous un bail correspondant au STB dans le bon VLAN ?
• Test “autre port” : brancher temporairement le STB sur un port connu OK (même baie/étage si possible).

Étape B : isoler STB/TV vs infrastructure

• Swap contrôlé : échanger un STB fonctionnel et un STB en défaut (si votre procédure exploitation l’autorise) pour voir si le défaut suit l’équipement ou le point réseau.
• Test STB sur un autre écran : utile si l’incident ressemble à un problème HDMI / entrée TV / mode hôtel.

Si ces vérifications échouent, ne basculez pas immédiatement sur « IGMP/cœur réseau » : une TV noire est très souvent locale quand elle ne touche qu’une chambre.

Cas n°2 : “IPTV qui gèle” (image figée, pixellisation, son qui décroche)

1) Chercher des pertes/erreurs réseau là où elles font mal (ports + uplinks)

• Sur le port STB : erreurs (CRC), flaps (lien qui monte/descend), drops/discards.
• Sur l’uplink de baie : mêmes compteurs + utilisation du lien (pics, saturation).
• Comparer deux chambres : une qui gèle et une qui est OK, pour voir si la différence se situe sur un switch/segment précis.

2) Écarter rapidement un flooding multicast (le grand classique)

Le flooding multicast, côté exploitation, ressemble souvent à « l’IPTV marche… puis se dégrade », parfois en même temps que d’autres services. L’idée à tester est simple : le VLAN TV reçoit-il “trop” de flux, y compris sur des ports qui ne devraient pas les recevoir ?

• Indice terrain : uplinks très chargés alors que peu de chambres regardent la TV.
• Indice réseau : plusieurs groupes multicast visibles sur un port STB alors que la TV n’en regarde qu’un.

Si vous avez un port mirror/SPAN, une capture courte (même quelques dizaines de secondes) permet souvent de trancher : voyez-vous un seul flux (celui de la chaîne regardée) ou plusieurs flux simultanément ?

Cas n°3 : “Zapping lent” (ou aléatoire)

Pourquoi le zapping devient “réseau” en IPTV multicast

En multicast, le changement de chaîne implique typiquement un abonnement (join) à un nouveau groupe et un désabonnement (leave) de l’ancien, via IGMP. Quand la chaîne met trop de temps à apparaître, on suspecte souvent un souci de maintien des tables multicast (IGMP snooping / querier), ou une diffusion multicast mal maîtrisée sur Wi‑Fi.

Tests simples qui évitent les débats

• Comparer filaire vs Wi‑Fi sur le même service : si le zapping est « normal » en filaire mais lent en Wi‑Fi, la piste WLAN devient prioritaire.
• Rechercher une logique “par VLAN” : un VLAN marche, l’autre non → suspectez querier/snooping incohérents (ou configuration différenciée).
• Demander un état (ou extraire une preuve) des tables IGMP snooping : groupes ↔ ports abonnés.

Focus diagnostic : multicast flooding / IGMP mal maîtrisé (ce qu’il faut prouver)

Ce que vous cherchez à démontrer

Dans un VLAN IPTV, un switch qui ne limite pas correctement le multicast peut se retrouver à répliquer des flux de façon non ciblée (flooding). Dans ce cas, ce n’est pas seulement la TV qui souffre : le réseau se charge inutilement, et la vidéo (souvent en UDP) devient très sensible aux pertes et congestions.

Tests “preuve” (et pas intuition)

• Table IGMP snooping : quels groupes sont présents, et sur quels ports ils sortent.
• Capture sur port STB : le port reçoit-il des flux de chaînes non demandées ?
• Mesure uplink : le volume multicast est-il cohérent avec l’usage réel (nombre de TV actives) ?

Si vous souhaitez passer à une logique de tests structurés (avant ouverture ou après modification), reportez-vous à la checklist de recette multicast/IGMP pour cadrer captures, preuves et livrables.

Focus diagnostic Wi‑Fi : quand le multicast “mange” l’airtime

En hôtel, une IPTV sur Wi‑Fi (ou une hospitality TV IP utilisée en WLAN) peut devenir instable même si la couverture semble correcte. La cause fréquente n’est pas « la puissance radio », mais la nature du trafic : le multicast sur Wi‑Fi, sans optimisation, peut consommer beaucoup d’airtime et pénaliser la TV elle‑même et tout le SSID.

Le test qui tranche

• Même chaîne, même chambre : filaire vs Wi‑Fi. Si la TV est stable en filaire et instable en Wi‑Fi, priorisez le diagnostic WLAN (capacité, multicast, roaming, optimisation multicast→unicast).

Points de contrôle côté Wi‑Fi (sans dépendre d’une marque)

• Le SSID TV est-il séparé (VLAN/SSID) et dimensionné pour ce service ?
• Existe-t-il une fonctionnalité d’optimisation multicast→unicast (selon contrôleur/AP), et est-elle activée sur le bon SSID ?
• Le WLAN est-il sous charge (zones denses) au moment des gels ?

Pour mesurer réellement la capacité (et pas seulement la couverture), vous pouvez vous appuyer sur notre protocole simple de test de capacité Wi‑Fi, et sur notre guide Wi‑Fi hôtelier si la problématique dépasse l’IPTV.

Uplinks, négociation, erreurs : la cause “invisible” qui ressemble à un problème IGMP

Un gel image et un zapping erratique peuvent venir d’un problème très basique : un uplink en erreur, une négociation incohérente, une agrégation mal formée, ou des erreurs CRC sur un lien cuivre. Avant d’ouvrir un chantier “multicast”, vérifiez :

• Les erreurs CRC et drops/discards sur les uplinks des switches d’étage.
• Les flaps (lien instable) sur un port d’uplink ou un port STB.
• La cohérence speed/duplex (et le comportement après redémarrage).

Une approche robuste consiste à corréler : « quels switches / quels étages » et « quels uplinks ». Si l’incident suit un uplink, il est inutile d’accuser un STB ou l’IGMP.

Quand l’IGMP est innocent : dépendances applicatives et WAN (OTT/unicast)

Si votre service TV inclut des chaînes OTT ou des applications, un incident WAN (latence/pertes/congestion), un problème DNS, ou une politique firewall peut produire exactement la même perception client : “ça gèle”. Le bon réflexe est de séparer les tests :

• Les chaînes/modes internes (si disponibles) sont-ils stables pendant que l’OTT gèle ?
• Observe‑t‑on une dégradation WAN simultanée (pertes, saturation) sur les outils de supervision réseau ?
• Le problème suit-il un basculement (failover) ou un incident opérateur ?

Si la TV dépend fortement du WAN, il peut être utile de cadrer la continuité WAN et les modes dégradés (priorités par service). Voir Deux connexions Internet : comment assurer le failover.

Ce qu’il faut collecter avant d’escalader (pour éviter les allers-retours)

Avant d’appeler un intégrateur, un opérateur ou un support constructeur, collectez des éléments simples, horodatés, et vérifiables :

• Date/heure précises + chambres impactées (et chambres témoins OK).
• Filaire ou Wi‑Fi + SSID/VLAN concernés.
• Switch/port de 2–3 STB impactés (et 1 STB OK sur le même étage si possible).
• Compteurs sur uplinks et ports STB (CRC, drops, flaps) au moment du symptôme.
• Si possible : un extrait des tables IGMP snooping (groupes → ports), et/ou une capture courte lors d’un zapping (join/leave).

Ces preuves transforment une discussion “opinions” en diagnostic : l’escalade est plus rapide, et le correctif plus ciblé.

Pour aller plus loin (conception, exploitation, et choix d’architecture)

• Si vous hésitez entre IPTV et coaxial (ou une architecture hybride), l’article IPTV ou télédistribution coaxiale : quelle architecture pour un hôtel ? aide à choisir sans déplacer la criticité au mauvais endroit.
• Pour cadrer la TV côté expérience, parc et exploitation, voir Hospitality TV : quelle différence avec une Smart TV classique ? et la page Hospitality TV (solution).
• Si votre établissement diffuse aussi de la vidéo sur IP hors IPTV (salles, affichage, AV), l’article AV-over-IP : distribuer audio et vidéo sur un réseau professionnel éclaire les points communs (multicast, segmentation, recette).

Vous souhaitez un diagnostic “exploitation” (symptômes → preuves → correction) ou une remise à plat d’architecture TV/réseau avant ouverture ? Contactez Domocasa pour cadrer une approche adaptée à votre hôtel.