---
title: Réserves
url: https://doc2.pstreamer.tv/fr/manual/webui/reserves.html
lang: fr
product: Perfect Streamer
version: 2.0.2.423
---

# Réserves

> **Important**
>
> **Version bêta 2.1.** Ce qui est décrit ici n’existe que dans la version bêta 2.1 : elle s’installe depuis le dépôt bêta et uniquement avec une licence ; la version stable 2.0.2 et la version de démonstration ne l’ont pas. La version bêta est fournie sans garantie, et l’assistance est assurée dans la mesure du possible ([Programme de test bêta](../extras/beta.md#extras-beta)).

La réserve Meshwork est une réserve à chaud des sorties multicast entre les nœuds d’un même domaine. Plusieurs nœuds reçoivent une seule et même source et maintiennent des sorties identiques vers une même adresse multicast et un même port ; un seul d’entre eux — l’émetteur élu — envoie à l’antenne vers cette adresse. Si l’émetteur tombe en panne ou est arrêté, un autre nœud reprend le groupe, et les récepteurs continuent de recevoir le flux depuis la même adresse, sans interruption ni répétition.

Outre les groupes multicast, la réserve Meshwork constitue des groupes OTT : la diffusion OTT d’une même chaîne sur différents nœuds (Groupes OTT).

L’état et les paramètres de la réserve de ce nœud sont regroupés sur l’écran « Réserves » de l’espace Meshwork ([Meshwork](meshwork.md#webui-fleet)). La version de démonstration n’a pas de réserve : l’élément de menu est indisponible.

## Groupes de réserve

Un groupe est formé par les sorties des nœuds du domaine qui envoient vers une même adresse multicast et un même port et dont le champ « Réserve Meshwork » est activé (bloc « Réserve Meshwork » de l’éditeur de sortie). Les membres peuvent être des sorties UDP, RTP et Pro-MPEG ([UDP, RTP, Pro-MPEG et TCP](io/network.md#webui-io-network)). Les sorties MPTS sont affichées dans le groupe, mais ne sont pas réservées.

Ce qu’il faut pour un groupe :

- la réserve est activée sur chaque nœud qui a un membre — champ « Réserve Meshwork » de l’onglet « Paramètres » de l’écran « Réserves », puis redémarrage du service ;
- les nœuds ont un nom de nœud et un domaine définis ([Paramètres du serveur](administration.md#webui-server-settings)), et tous sont dans un même domaine principal : avec les nœuds d’un autre domaine, aucune réserve ne se forme ;
- le port UDP du canal de contrôle (43975 par défaut) est ouvert entre les nœuds du domaine ;
- la sortie a une adresse multicast et une interface d’envoi, « Multicast egress interface » ;
- les flux des membres ont le même « Type de flux » et le même indicateur de chaîne embrouillée : c’est sur cette base que les nœuds comparent les sources.

Le canal de contrôle de la réserve est protégé par la clé du domaine Meshwork, elle doit donc être la même sur tous les membres. Les nœuds dont les clés diffèrent ne s’acceptent pas : dans le tableau des nœuds, cela apparaît comme « Échec d’authentification » et « Différente » dans la colonne « Clé ».

**Une seule source ou non.** Les nœuds comparent en continu les flux de leurs membres d’après les horodatages et le contenu. Le résultat s’affiche dans la colonne « Source » : « Même source », « Même signal » (mêmes horodatages, autre encodage), « Par libellé », « Horodatage propre », « Non prouvée », « Désembrouillage différent » ou « En attente » tant que les données sont peu nombreuses. Si l’entrée du flux pose elle-même les horodatages (fichier, RTMP, RTSP, transcodeur, multiplexeur MPTS), ils ne peuvent pas être comparés : définissez le même champ « Libellé de source de réserve » dans l’éditeur de flux sur tous les membres.

## Qui émet

Dans le mode par défaut — champ « Seul l’émetteur élu émet (reserve-gate) » de l’onglet « Paramètres », activé — seul le nœud élu émet dans chaque groupe, et les autres membres tiennent le flux prêt. Si ce champ est désactivé, la réserve fonctionne en mode observation : les membres sont vérifiés et affichés, mais tous émettent. Le champ est lu au démarrage du service ; définissez-le de la même façon sur tous les nœuds du domaine.

L’émetteur est élu par un vote des nœuds du domaine dont la réserve est activée. Après son démarrage, un nœud passe d’abord par une quarantaine : il ne vote pas et ne se porte pas candidat tant qu’il n’entend pas les votants (15 secondes au plus). Un groupe passe de lui-même à un autre membre lorsque :

- le nœud de l’émetteur ou son canal de contrôle cesse de répondre ;
- la sortie de l’émetteur cesse d’émettre ;
- l’entrée de l’émetteur s’est tue ou est passée sur une entrée de secours, et un autre membre a un meilleur flux.

Si la source a disparu chez tous les membres à la fois, le groupe ne bascule pas. Un nœud arrêté normalement cède d’abord ses groupes. Après des basculements fréquents, le basculement automatique du groupe est suspendu — le groupe est « gelé » (alerte de code 72, `reserve-frozen`, [Redondance des flux](../extras/alert_codes.md#extras-alert-codes-reserve)).

L’émetteur peut aussi être choisi à la main : bouton « Déplacer vers… » dans la ligne du groupe. L’émetteur actuel et le nouveau basculent au même instant de l’échelle de temps du groupe, sans interruption ni répétition ; la sortie du nouveau membre doit être ouverte et émettre. Le champ « Priorité de réserve » de la sortie (0–9, le plus élevé d’abord) définit le membre préféré, et « Rendre après (s) » le nombre de secondes pendant lesquelles un tel membre doit être prêt pour que le groupe revienne vers lui (0 — jamais : le groupe reste tant qu’on ne le déplace pas).

**Domaine de deux nœuds.** Lorsque seuls deux nœuds votent, un nœud redémarré ne reprend un groupe à l’autre que 30 secondes au plus tôt après son démarrage, et seulement si l’autre nœud a réellement disparu de Meshwork. Un troisième nœud dont la réserve est activée vote aussi et supprime cette attente ; il n’est pas nécessaire qu’il porte des membres.

Chaque basculement est inscrit dans le journal des événements du flux et visible sur la piste « Réserve » des graphiques de statistiques ([La piste « Réserve »](streams.md#webui-stream-stats-reserve)).

## Délai de sortie

Pour qu’un basculement soit transparent, les sorties de réserve envoient le flux avec un délai fixe par rapport à l’entrée — c’est l’échelle de temps du groupe. Elle est définie par le champ « Délai de sortie (ms) » de l’onglet « Paramètres » : de 500 à 2500, 500 par défaut. Définissez la même valeur sur tous les membres du groupe.

Une nouvelle valeur s’applique à une sortie lorsqu’elle s’ouvre à nouveau : au démarrage ou après une pause de la sortie de quelques secondes suivie d’un redémarrage. Une sortie en marche continue avec l’ancien délai, et l’écran « Réserves » indique quelle valeur s’appliquera. Si un membre de réserve est en retard sur l’émetteur, l’émetteur décale lui-même l’échelle de temps du groupe plus tard — de 300 ms au plus au-delà du délai défini et pas au-delà de 2500 ms ; quand le retard disparaît, le délai revient par pas de 5 ms toutes les 5 secondes.

## Second chemin et Pro-MPEG

Un membre doté d’une sortie RTP ou Pro-MPEG peut aussi envoyer un second chemin selon SMPTE ST 2022-7 ([Exigences réseau pour ST 2022-7](../planning/st2022_7.md#planning-st2022-7)). L’émetteur du groupe envoie les deux chemins. Définissez le second chemin de la même façon sur tous les membres, y compris « Path 2 multicast egress interface » : les nœuds surveillent aussi l’émetteur sur le second chemin. Si le second chemin d’un membre diffère, le groupe affiche le problème « Chemin 2 différent entre les membres » — un basculement vers ce membre déplacera ou supprimera le second chemin chez les récepteurs.

Si l’entrée du flux reçoit elle-même deux chemins, le délai de sortie doit être au moins égal à la fenêtre d’attente du second chemin (« Path skew (ms) » de l’entrée) plus 400 ms. Sinon, un basculement lors d’une vraie perte de l’entrée ne sera pas transparent, et le groupe affiche le problème « Délai de réserve plus court que l’attente de fusion ».

Une sortie Pro-MPEG ne participe au choix de l’émetteur qu’avec une matrice FEC déterminée et sans multiplexage ni phrase secrète ([sortie Pro-MPEG dans un groupe de réserve](io/network.md#webui-io-prompeg-reserve)).

## Groupes OTT

Un groupe OTT réunit la diffusion OTT (HLS, LL-HLS, DASH) d’une même chaîne sur différents nœuds du domaine : des flux ou des ensembles adaptatifs portant le même nom de groupe. Les membres se trouvent et se vérifient mutuellement, et un spectateur HLS dont le nœud est défaillant continue de regarder depuis un autre membre sans quitter le lecteur (Bascule des spectateurs vers un autre nœud).

**Comment l’activer.** La réserve Meshwork doit être activée sur le nœud (Groupes de réserve). Ensuite, pour un flux, dans l’onglet « Flux » de l’éditeur, bloc « Réserve Meshwork », ou dans la fenêtre d’un ensemble adaptatif, activez le champ « Réserve OTT » et renseignez « Nom du groupe de réserve » :

- jusqu’à 64 caractères `A-Z a-z 0-9 _ . -`, sensible à la casse ; le même nom sur tous les nœuds qui diffusent la chaîne ;
- champ vide : le nom OTT sert de nom de groupe, « Nom du flux dans l’URL » pour un flux, « Nom OTT » pour un ensemble. Sans aucun de ces deux noms, le membre n’est pas annoncé aux autres nœuds ;
- une modification s’applique en moins d’une seconde et ne redémarre pas la diffusion OTT du flux.

Seul un flux SPTS dont la diffusion OTT est activée peut être membre ; pour un flux MPTS, le champ n’a pas d’effet. Un ensemble adaptatif est un seul membre, et ses paliers sont les flux de l’ensemble qui portent de la vidéo. Les sources des flux sont comparées comme dans les groupes multicast : « Type de flux » et « Chaîne embrouillée » doivent donc être identiques chez les membres ; les ensembles adaptatifs sont appariés par leur nom. Pour que les autres nœuds joignent le serveur OTT de ce nœud par un nom, renseignez le « Nom d’hôte » du serveur HTTP ([Serveur HTTP de diffusion](administration.md#webui-http-server)) : sans lui, les autres nœuds reçoivent l’adresse du nœud, et seulement en HTTP si le certificat du nœud n’est pas émis pour cette adresse.

**La carte du groupe OTT**, dans l’onglet « État », affiche le nom du groupe, les formats qu’il sert (« Sert : … »), l’état, le résultat de la comparaison des sources et les problèmes. États :

- « Secouru » : un membre sur un autre nœud peut remplacer celui-ci ;
- « Non protégé » : d’autres nœuds ont des membres, mais aucun ne peut remplacer celui-ci ;
- « Clé en attente » : le nœud n’a pas encore de clé de domaine convenue ;
- « Pas membre » : la réserve OTT est activée, mais le flux ou l’ensemble n’y participe pas : pas de nom de groupe, un nom invalide, un flux MPTS ou pas encore de domaine ; la raison figure dans les problèmes ;
- « Nom en double » : deux flux ou ensembles de ce nœud ont le même nom de groupe, et aucun des deux n’est annoncé.

Pour chaque membre, la carte indique : « Secours », soit « Peut secourir », soit « Non proposé » avec la première vérification échouée ; « Bascule du spectateur », c’est-à-dire comment un spectateur passerait à ce membre (« Aligné », « Même chronologie » ou « Redémarrage ») ; « Live » et « Archive ». Un membre sur un nœud de version antérieure à 2.1.0.456 n’accepte pas de spectateurs : si les autres vérifications sont réussies, la colonne « Secours » indique « Sa version ne sait pas encore reprendre les spectateurs ». Si tous les membres des autres nœuds sont dans ce cas, le groupe reste sans protection.

Problèmes d’un groupe OTT :

| Problème | Signification |
| --- | --- |
| « Pas de nom de groupe » | Ni « Nom du groupe de réserve » ni nom OTT : le membre n’est pas annoncé. |
| « Nom de réserve invalide » | Un nom contenant des caractères non autorisés ou de plus de 64 caractères, lu dans le fichier de paramètres. Tant qu’il n’est pas corrigé, le flux n’est pas membre ; le nom OTT ne le remplace pas. |
| « Pas de secours sur un autre nœud » | Depuis 60 secondes, aucun membre d’un autre nœud ne peut remplacer celui-ci : les autres nœuds n’ont pas ce nom ou leurs membres échouent aux vérifications (détails dans la description du problème). Le nœud déclenche l’alerte de code 70 (`reserve-unprotected`). |
| « Formats OTT différents » | Les membres servent des formats OTT différents. |
| « Pas de nom d’hôte pour le serveur OTT » | Le « Nom d’hôte » du serveur HTTP n’est pas renseigné : les autres nœuds reçoivent l’adresse du nœud, et seulement en HTTP si le certificat du nœud n’est pas émis pour cette adresse. C’est une information, pas une erreur. |
| « Nom d’hôte du serveur OTT invalide » | Le « Nom d’hôte » du serveur HTTP n’est pas un nom d’hôte : le nœud ne communique pas aux autres nœuds l’adresse de son serveur OTT. |
| « L’horloge d’un nœud dérive trop » | L’horloge du nœud d’un autre membre s’écarte de plus de 240 secondes de celle de ce nœud : ce membre ne peut pas remplacer celui-ci. |
| « Pas encore de clé de visionnage » | Le nœud a un membre de réserve OTT, mais pas encore de clé de visionnage du domaine : les spectateurs de ce nœud ne basculent pas vers d’autres nœuds, et il n’accepte pas de spectateurs de secours. Au bout de 2 minutes, si la clé peut venir d’un autre nœud, le nœud déclenche l’alerte de code 78 (`reserve-view-key`). |
| « La clé de visionnage n’atteint pas ce nœud » | D’autres nœuds ont la clé, mais elle n’atteint pas ce nœud ; vérifiez la liaison entre les nœuds du domaine (alerte de code 78). |
| « Un nœud n’a pas pris la clé de visionnage » | Un nœud ayant un membre de réserve OTT ne confirme pas la clé active depuis 10 minutes (alerte de code 78). |
| « Trop de clés de visionnage » | Le nœud conserve plus de quatre clés de visionnage (alerte de code 78). |
| « Surchargé pour les spectateurs de secours » | Le nœud refuse les nouveaux spectateurs de secours : le CPU ou le réseau est au seuil, ou le « Plafond de sessions de secours » est atteint (Protection contre la surcharge). |
| « Les échelles de débit diffèrent » | Pour une partie des paliers de ce membre, le membre d’un autre nœud n’a pas de palier avec le même codec et un débit adapté : ces paliers n’ont pas de secours. Un membre dont aucun palier ne correspond pendant 60 secondes n’est pas proposé : la colonne « Secours » indique « Aucun de ses paliers ne correspond à ceux de ce nœud ». |
| « Un nœud n’a pas d’adresse https pour le secours » | Le nœud du membre ne communique pas l’adresse HTTPS de son serveur OTT : il n’est pas proposé comme secours aux spectateurs en HTTPS. Sur ce nœud, renseignez le « Nom d’hôte » du serveur HTTP pour lequel son certificat est émis. |
| « Un nœud n’a que des adresses privées pour le secours » | Le nœud du membre ne communique que des adresses privées : il n’est pas proposé comme secours aux spectateurs venant d’adresses publiques. |

## Bascule des spectateurs vers un autre nœud

Depuis la version 2.1.0.458, la playlist maître du HLS live d’un membre de groupe OTT désigne jusqu’à deux autres nœuds du groupe comme variantes de secours de chaque palier, après les siennes. Un lecteur qui prend en charge les variantes de secours passe de lui-même sur le nœud de secours lorsque le nœud du spectateur cesse de servir la fenêtre live ; le spectateur ne quitte pas le lecteur. Si le flux du nœud s’est arrêté ou figé alors que le secours est en direct, le nœud répond aussitôt à ce spectateur par `404` sur la playlist, et le lecteur bascule sans attendre ses propres délais d’attente. Les spectateurs d’un nœud défaillant se répartissent entre ses secours.

**Lecteurs.** Reçoivent des variantes de secours les lecteurs qui savent s’en servir : AVPlayer (Safari, iOS, tvOS), hls.js et les lecteurs similaires dans le navigateur, ExoPlayer et Media3. Les lecteurs qui ne savent pas basculer ainsi (VLC, mpv, Kodi, GStreamer, lecteurs basés sur ffmpeg, boîtiers décodeurs sans User-Agent) reçoivent une playlist maître sans lignes de secours et fonctionnent comme avant ; le nombre de playlists maîtres servies ainsi est indiqué par la ligne « Playlists maîtres sans secours » du bloc « Clé de visionnage OTT ». Ce que reçoit chaque lecteur et ce qui a été testé : [Lecteurs et réserve OTT/DVR](../extras/ott_players.md#extras-ott-players) ; ce qu’il faut prendre en compte pour le cache et le CDN : [8.1. Réserve OTT/DVR et CDN](../extras/ott_caching.md#extras-ott-cdn-reserve). L’application propre de l’opérateur peut demander les secours avec le paramètre `rsv=1` dans l’adresse de la playlist maître, ou les refuser avec le paramètre `rsv=0`.

Pour hls.js, définissez des délais d’attente courts pour le chargement de la playlist et du segment — environ une durée cible de segment, soit 2 à 3 secondes : le lecteur quitte alors rapidement un nœud figé.

**Quel nœud devient secours.** Un nœud n’est désigné comme secours que si son membre peut remplacer le membre de ce nœud (colonne « Secours » : « Peut secourir ») et si, au moment de la requête :

- il a servi récemment la fenêtre live et sert du HLS ;
- son horloge ne s’écarte pas de plus de 240 secondes de celle de ce nœud ;
- les nœuds ont une clé de visionnage commune (voir ci-dessous) ;
- le nœud n’est pas surchargé (Protection contre la surcharge) ;
- il a un palier avec le même codec ;
- le spectateur peut le joindre de la même façon : un spectateur en HTTPS a besoin d’une adresse HTTPS du nœud de secours, un spectateur sur une adresse publique, d’une adresse publique. Renseignez donc le « Nom d’hôte » du serveur HTTP sur chaque nœud ([Serveur HTTP de diffusion](administration.md#webui-http-server)).

**Clé de visionnage.** Le nœud de secours accepte le spectateur d’un autre nœud sur présentation d’un laissez-passer lié à la session du spectateur, à son nœud, au flux et à l’heure. Les laissez-passer sont signés par la clé de visionnage, commune aux nœuds du domaine ayant des membres de réserve OTT. Il n’y a rien à configurer : la clé est créée automatiquement, change tous les 7 jours et n’est conservée qu’en mémoire ; son état est affiché par le bloc « Clé de visionnage OTT » de l’onglet « État », et le bouton « Changer la clé de visionnage » la change manuellement. Si la clé n’atteint pas le nœud, celui-ci déclenche l’alerte de code 78 (`reserve-view-key`).

**Limites de cette version bêta.** Seuls reçoivent des variantes de secours les flux simples dont les membres sur les différents nœuds prennent la même source (bascule « Même chronologie »). Les ensembles adaptatifs, le LL-HLS et le DASH sont regroupés et affichés, mais n’ont pas encore de secours dans la playlist maître et le manifeste ; ces spectateurs ne sont protégés que par la redirection à l’ouverture (Redirection des spectateurs). Les sous-titres restent sur le nœud d’origine après la bascule. La playlist maître de l’archive et du catch-up ne désigne pas de secours : le spectateur obtient l’archive des autres nœuds par redirection.

## Redirection des spectateurs

Depuis la version 2.1.0.459, le nœud redirige le spectateur vers un autre nœud du groupe OTT (réponse `302`) dès l’ouverture de la playlist maître HLS et LL-HLS ou du manifeste DASH. La redirection n’exige aucune prise en charge de la part du lecteur : tous les lecteurs la suivent, y compris VLC et les boîtiers décodeurs, et pour DASH c’est la seule protection du direct dans cette version bêta. Elle fonctionne pour les flux et les ensembles adaptatifs dont la « Réserve OTT » est activée.

**Catch-up depuis l’archive des autres nœuds.** Si le spectateur demande une période passée absente de l’archive de ce nœud, le nœud l’envoie vers le nœud du groupe qui conserve la plus grande partie de la période ; la profondeur d’archive peut différer d’un nœud à l’autre. Si aucun nœud ne conserve la période, le spectateur reçoit `404` (`reserve: no recording for this period`), et non plus une playlist vide. Pour HLS, c’est l’archive MPEG-TS qui est prise en compte ; pour LL-HLS et DASH, l’archive fMP4.

Le passage à l’archive d’un autre nœud est choisi d’après la plage d’archive, de l’enregistrement le plus ancien au plus récent. Si le début de la période demandée tombe dans la plage d’archive de ce nœud, c’est ce nœud qui sert le spectateur, même si son archive présente un trou à ce moment-là (par exemple pendant que l’entrée ne fonctionnait pas) : les trous à l’intérieur de la plage ne sont pas renvoyés vers un autre nœud.

**Nouveaux spectateurs d’un flux qui ne fonctionne pas ici.** Un spectateur qui ouvre un flux qui ne fonctionne pas sur ce nœud — arrêté ou en pause, en erreur, avec une entrée tombée ou encore sans image — est envoyé par le nœud vers un nœud où ce flux est en direct. Un flux qui est seulement en train de démarrer n’est pas concerné : dès qu’un segment apparaît dans sa fenêtre live, c’est ce nœud qui sert les spectateurs. Un nœud redémarré avec un flux en pause ne redirige pas les nouveaux spectateurs tant que le flux n’a pas fonctionné au moins une fois.

**L’identifiant d’abord.** Pour les flux dont la « Réserve OTT » est activée, l’identifiant du spectateur est vérifié avant tout : avec un mot de passe erroné, la réponse est toujours `403`, même si le flux ne fonctionne pas. Les autres flux répondent comme avant.

**Limite de connexions.** Le champ « Connexions max, HTTP/HLS » de l’identifiant ([Utilisateur : ajout et modification](configure.md#webui-user-editor)) s’applique sur chaque nœud séparément : un abonné redirigé peut ouvrir autant de sessions sur l’autre nœud aussi.

Le nœud est choisi de la même façon que le secours pour la bascule (Bascule des spectateurs vers un autre nœud), mais le lecteur et le niveau de bascule ne sont pas vérifiés ; les ensembles adaptatifs et le LL-HLS conviennent donc aussi. Le réseau du spectateur n’est pas pris en compte lors du choix du nœud pour le catch-up : l’autre nœud doit être joignable par le spectateur de la même façon — en HTTPS, il faut une adresse HTTPS.

## Protection contre la surcharge

Un nœud de secours n’accepte un nouveau spectateur d’un autre nœud (spectateur de secours) que tant qu’il dispose d’une marge : la charge CPU de l’hôte et celle de l’interface réseau sont inférieures aux seuils d’erreur de ces ressources dans les paramètres des alertes ([Alerteur](administration.md#webui-alerter)), et le nombre de sessions de secours n’a pas atteint le « Plafond de sessions de secours » de l’onglet « Paramètres » (0 — sans limite, appliqué immédiatement). Un seuil à 0 désactive sa vérification. Le nœud ne refuse jamais ses propres spectateurs ni les sessions de secours déjà ouvertes. Après un refus, le lecteur passe au secours suivant, et les autres nœuds cessent pour un temps de désigner le nœud surchargé comme secours.

Le bloc « Protection OTT contre la surcharge » de l’onglet « État » indique s’il y a une marge, les causes de surcharge, la marge de réseau et de sessions, les seuils, le nombre de sessions de secours et de refus. Tant que la cause persiste, les groupes OTT du nœud présentent le problème « Surchargé pour les spectateurs de secours ». Si le nœud refuse les nouveaux spectateurs de secours pendant 30 secondes d’affilée, il déclenche l’alerte de code 79 (`reserve-ott-overload`) ; l’alerte se ferme après 60 secondes sans refus.

## Écran « Réserves »

L’écran affiche les groupes dans lesquels ce nœud a un membre ; les autres nœuds affichent les leurs. Si la réserve est désactivée sur le nœud, l’écran explique comment l’activer et propose le lien « Ouvrir les paramètres ».

**Onglet « État ».**

- Les tuiles « Groupes », « Groupes avec problèmes », « Erreurs », « Avertissements », « Nœuds sur le canal » et « Groupes par état ».
- Le bloc « Canal de contrôle de ce nœud » : état du canal, horloges (« Synchronisée » ou « Non synchronisée »), empreinte de la clé, nœuds votants, quarantaine et « Temporisations » — reprise, fenêtre et délai ; les compteurs « Groupes OTT » et « Rapports non envoyés » (rapports qui ne tenaient pas dans un datagramme ou reportés au tour suivant).
- Le tableau « Nœuds » : une ligne par nœud du canal — « Canal », « Clé », « RTT, ms », « Décalage d’horloge, ms », « Perte, % », « Dernier contact » et « Version ».
- La liste « Groupes ». Pour chaque groupe : l’état, le rôle de ce nœud, l’émetteur et le numéro d’élection, les membres avec leur priorité, leur rôle, l’indicateur « Émet » et le résultat de la comparaison des sources, le bloc « Sortie de ce nœud » et la liste des problèmes. États du groupe : « Seul » (les autres membres ne se signalent pas), « En formation » (membres trouvés et en cours de vérification), « Divergence » (les membres ont un type de flux ou un indicateur de chaîne embrouillée différent) et « Conflit » (quelqu’un qui n’en fait pas partie envoie dans le groupe).

Rôle de ce nœud dans le groupe : « Émetteur », « En attente », « Candidat », « Seul », « Pas prêt », « Quarantaine », « Attend la clé du domaine », « Émetteur non confirmé », « Écarté », « Libéré », « Cède le rôle », « Reprend le rôle », « Non vérifié » ou « Aucun ».

Le bloc « Sortie de ce nœud » indique si la sortie est ouverte (« Ouverte : ce nœud émet » ou « Fermée : un autre membre émet »), si elle est alignée sur l’échelle de temps du groupe, la marge, le délai, le FEC de groupe d’une sortie Pro-MPEG et les compteurs de datagrammes. Les compteurs croissants de datagrammes en retard, de débordements et d’erreurs d’envoi sont mis en évidence ; un membre de réserve en retard est signalé : un basculement vers lui ne sera pas transparent.

**Onglet « Paramètres ».** Les champs « Réserve Meshwork », « Seul l’émetteur élu émet (reserve-gate) », « Port UDP du canal de contrôle » (1024–65535, 43975 par défaut), « Interface du canal de contrôle » (« Toutes les interfaces » par défaut), « Délai de sortie (ms) », « Rendre après (s) », « Plafond de sessions de secours » (Protection contre la surcharge) et « Interface témoin » (pour un nœud qui ne fait que voter ; pas encore utilisé dans cette version). L’activation de la réserve, le mode, le port et l’interface sont lus au démarrage du service : les modifications prennent effet après un redémarrage.

## Problèmes du groupe

| Problème | Signification |
| --- | --- |
| « Conflit d’adresse » | Une source qui n’en fait pas partie envoie dans le groupe (alerte de code 71, `reserve-address-conflict`). |
| « Deux émetteurs » | Deux membres envoient en même temps dans le groupe (alerte de code 67, `reserve-two-senders`). En mode observation, c’est un avertissement : tous y émettent. |
| « Paramètres différents » | Les membres ont un « Type de flux » ou un indicateur de chaîne embrouillée différent. |
| « Contenu contraire aux paramètres » | Le flux d’un membre ne correspond pas à ses paramètres : par exemple, il contient de la vidéo alors que le type de flux est « Audio uniquement ». Ce sont les paramètres qui priment. |
| « Source non prouvée identique » | La source d’un membre ne peut pas être appariée pendant 30 secondes (alerte de code 68, `reserve-source-mismatch`). |
| « Désembrouillage différent » | Les parties en clair des flux coïncident, mais pas le contenu : l’un des nœuds ne désembrouille pas. |
| « Horodatage propre, sans libellé de source » | L’entrée du membre pose elle-même les horodatages : définissez le même « Libellé de source de réserve ». |
| « Membre non vérifié » | Un nœud annonce un membre, mais ses rapports n’arrivent pas jusqu’à ce nœud. |
| « Deux sorties de ce nœud » | Deux sorties d’un même nœud envoient dans un même groupe. |
| « Interface de sortie multicast manquante » | La sortie membre n’a pas d’interface d’envoi définie. |
| « Ce nœud ne voit pas le groupe » | Ce nœud ne peut pas observer le groupe ; les détails figurent dans la description du problème. |
| « MPTS listé, non réservé » | Une sortie MPTS est affichée dans le groupe, mais n’est pas réservée. |
| « Entrée DVB, pas encore testée » | Le flux provient d’une entrée DVB. |
| « Chemin 2 différent entre les membres » | Le second chemin d’un membre va vers une autre adresse ou n’est pas défini. |
| « Délai de réserve plus court que l’attente de fusion » | Le délai de sortie est inférieur à la fenêtre d’attente du second chemin de l’entrée plus 400 ms. |
| « Membre ProMPEG sans porte : matrice ou packets » | La sortie Pro-MPEG ne participe pas au choix de l’émetteur : « colonnes × lignes » n’est pas une puissance de deux, ou un datagramme ne contient pas 7 paquets TS. Elle émet toujours, à côté de l’émetteur du groupe, et ne reprend pas le groupe. |
| « Membre ProMPEG sans porte : multiplexage ou phrase secrète » | Idem, pour une sortie avec multiplexage ou phrase secrète. |
| « Matrice FEC ProMPEG différente » | La matrice FEC d’un membre diffère, ou sa version ne la communique pas : un basculement vers lui change la matrice chez les récepteurs. |

Les alertes de réserve — codes 66 à 74, 78 et 79 — sont listées dans [Redondance des flux](../extras/alert_codes.md#extras-alert-codes-reserve).