Historique des versions

version 2.0.2.423

26.10.2026

  • Version de démonstration — édition gratuite destinée à l’évaluation technique, paquet pstreamer-demo : sans clé de protection ni activation, sans limite de durée, uniquement pour évaluation (utilisation commerciale interdite). Fonctionnalités et limites — Version de démonstration.

  • Version de démonstration : le champ DVR sans erreur — dans l’onglet « OTT » de l’éditeur de flux, après le choix du mode « OTT / HLS », l’erreur « Impossible de charger les stockages DVR » n’apparaît plus sous le champ « Stockage DVR » : le champ affiche seulement « Non disponible dans la démo » (Comparaison des éditions).

  • Mettez à jour les transcodeurs en même temps que le streamer — il faut pstreamer-tcnv 1.2.0.128, pstreamer-tcsw 1.2.0.127 et pstreamer-tcivpl 1.1.0.56 ou plus récents : un transcodeur d’une version antérieure peut s’arrêter brutalement à l’arrêt du service, et le logo sur le transcodeur logiciel exige la nouvelle version de tcsw. Après la mise à jour des transcodeurs, redémarrez le service (Fichiers et vérification de l’installation).

  • Démarrage automatique du service lors d’une mise à jour du paquet — la mise à jour du paquet rpm ne désactive plus le démarrage automatique du service pss et ne l’arrête plus : auparavant, après une telle mise à jour et un redémarrage du serveur, le streamer ne démarrait pas de lui-même. Désormais, y compris lors d’une mise à jour depuis 2.0.2.408, le démarrage automatique reste activé et un service en cours est redémarré sur la nouvelle version ; un service que l’administrateur a arrêté ou désactivé reste dans cet état. La mise à jour du paquet deb n’active plus un démarrage automatique désactivé par l’administrateur. L’utilisateur système pss n’est plus supprimé puis recréé lors d’une mise à jour. Si une installation rpm a été mise à jour auparavant, vérifiez le démarrage automatique avec systemctl is-enabled pss et, si la réponse est disabled, activez-le : sudo systemctl enable pss (Installation sur les systèmes de la famille RHEL).

  • Paramètres OTT, DVR et DRM sans interruption de la diffusion — l’enregistrement des paramètres OTT, DVR et DRM d’un flux en cours ne redémarre que la diffusion OTT et l’enregistrement de l’archive : les entrées et les sorties (UDP, SRT et autres) continuent de fonctionner sans interruption, et l’uptime du flux n’est pas remis à zéro. Auparavant, toute modification de ce type redémarrait toutes les entrées et sorties du flux, avec une brève coupure sur les sorties. La profondeur de l’archive et la durée cible des parties LL s’appliquent à chaud, sans redémarrage. Les paramètres qui modifient le flux de transport lui-même (nom du service, programme, filtres PID, corrections PAT/PMT/PCR, source EPG) redémarrent les entrées et les sorties, comme avant (OTT et DVR).

  • Clonage des flux — dans l’interface web, un flux ou plusieurs flux sélectionnés sont copiés avec leurs entrées et sorties : la copie est créée en pause, avec le suffixe -copy dans le nom, et le bilan énumère les ports et adresses identiques à ceux du flux d’origine (Clonage des flux).

  • Connexion à l’interface web sans fenêtre du navigateur — à l’ouverture de l’interface web depuis un autre ordinateur, le navigateur n’affiche plus sa propre fenêtre de connexion avant le formulaire de l’interface web. Une requête API vers un chemin /data/… portant l’en-tête X-Requested-With: XMLHttpRequest reçoit en cas de refus 401 sans défi Digest ; les scripts qui se connectent par Digest ne doivent pas envoyer cet en-tête (Connexion, Accès).

  • Assistant de réclamation dans l’interface web — tant qu’un flux SPTS présente une violation TR 101 290 active ou une dérive PCR, l’icône « Lettre IA » s’affiche dans la ligne du flux et dans la fenêtre des statistiques : elle ouvre une requête prête à l’emploi pour un chat IA, qui rédigera une lettre de réclamation au fournisseur. La requête n’est accessible qu’au rôle Admin, la lettre est toujours en anglais (le choix de la langue a été supprimé), et la requête ne reprend de la source que l’adresse de l’entrée, sans identifiants, mots de passe ni clés. Sans violation active, le nœud ne génère pas de requête (Assistant de réclamation).

  • Déplacement de l’image agrandie de la mosaïque — dans la fenêtre de l’image originale, l’image agrandie se déplace à la souris, bouton droit enfoncé, et sur téléphone et tablette elle se zoome en pinçant et se déplace du doigt (Image originale).

  • Nom OTT de l’ensemble adaptatif sans espaces — le champ « Nom OTT » d’un ensemble adaptatif n’accepte plus les espaces : ils empêchaient la lecture et l’export de la playlist. Le streamer les supprime aussi — lors de l’ajout et de la modification d’un ensemble via l’API et au chargement des paramètres (avec une entrée au journal) ; le nom nettoyé est écrit au prochain enregistrement. Si, une fois les espaces supprimés, les noms de deux ensembles coïncident, les paramètres sont tout de même chargés : le second nom n’est pas diffusé et un avertissement est écrit au journal (auparavant, de tels paramètres ne se chargeaient pas) (Ensemble adaptatif).

  • Export M3U : ensembles adaptatifs et DASH — les ensembles adaptatifs sont désormais aussi exportés dans la playlist : la playlist maître HLS et le manifeste DASH de l’ensemble, chacun tant qu’au moins un flux de l’ensemble le diffuse. L’option « Tous les actifs » ajoute après les flux tous les ensembles en fonctionnement, et le nouveau protocole DASH inclut les manifestes des ensembles et les flux en mode DASH. Auparavant, les ensembles sélectionnés ne pouvaient pas être exportés (Export et import M3U).

  • Logo dans l’image du transcodeur — un logo issu d’un fichier PNG peut être incrusté sur les sorties d’un transcodeur NVIDIA et du transcodeur logiciel (CPU) : chaque sortie a son propre fichier, sa position, son opacité et le flou de l’arrière-plan sous le logo. Le logo n’est pas mis à l’échelle ; l’interface web vérifie aussitôt s’il tient dans l’image de sortie et en affiche un aperçu à l’échelle. Les fichiers de logos sont téléversés dans l’interface web et conservés sur le nœud. Le backend d’un décodeur avec logo peut être basculé entre NVIDIA et logiciel ; à réglages de taille identiques, leur image peut différer de quelques pixels, et le logo doit tenir dans l’image du backend choisi. Intel n’a pas de logo (Logo dans l’image).

  • Arrêt et redémarrage rapides — les transcodeurs, les commandes externes des entrées et sorties std et la commande d’alerte se terminent avec le service, et pendant l’arrêt le nœud ne redémarre plus les transcodeurs. Auparavant, ils ne réagissaient pas au signal d’arrêt, et l’arrêt ou le redémarrage du service attendait que le système les termine de force, en général au bout d’environ 15 secondes.

  • Statistiques du transcodeur — la file du décodeur et la latence ne se figent plus après que le nœud a redémarré le transcodeur.

  • Alertes par groupes — l’écran « Alertes » regroupe par défaut les alertes en vigueur par nœud et par code, avec le nombre de lignes et la gravité la plus élevée dans l’en-tête du groupe ; les grands groupes s’ouvrent repliés. Les étiquettes « resync persistante » et « entrée de secours » distinguent les recommandations de resynchronisation et les erreurs des entrées de secours des pannes en cours. L’ancienne liste reste accessible par le sélecteur « Liste » (Alertes).

  • Alertes sans clignotement — une alerte sur les ressources du nœud (CPU, mémoire, réseau, GPU, mémoire vidéo du GPU, stockage DVR, threads de travail des adaptateurs DVB) n’est déclenchée que lorsque la valeur reste au-delà du seuil pendant 30 secondes, et se résout après 60 secondes sous le seuil. L’alerte d”erreurs du compteur de continuité d’un flux (code 15) n’est déclenchée que lorsque les pertes durent 30 secondes et se résout après 60 secondes sans pertes ; le niveau erreur est maintenu tant que le nombre d’erreurs ne descend pas sous la moitié du seuil. Auparavant, une charge qui franchissait le seuil dans un sens puis dans l’autre et des paquets perdus isolés produisaient des alertes qui apparaissaient et disparaissaient en quelques secondes. Les durées se définissent sur l’écran « Alerteur » (paramètres system-alert-raise-sec, system-alert-clear-sec, stream-cc-raise-sec et stream-cc-clear-sec de la section alerter) ; 0 rétablit le comportement antérieur (Paramètres de l’alerter).

  • Alerte de remplissage de la mémoire vidéo du GPU — une nouvelle alerte de code 64 pour chaque carte NVIDIA : un avertissement quand la mémoire vidéo est remplie à 85 %, une erreur à 95 % (ligne « Mémoire vidéo GPU » de l’écran « Alerteur », paramètres gpu-mem-warning-pct et gpu-mem-error-pct ; 0 désactive le niveau). Une carte dont la mémoire vidéo est pleine ne lance pas de nouveau canal de transcodeur, même si sa charge peut paraître normale. Cette alerte n’existe pas pour les GPU Intel. Les données du moniteur système (/data/sysmon) indiquent pour chaque carte NVIDIA la mémoire vidéo occupée et totale ainsi que le pourcentage de remplissage, et le moniteur système de l’interface web affiche une barre « Mémoire vidéo » ; l’ancienne barre « Mémoire » d’une carte NVIDIA s’appelle désormais « Bande passante mémoire ». Avec la réplication des alertes système, les nœuds de versions antérieures du même domaine affichent cette alerte sans nom tant qu’ils ne sont pas mis à jour (Catalogue des codes d’alerte).

  • Secours défaillant — en une seule alerte — la nouvelle alerte de code 65 (niveau « avertissement », une par flux) énumère les entrées en erreur pendant que le flux passe par une autre entrée. Ces entrées ne gardent plus leurs propres lignes de code 1, et le code 1 est désormais toujours critique : le flux a perdu sa source. Une destination externe reçoit la levée des lignes de code 1 et le déclenchement du code 65 au lieu de l’ancienne mise à jour « critique » → « erreur ». Elle se configure dans le bloc « Entrées de secours (code 65) » de l’écran « Alerteur » (Catalogue des codes d’alerte).

  • Alertes de resynchronisation plus discrètes — l’alerte de code 61 (rupture de PCR sans perte) est désormais informative et désactivée par défaut ; son seuil est une clé distincte stream-sync-absorbed-count. Les codes 58, 59 et 61 sont levés après deux heures sous le seuil au lieu de six heures sans le moindre événement, et la ligne de l’entrée que le flux a quittée est levée immédiatement. Les seuils et le nombre d’heures calmes se règlent dans le nouveau bloc « Resynchronisation d’entrée (codes 58, 59, 61) » de l’écran « Alerteur » (Catalogue des codes d’alerte).

  • L’alerte ACME se résout d’elle-même — l’alerte d’erreur d’émission de certificat due à un problème sur le nœud (pas de serveur HTTPS avec le nom d’hôte, port de validation HTTP-01 occupé, clé de compte) se résout après la première tentative qui franchit cette étape ; auparavant, elle subsistait jusqu’à la désactivation de l’émission automatique (Catalogue des codes d’alerte).

  • Alertes externes : déclenchement et résolution par paire — le seuil de sévérité minimale des canaux « Processus », Telegram et e-mail s’applique à l’incident, et non à chaque message. Un incident dont la gravité a atteint le seuil est signalé au moment de cette hausse, et la résolution arrive toujours lorsque le déclenchement a été signalé. Auparavant, lorsque la gravité changeait par rapport au seuil, une résolution arrivait sans déclenchement ou un déclenchement sans résolution (Quand le script est lancé).

  • Scripts d’alerte et stderr — la sortie d’erreur du script est lue pendant qu’il s’exécute : une sortie abondante sur stderr ne provoque plus d’expiration du délai, et un processus laissé en arrière-plan ne retarde pas les alertes suivantes. Seul un code de sortie non nul est considéré comme un échec de livraison ; les 4 derniers Ko de stderr sont écrits dans le journal (Résultat, délai d’expiration et journal).

  • Meshwork : protection des échanges entre nœuds — un nœud vérifie que la réponse d’un voisin est signée avec le même secret ou la même clé de domaine, c’est-à-dire qu’elle provient d’un véritable participant du réseau, et refuse un message d’un voisin enregistré auparavant et renvoyé, ainsi qu’un message adressé à un autre nœud. La clé du domaine est transmise chiffrée : un échange enregistré et rejoué plus tard ne l’obtient pas. Auparavant, quiconque répondait à la connexion (liaison interceptée en HTTP ou en TLS sans vérification du certificat) pouvait substituer les données des nœuds, les sessions de connexion et la clé du domaine. Aucune configuration n’est nécessaire (Voisins et secrets).

  • Meshwork : les horloges des nœuds doivent être synchronisées — un nœud dont l’horloge s’écarte de celle d’un voisin de plus de 5 minutes est refusé par ce voisin, et la liaison est affichée comme indisponible. Les deux nœuds écrivent dans le journal un avertissement avec le nom du voisin et la valeur de l’écart ; le premier avertissement apparaît dès la moitié de la tolérance. La tolérance est définie par un nouveau paramètre facultatif, cluster-hello-window-sec (300 secondes par défaut, 0–86400) ; 0 désactive la vérification des horloges pour les nœuds dont les horloges ne peuvent pas être synchronisées, et les messages rejoués sont refusés même dans ce cas. Avant la mise à jour, vérifiez que NTP fonctionne sur tous les nœuds (Prérequis et joignabilité).

  • Mise à jour et retour en arrière de Meshwork — si possible, mettez à jour tous les nœuds du domaine en même temps. Si ce n’est pas possible, mettez d’abord à jour les nœuds auxquels les autres se connectent (nœuds centraux et nœuds à adresse publique), puis les nœuds derrière un NAT. Tant que des nœuds de versions différentes fonctionnent dans le domaine, l’échange de données est limité, et les messages des nœuds de versions antérieures peuvent encore être rejoués. Un nœud ramené à une version antérieure est refusé par ses voisins en nouvelle version jusqu’à leur redémarrage : revenez en arrière sur le domaine entier, ou redémarrez les nœuds en nouvelle version après le retour en arrière (Mise à jour des nœuds du domaine).

  • Plus de calme lors des redémarrages planifiés des nœuds Meshwork — l’alerte de nœud inactif (code 26) est déclenchée après une minute de silence et non plus après 15 secondes, de sorte qu’un redémarrage rapide d’un voisin ne réveille pas tout le domaine. Un nœud que l’on arrête ou redémarre volontairement prévient d’abord ses voisins (les nœuds de versions antérieures ne reçoivent pas l’avis), qui ne déclenchent pas d’alerte pour lui pendant 5 minutes, tandis que le tableau des nœuds l’affiche comme « Redémarrage (N s) ». Les durées se définissent par les champs du bloc « Contact Meshwork (avancé) » des paramètres du serveur (paramètres cluster-node-down-sec et cluster-leave-grace-sec de la section cluster, Catalogue des codes d’alerte). Corrigé : un nœud pouvait s’afficher deux fois dans le réseau et répéter ses propres alertes comme si elles venaient d’un voisin.

  • Modification des réglages Meshwork — l’enregistrement des réglages ne retire plus les nœuds découverts automatiquement de la carte du réseau et ne lève plus par erreur leurs alertes « un nœud du réseau s’est tu » (Catalogue des codes d’alerte).

  • Connexion automatique depuis un autre nœud du domaine — une session de connexion automatique venue d’un autre nœud du domaine reçoit le rôle Viewer sur un nœud où ce compte n’existe pas. Si le compte existe sur le nœud, c’est son rôle qui s’applique, comme auparavant (Serveur web et comptes).

  • Facturation externe et nœuds voisins — les serveurs de facturation ne reçoivent plus la demande de connexion d’un nœud Meshwork voisin que le nœud a déjà refusée lui-même.

  • Secrets dans les réponses de l’API et leur réécriture — la réponse à l’ajout ou à la modification d’un enregistrement via l’API (POST vers /config/…) ne reprend plus les mots de passe ni les autres secrets, y compris pour le rôle Admin : ils arrivent sous la forme ******** ; la lecture des paramètres (GET) n’a pas changé. Un secret ou une ligne de commande transmis à l’écriture sous la forme ******** conserve la valeur enregistrée, tout comme une adresse masquée avec la trace <hidden> : la réponse reçue peut être renvoyée sans perdre les mots de passe. ******** lui-même ne peut plus servir de mot de passe (Pilotage via l’API HTTP).

  • Adresses dans les réponses pour les rôles Viewer et Restricted admin — dans le flux d’événements /data/events (adresse de l’entrée active du flux et textes d’erreur), dans les textes d’événements de /data/dbstat et dans le motif reason de /data/cert/acme/status, les identifiants, mots de passe et paramètres secrets des adresses sont masqués, comme dans le XML de /data. Rien ne change pour le rôle Admin.

  • Une modification refusée des paramètres ne change rien — si le nœud refuse une modification d’un flux, d’une entrée, d’une sortie ou des paramètres du serveur (par exemple un nom de nœud invalide), l’objet reste tel qu’il était. Auparavant, les clés appliquées avant le refus restaient en vigueur jusqu’au redémarrage (Comment arrivent les erreurs).

  • Statistiques de la base sans les tables absentes — la requête /data/dbstat avec le paramètre missing=skip ignore les tables qui n’existent pas au lieu de rejeter toute la requête.

  • Fichiers de configuration fermés à la lecture — pss.json et ses copies de sauvegarde ne sont lisibles que par l’utilisateur du service. L’exportateur de métriques pss-metrics, lancé sous un autre utilisateur, se connecte au port 43971 ; si le serveur web utilise un autre port, définissez PSS_URL, y compris dans le fichier /etc/pss-metrics.conf. Corrigé : l’exportateur se connectait au port 8808 si aucun port de serveur web n’était défini dans pss.json, et ne tenait pas compte de PSS_URL de ce fichier (Fichiers et services, Configuration).

  • Comptes par adresse IP et clients IPv6 — la connexion d’un client en IPv6 ne provoque plus d’erreur lors de la vérification des comptes par adresse IP : un tel client ne correspond simplement à aucune adresse IPv4 (Utilisateurs / Identifiants).

  • Flux autorisés d’un identifiant local — un identifiant dont aucun des flux de la liste « Flux autorisés » n’existe plus au démarrage du nœud n’obtient aucun flux. Auparavant, un tel identifiant pouvait regarder tous les flux (Utilisateurs / Identifiants).

  • Activation et désactivation du serveur EPG — « Activer le serveur EPG » gère désormais les deux ports, HTTP et HTTPS, et agit immédiatement, sans redémarrage : un serveur désactivé n’ouvre aucun port. Auparavant, un serveur désactivé occupait quand même ses ports au démarrage du service (les connexions restaient bloquées), la désactivation à chaud redémarrait le port HTTP, et le port HTTPS ignorait l’indicateur (Distribution XMLTV).

  • Export EPG complet avec les données d’association — le nouveau chemin /xmltv-src du serveur EPG (et /xmltv-src.gz) fournit les chaînes de toutes les sources ou des sources choisies avec les données permettant d’associer les chaînes diffusées : le numéro et le nom de la source, l’identifiant de la chaîne dans le fichier XMLTV ; on peut n’exporter que le catalogue des chaînes ou ajouter des jours passés. Accès — pour un compte du serveur EPG doté de l’indicateur « Toutes les chaînes sur /xmltv-src » (all-channels) ou depuis le nœud lui-même (Export complet avec les données d’association, Paramètres EPG).

  • Classification par âge dans le programme des émissions — le programme quotidien d’une chaîne en JSON pour le middleware OTT fournit la classification par âge de l’émission (l’âge et le système de classification, par exemple 16+), issue du fichier XMLTV ou de la classification parentale DVB EIT ; dans le programme de la chaîne de l’interface web, elle est affichée sous forme de badge (Programme quotidien en JSON, Base de données EPG).

  • Sous-titre de l’émission dans un champ distinct — le sous-titre du fichier XMLTV (<sub-title>, par exemple le titre de l’épisode) dans la langue du titre ou sans langue indiquée est fourni dans le programme quotidien d’une chaîne en JSON dans un champ sub distinct, et dans l’export complet /xmltv-src dans un élément <sub-title> ; le titre de l’émission y est sans sous-titre. La distribution habituelle /xmltv ne change pas. Les sous-titres apparaissent après la prochaine mise à jour de chaque source (Programme quotidien en JSON).

  • Téléchargement EPG tour à tour — les gros fichiers XMLTV sont téléchargés et traités un par un, les autres attendent dans la file, et au démarrage du service les téléchargements sont étalés dans le temps : le pic de mémoire au redémarrage avec plusieurs gros fichiers est celui d’un seul fichier. Un téléchargement échoué est retenté au bout de 2, 5 et 15 minutes, puis toutes les 30 minutes, et non après l’intervalle de mise à jour complet. Dans l’interface web, une source en file d’attente est marquée, et l’onglet « État des sources » affiche les champs « Prochaine tentative » et « Téléchargements échoués d’affilée » (File de téléchargement et nouvelles tentatives, Base de données EPG).

  • Délai de téléchargement d’une source EPG — le nouveau paramètre de source « Délai de téléchargement, s » (fetch-timeout) pour les sources lentes qui constituent le fichier à la demande ; 30 secondes par défaut, comme auparavant (Configuration des sources).

  • Sources EPG — lors d’une modification, « URL / chemin de la source » doit être une adresse http ou https ou un chemin absolu vers un fichier, sinon la modification est refusée. Les Cookies de la source sont désormais réellement transmis — dans l’en-tête standard Cookie et uniquement à l’hôte configuré ; auparavant, l’en-tête s’appelait Cookies, et les serveurs n’en tenaient pas compte. Après la modification d’une source activée (par exemple de son adresse), les données sont chargées immédiatement, et non à l’expiration de l’intervalle de mise à jour (Configuration des sources).

  • Suppression d’un ensemble de chaînes EPG — le contenu d’un ensemble est supprimé avec l’ensemble, et seulement si la suppression a abouti. Auparavant, le contenu d’un ensemble sans compte restait dans la base, et la suppression refusée d’un ensemble attribué à un compte pouvait effacer son contenu.

  • EPG : émissions à cheval sur minuit — une émission qui passe minuit (UTC) s’affiche dans les deux journées du programme, et son repère dans la playlist OTT est trouvé aussi après minuit. Auparavant, une telle émission disparaissait des deux journées.

  • Corrigé : dans l’export /xmltv, une émission pouvait se répéter si deux sources fournissent une chaîne de même identifiant ; le programme des émissions issu de l’EIT des flux affiche aussitôt une émission modifiée, et non son ancien texte ou son ancienne classification.

  • Corrigé : « Nettoyage automatique des chaînes orphelines » pouvait supprimer les chaînes d’une source EPG dont le fichier XMLTV n’avait pas changé ; les modifications du programme dans les sources externes sont désormais reconnues de façon plus fiable, et les modifications des noms de chaînes faites dans l’interface web sont conservées (Base de données EPG).

  • EIT — le service ne s’arrête plus de façon anormale lors de la génération de l”EIT depuis XMLTV lorsqu’un événement a deux classifications par âge ou plus, ou une longue description en polonais, tchèque, hongrois, croate ou bosniaque : un texte trop long est réparti sur plusieurs descripteurs. Une description longue en cyrillique et dans d’autres alphabets non latins n’est plus découpée en fragments d’un octet, la numérotation des descripteurs est correcte, et un événement à description longue conserve sa classification par âge (Générateur EIT).

  • NIT — le nœud suit la version de la NIT y compris après une réinitialisation (auparavant, la liste des numéros logiques de chaînes pouvait rester vide) et n’applique que la NIT de son propre réseau (actual).

  • Type de service automatique — avec Service type 0, un programme H.264 est considéré comme HD (type 0x19) à partir du niveau 3.1. Auparavant, le seuil était le niveau 3.0, et le SD 576i/480i de ce niveau était marqué comme HD ; il est désormais SD (0x16) (Paramètres des programmes).

  • Réception multicast sur l’interface de bouclage — une entrée UDP ou RTP avec l’interface lo ou 127.0.0.1 rejoint le groupe multicast uniquement sur l’interface de bouclage et reçoit le groupe émis sur ce même nœud. Auparavant, l’entrée rejoignait le groupe sur l’interface externe et ne recevait rien. Pour recevoir un groupe depuis le réseau, indiquez une interface réseau ou laissez le champ vide (Entrée).

  • Réadhésion au groupe multicast — pour les entrées UDP, RTP et Pro-MPEG, la période de répétition est limitée à 3600 secondes : le nœud refuse une valeur supérieure et la ramène à 3600 au démarrage. Auparavant, une valeur supérieure à 4294 secondes faisait répéter la réadhésion en continu. Une tentative échouée est désormais répétée après la période, au lieu d’arrêter les répétitions jusqu’à la reconnexion de l’entrée ; une entrée Pro-MPEG se réabonne aussi aux flux FEC (Entrée).

  • Contrôle de l’adresse des entrées UDP et RTP — lors d’une modification, une adresse qui n’est pas une adresse IPv4 (par exemple 999.999.1.1) est refusée avec le message Incorrect IPv4 address. Les paramètres enregistrés auparavant ne sont pas revérifiés au démarrage (Entrée).

  • Entrée RIST multicast — rejoint le groupe sur l’interface de la colonne Interface ; auparavant, la route par défaut était toujours utilisée. Pour une sortie RIST multicast, l’interface reste sans effet : le trafic part par la route système vers le groupe (La liste des pairs).

  • RIST sans arrêts brutaux — un émetteur RIST dont la taille des blocs de données n’est pas un multiple de 188 octets n’arrête plus le service : ces blocs sont écartés, et le journal ne les signale pas plus d’une fois par minute. Le remplacement de toutes les entrées ou sorties d’un flux en une seule modification, alors qu’une entrée ou une sortie RIST fonctionne, ne provoque plus non plus l’arrêt brutal du service.

  • Entrée RTSP — lors d’un changement d’adresse, d’une pause, d’un basculement vers une entrée de secours ou d’une reconnexion, l’entrée ferme réellement la session précédente. Auparavant, elle pouvait continuer à recevoir le flux de l’ancienne source.

  • DVB : plus de coupures périodiques du flux — une lecture incomplète des données depuis le périphérique DVB n’entraîne plus le redémarrage de l’entrée ni un nouveau réglage du tuner, qui provoquaient des interruptions périodiques des flux DVB-T/S (Récepteur DVB).

  • Destinataire lent des sorties file, pipe et std — si le destinataire prend durablement du retard sur le flux, la sortie passe en erreur Output queue full et redémarre, comme les sorties des autres types ; les données transmises restent dans l’ordre. Auparavant, dans cette situation, des paquets TS étaient perdus et réordonnés sans aucun signalement (Applications externes (std)).

  • Sortie std avec un stderr abondant — une application qui écrit beaucoup sur stderr ne se bloque plus après 64 Ko de sortie et ne redémarre plus en boucle. En cas d’échec, la fin de son stderr figure dans le texte de l’erreur (Applications externes (std)).

  • Tables endommagées dans le flux d’entrée — le nœud écarte les sections PAT, PMT, CAT, NIT, EIT et TOT endommagées ainsi que les descripteurs qu’elles contiennent ; elles ne peuvent plus provoquer l’arrêt anormal du service.

  • Marque ESCR dans les PES — les flux dont les en-têtes PES portent la marque ESCR sont analysés correctement ; auparavant, leur analyse s’interrompait sur une erreur.

  • Ajout d’un flux avec transcodeur — l’ajout d’un flux dont l’entrée transcoder est raccordée à un décodeur déjà en fonctionnement n’entraîne plus l’arrêt anormal du service (Raccordement).

  • HTTP/3 : réponses en flux transmises intactes — en HTTP/3, le MPEG-TS over HTTP (/http/) et les parties LL-DASH en direct sont transmis entiers, comme en HTTP/1.1. Auparavant, le corps d’une telle réponse arrivait endommagé : il ne commençait pas sur une frontière de paquet TS, des fragments disparaissaient ou se répétaient, et les lecteurs perdaient la synchronisation. Les segments HLS et DASH et les autres fichiers n’étaient pas touchés (HTTP/3 (QUIC)).

  • OTT — la diffusion DASH et LL-HLS reprend après un changement du PID vidéo dans le flux (auparavant, seulement après un redémarrage d’OTT) ; la diffusion MPEG-TS over HTTP ne réinitialise plus l’entrée lors d’un ralentissement passager du disque DVR.

  • La suppression d’une entrée ou d’une sortie n’arrête plus l’enregistrement DVR — après la suppression d’une entrée ou d’une sortie d’un flux, l’archive DVR continue d’être enregistrée. Auparavant, l’enregistrement s’arrêtait jusqu’à la modification suivante des paramètres OTT du flux.

  • DVR : enregistrement d’index endommagé — si un seul enregistrement de l’index de l’archive est endommagé (par exemple après une coupure de courant), le nœud l’ignore et charge le reste de l’archive ; seul ce fragment est perdu. Auparavant, tout ce qui avait été enregistré après lui disparaissait de l’archive à chaque redémarrage, puis les fichiers étaient supprimés (Stockages DVR).

  • DVR : nettoyage des archives MP4 — en cas de dépassement de la limite d’utilisation du disque, les segments les plus anciens des archives MP4 (DASH et LL-HLS) sont eux aussi supprimés. Auparavant, seule l’archive TS était nettoyée, et un disque ne contenant que des archives MP4 restait saturé.

  • DVR : sous-titres — l’archive des sous-titres WebVTT est conservée au redémarrage ; auparavant, elle était perdue (Sous-titres WebVTT).

  • DVR : espace libre d’urgence — le champ « Espace libre d’urgence, GiB » des stockages DVR n’a jamais eu et n’a toujours aucun effet sur le fonctionnement : la valeur est enregistrée, mais l’enregistrement n’est pas arrêté en fonction de l’espace libre. Le champ est désormais décrit comme réservé ; c’est le nettoyage par espace qui maintient le disque dans la limite, sans toucher à l’archive plus récente que le minimum protégé (Stockages DVR).

  • Autres améliorations et corrections de bogues.

version 2.0.2.408

19.10.2026

  • Un disque DVR défaillant n’arrête pas la diffusion en direct — un disque DVR plein, en lecture seule ou défaillant n’arrête plus la diffusion en direct d’un flux en HLS et DASH. Auparavant, une erreur d’écriture de l’archive, sans entrée dans le journal, arrêtait à la fois la diffusion en direct et l’archive jusqu’au redémarrage, et effacer l’archive n’y changeait rien. Désormais, le journal signale le début et la fin d’un échec d’écriture, et une fois la panne réparée, l’archive est de nouveau écrite, y compris après l’effacement de l’archive du flux (Statistiques du flux). Il en va de même pour l’archive des sous-titres.

  • La modification des réglages ne bloque pas l’API — la modification d’un flux (un paramètre, une sortie, la suppression du flux) ne peut plus rester bloquée lorsqu’une entrée est tombée ou inactive, ni sous charge. Auparavant, toutes les requêtes de configuration et la liste des flux dans l’interface web cessaient de répondre en même temps.

  • Enregistrement des réglages sans perte — une modification effectuée juste avant un arrêt normal ou un redémarrage du service n’est plus perdue ; une écriture échouée du fichier de configuration est retentée toutes les 10 secondes, et le journal en indique la cause ; une modification effectuée avant le redémarrage automatique après une restauration depuis une sauvegarde n’écrase plus la configuration restaurée.

  • Reconnexion des entrées et des sorties — après une nouvelle tentative de connexion, une entrée ou une sortie ne peut plus rester bloquée dans une tentative de démarrage sans avoir rien ouvert, jusqu’au redémarrage du service ou à une modification des réglages. Cela arrivait le plus souvent avec une entrée SRT en mode listener ; PS1, RTMP/RTMPS, RTSP, l’entrée HLS, TCP et le transcodeur étaient également concernés.

  • SRT : une phrase secrète erronée ne bloque pas l’entrée — les appelants qui se connectent encore et encore à un port SRT en mode listener avec une phrase secrète erronée, ou sans phrase secrète, n’occupent plus toutes les places de connexion : un émetteur disposant de la bonne phrase secrète se connecte immédiatement.

  • Dépôt de paquets en HTTPS et signé — le dépôt fonctionne en HTTPS, les paquets et les métadonnées sont signés avec la clé du dépôt. Les nouvelles commandes pour l’ajouter figurent dans Installation sur les systèmes de la famille RHEL et Installation sur les systèmes de la famille Debian ; un dépôt ajouté auparavant continue de fonctionner.

  • Création d’un flux avec une valeur invalide — une requête de création de flux via l’API HTTP avec une valeur de paramètre invalide est refusée dans son ensemble, et aucun flux n’est créé. Auparavant, la valeur était ignorée et le flux était créé (Comment arrivent les erreurs).

  • L’ordre de la clé ``mpts`` n’a pas d’importance — mpts est appliquée avant les autres clés d’une entrée de flux, où qu’elle se trouve. Les paramètres OTT et les autres réglages d’un flux à programme unique transmis lors de la création d’un flux via l’API HTTP sans mpts, ou écrits dans le fichier de configuration au-dessus d’elle, ne sont plus perdus (L’ordre des clés à l’intérieur d’un objet compte).

  • SIGHUP est un arrêt normal — le signal SIGHUP arrête le service de la même manière que SIGTERM : les flux sont arrêtés et la dernière modification des réglages est enregistrée. Auparavant, le processus se terminait immédiatement.

  • Entrée Pro-MPEG dans le catalogue Meshwork — une entrée Pro-MPEG qui reçoit un groupe multicast est annoncée dans le catalogue des ressources partagé du domaine de la même manière que les entrées UDP et RTP (Catalogue commun des ressources).

  • Autres améliorations et corrections de bogues.

version 2.0.2.399

01.10.2026

  • Tampon T-STD : métrique uniquement — le modèle du tampon vidéo produisait de fausses alertes sur des flux sains ; son indicateur reste donc dans les statistiques à des fins de diagnostic, mais ne déclenche plus d”alarme (code 11) et n’entre pas dans le verdict global TR 101 290 (code 49) (Catalogue des codes d’alerte).

  • OTT sans bourrage CBR — les paquets NULL qui complètent le flux jusqu’au débit constant ne sont remis à aucun client OTT, y compris lors d’une diffusion HTTP sans segmenteur. Le débit constant n’est conservé que sur les sorties de transport — UDP, SRT, PS1, RIST.

  • Parties LL-HLS calées sur les images clés — chaque IDR ouvre une nouvelle partie marquée INDEPENDENT ; un lecteur qui se connecte au bord du direct trouve ainsi un point d’entrée en l’espace d’un seul GOP.

  • Nombreuses entrées HLS sur un nœud — les entrées HLS téléchargent les segments via un pool commun : une entrée ouverte ne mobilise plus ses propres threads de travail, et lorsque le pool est occupé, le téléchargement d’un segment est différé au lieu de redémarrer l’entrée.

  • Autres améliorations et corrections de bogues.

version 2.0.2.362

06.09.2026

  • Menu du module CI — le menu propre du module est lu : état de la carte, abonnements, numéro de série, saisie du PIN et entrées de service sont accessibles directement depuis l’écran matériel — la même chose que le module afficherait sur l’écran d’un téléviseur. La carte d’identité du module y est apparue également — fabricant, code produit et type d’application EN 50221 — et le nœud décode son nom, si bien que les noms cyrilliques n’arrivent plus déformés (Menu du module).

  • Désembrouillage par un module CI distinct — un module logé dans un lecteur de cartes autonome dessert n’importe quelle entrée d’un flux, et pas seulement la réception depuis une carte DVB : tout le transport de l’entrée le traverse, tandis que la liste des programmes indique seulement lesquels désembrouiller. Le slot est attribué sur l’entrée elle-même, et c’est là aussi que l’on voit quelle entrée l’occupe (CI/CAM sur une entrée de flux).

  • Plusieurs slots CI sur une même entrée — un multiplex est conduit successivement à travers plusieurs modules, avec son propre jeu de programmes pour chaque slot. La fréquence d’horloge du bus CI est choisie d’après le débit réel de l’entrée, et un slot resté occupé se libère sur demande depuis l’écran du matériel.

  • Tables de service lors du démultiplexage — les tables de réseau et d’heure ainsi que les autres PID de service du multiplex d’origine obéissent désormais aux mêmes clés mpegts-filter-nit, mpegts-filter-tdt, mpegts-filter-unnecessary et mpegts-filter-cat que sur les autres chemins, au lieu d’être écartées sans condition. La valeur par défaut a changé du même coup : un flux extrait d’un multiplex porte les tables de réseau et d’heure qu’il ne portait pas auparavant — un récepteur situé derrière un tel flux, et un module CI en premier lieu, s’attend à les voir. Le comportement antérieur se rétablit avec mpegts-filter-nit.

  • Une discontinuité PCR ne vide plus le tampon de gigue — une entrée ayant capté un saut de PCR en avant déplace le point de synchronisation à la volée, sans purger la file ; la discontinuité coûte donc un seul accroc au lieu d’un remplissage du tampon. La fenêtre au-delà de laquelle un saut compte comme une discontinuité est choisie automatiquement (Synchronisation).

  • Démarrage rapide d’une entrée HLS — une playlist en direct est reprise par la fin : seuls les derniers segments nécessaires à la gigue configurée entrent dans la file, et non toute la fenêtre ; l’entrée passe donc à l’antenne avec un retard de quelques segments au lieu d’une fenêtre de playlist entière. Une playlist achevée (VOD) est toujours lue depuis le début.

  • Suppression du battement des alertes — une alerte déclenchée et résolue encore et encore est repliée en un incident unique : le nœud la maintient pendant l’accalmie et ne la ferme que lorsque le battement a réellement cessé. Une tempête de répétitions ne se répand ni dans le journal ni par les canaux externes. Une source de battement une fois identifiée le reste après l’accalmie : sa série suivante est maintenue dès la première répétition.

  • Modification d’une chaîne EPG — une chaîne reçoit un identifiant XMLTV distinct du nom affiché ainsi que des libellés par langue, et une chaîne devenue inutile se supprime entièrement : ses libellés, ses événements et son appartenance à des ensembles disparaissent avec elle.

  • Autres améliorations et corrections de bogues.

version 2.0.2.335

27.08.2026

  • Meshwork (multidomaine) — plusieurs serveurs sont regroupés en domaines nommés, et le domaine sert de frontière d’isolation : l’appartenance des nœuds, le catalogue des ressources et les alertes ne se propagent qu’à l’intérieur de leur propre domaine, rien n’est transmis entre les domaines. Un nœud peut appartenir à plusieurs domaines à la fois sans mélanger leurs données. Pour plus de détails — Meshwork.

  • Découverte automatique des nœuds — il suffit de définir le domaine et un seul point d’entrée : les nœuds échangent des listes de voisins et construisent d’eux-mêmes un réseau maillé complet de liaisons directes. La clé de domaine commune est produite automatiquement et n’est transmise que par un canal protégé — TLS ou un segment de réseau local de confiance.

  • Bibliothèque de ressources répartie — les sorties UDP, RTP, Pro-MPEG et RIST, les entrées multicast UDP, RTP et RIST, ainsi que les liaisons PS1 et SRT sont publiées dans le catalogue commun du domaine (/data/library) : une liste unique des groupes multicast, des ports, des VLAN, des sources SSM et des liaisons point-à-point, avec indication du nœud et du flux. Le catalogue montre quelles adresses et quels ports sont déjà occupés, et une nouvelle entrée s’y raccorde directement — en choisissant un flux déjà diffusé sur un autre nœud du domaine, sans saisir l’adresse à la main.

  • Aperçu des nœuds du domaine — pour chaque nœud sont affichés l’état, l’heure du dernier contact, le rôle, la région, la version du build, le temps de fonctionnement depuis le démarrage, la charge CPU, le trafic par interface physique et le nombre de flux à l’antenne ; pour chaque liaison inter-nœuds PS1 ou SRT — le débit, le RTT, la part de retransmissions et de pertes et un verdict sur son état. Un nœud tombé ne disparaît pas de la liste : il y reste sept jours comme injoignable, avec son alerte, et un nœud mis hors service est retiré de l’aperçu par une commande dédiée.

  • Fonctionnement derrière un NAT — un nœud placé derrière un NAT participe pleinement au domaine et sans redirection des ports entrants : il se connecte lui-même, son point d’accès public est reconstitué à partir de l’adresse effectivement observée et du port annoncé, et son état est relayé par les voisins sur un saut — le nœud est visible même pour ceux qui ne peuvent pas s’adresser à lui directement.

  • Nom du nœud issu du certificat — un nœud dont le nom d’hôte n’est pas défini annonce à ses pairs le nom couvert par son propre certificat, et seulement après que ce nom se résout à nouveau vers lui ; le résultat du contrôle est visible dans les données du serveur sous cert-host et cert-host-refused.

  • Connexion automatique des liaisons à l’intérieur du domaine — les liaisons PS1 et SRT entre nœuds d’un même domaine ne demandent pas de créer un identifiant et un mot de passe pour chaque liaison : du côté appelant (entrée PS1, entrée SRT, sortie SRT en mode caller), il suffit d’activer le paramètre « Meshwork peer auth » et l’autorisation s’effectue au moyen du secret de domaine commun. Le nœud partenaire confirmé et son flux apparaissent dans la bibliothèque de ressources et dans la liste des sessions.

  • Low-Latency HLS et MPEG-DASH sur CMAF — nouveau mode de diffusion « OTT / LL-HLS / DASH » : le multiplexeur intégré produit du MP4 fragmenté (CMAF), au-dessus duquel MPEG-DASH est servi sur /dash et Low-Latency HLS sur /llhls ; les ensembles adaptatifs sont également constitués pour ces formats. Pour plus de détails — Modes de diffusion.

  • Faible latence LL-HLS — la playlist média est découpée en parts, le rechargement bloquant de la playlist et l’indication de préchargement sont mis en œuvre, de sorte que le lecteur démarre la lecture sans attendre qu’un segment complet soit prêt. Les segments CMAF portent le Producer Reference Time, le manifeste DASH annonce UTCTiming et la latence cible, et le paramètre « Durée cible de la part LL (ms) » est appliqué à chaud, sans redémarrer le flux.

  • HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS et MPEG-TS over HTTP sont diffusés sur QUIC sur un port UDP dédié, avec 0-RTT facultatif ; le client demande le passage à QUIC par le paramètre ?h3. QUIC ne fonctionne que sur TLS : TLS désactivé, l’écouteur n’est pas ouvert ni proposé au client, et son état réel est visible dans les données du serveur HTTP et non seulement dans le paramètre. Les routes d’administration restent uniquement en TCP.

  • Alignement des segments sur les IDR — le segmenteur distingue une image IDR d’une image I ordinaire : sur les sources à closed-GOP, chaque segment commence par un point d’entrée complet, ce qui permet au lecteur d’ouvrir le flux sur n’importe quel segment ; sur les sources à open-GOP, la frontière est l’image I la plus proche.

  • Protection du contenu (DRM) — la diffusion OTT d’un flux peut être chiffrée : HLS AES-128 avec une clé fournie par le serveur lui-même ou par un serveur de clés externe et avec une rotation facultative par fenêtres temporelles, ou bien MPEG Common Encryption (ISO/IEC 23001-7) selon les schémas cenc et cbcs pour CMAF et DASH. Le chiffrement est effectué une seule fois, au moment de la formation du segment, si bien que l’archive DVR est conservée chiffrée et survit à un nombre quelconque de rotations de clé. Pour plus de détails — Protection du contenu (DRM).

  • Chaque connexion MPEG-TS over HTTP est une session distincte — la liste des clients du flux comporte désormais une ligne par connexion avec son propre sess-id, le détail est accessible à /data/stream/http-clients/<sess-id>, une connexion isolée se ferme par POST /data/kick?sess-id=<id>, et la limite max-conn est respectée aussi pour des valeurs supérieures à un.

  • DVR (archive réseau) — chaque canal OTT est écrit sur disque en parallèle de la diffusion, avec la même segmentation et sans enregistreur distinct ; en mode faible latence, l’archive est tenue sur deux lignes, MPEG-TS et CMAF, de sorte que l’enregistrement est disponible dans le même conteneur que la diffusion en direct. Pour plus de détails — DVR.

  • Lecture de l’archive (VOD) — l’archive est servie sur les mêmes URL HLS, DASH et LL-HLS que la diffusion en direct : t=<temps> active le mode VOD et fixe le début de la fenêtre, d=<secondes> en donne la durée. La playlist HLS est alors close, le manifeste DASH statique, les interruptions d’enregistrement sont présentées comme des périodes distinctes ; les ensembles adaptatifs lisent l’archive avec les mêmes paramètres.

  • Catch-up par EPG — au lieu de t et d, il suffit de transmettre epg=<temps> : le serveur trouve lui-même, sur la chaîne EPG associée, l’émission diffusée à cet instant et en prend le début et la durée comme bornes de la fenêtre de lecture.

  • Sous-titres dans l’archive — les pistes WebVTT sont écrites sur disque avec les segments et sont restituées en VOD sur les mêmes URL ; les fenêtres sans réplique n’occupent aucun espace disque.

  • Stockages DVR — les stockages peuvent être multiples, chacun avec sa propre limite de remplissage et son propre ordre de nettoyage. La profondeur de l’archive (« Rétention (heures) », jusqu’à 90 jours) et le minimum protégé sont définis séparément pour chaque flux, et le nettoyage par espace libre ne touche ni le minimum protégé ni les fenêtres des sessions VOD ouvertes.

  • Moniteur DVR — un écran dédié affiche l’état et le remplissage des stockages, le volume et la profondeur de l’archive par flux ainsi que les temps de lecture et d’écriture, tandis que l’histogramme de couverture (/data/dvrstat) signale non seulement les trous de l’archive mais aussi leur cause — coupure de l’entrée, changement de PMT, embrouillage, déclenchement du nettoyage. C’est également depuis cet écran que sont effacés l’archive d’un flux donné et les répertoires des flux supprimés.

  • Une panne de disque d’archive n’arrête plus le nœud — une erreur de service de l’archive DVR se limite au stockage et à l’étape où elle est survenue : les autres flux et les autres lignes d’enregistrement continuent, et l’archive touchée est marquée comme nécessitant une reconstruction.

  • Alerteur — nouveau service d’alertes : chaque défaillance devient un incident qui est déclenché, mis à jour et résolu automatiquement, tandis que l’ensemble actif dédupliqué n’affiche que ce qui se produit à l’instant présent. La gravité est définie sur une échelle unique — de l’information jusqu’à la nécessité d’une action de l’administrateur ; un tel incident n’est résolu que par l’acquittement de l’opérateur. Pour plus de détails — Alertes (alerter).

  • Catalogue des codes d’alerte — plus de cinquante types d’incidents dans une seule liste : les flux et leurs entrées et sorties, les violations de TR 101 290, les ressources du nœud, les stockages et la santé de l’enregistrement DVR, la réception DVB et CI/CAM, les transcodeurs, l’OTT, les certificats et les nœuds du domaine. Les seuils de déclenchement se règlent dans la section des alertes.

  • Livraison externe des alertes — les alertes sortent de la console web : par courrier électronique en SMTP (STARTTLS, implicit TLS, AUTH), par message Telegram et par le lancement d’une commande arbitraire, à laquelle l’incident est transmis dans des variables d’environnement et sous forme de JSON complet sur l’entrée standard. Chaque canal possède son propre interrupteur et son propre seuil de gravité.

  • Alertes à l’échelle du domaine — l’opérateur de permanence voit les alertes de n’importe quel nœud depuis n’importe quel autre : l’ensemble actif se propage avec le keep-alive et est résolu dès qu’il disparaît à la source, et chaque ligne indique le nœud source. Les alertes matérielles et système restent locales par défaut et ne sont promues à l’échelle du domaine que par un paramètre distinct.

  • Journal en base de données — les messages du service sont écrits dans SQLite : enregistrements typés avec source et niveau de gravité, regroupement des répétitions consécutives en une seule ligne avec compteur, limitation de la conservation par durée et par volume. Contrairement à l’ensemble actif des alertes, le journal survit à un redémarrage.

  • Interrupteur général des notifications — enable désactivé dans les paramètres de l’alerteur, le nœud ne lève aucune alerte propre et n’envoie rien vers l’extérieur, y compris les alertes reçues de ses pairs du domaine ; dans la liste et dans le flux d’événements ne restent que les alertes des pairs diffusées dans le domaine.

  • La gravité d’une alerte d’entrée-sortie suit les conséquences — une entrée qui tombe alors qu’elle ne porte pas le flux est marquée Error, tandis qu’une entrée porteuse, toute sortie et une panne sans antenne sont marquées Critical ; l’évaluation est recalculée tant que l’alerte est ouverte et suit le basculement sur la réserve.

  • Couleur dans les notifications externes — un marqueur de couleur du niveau a été ajouté au texte du message (rouge pour les erreurs, jaune pour les avertissements, vert pour la levée, bleu pour l’information), et le courrier part en deux variantes à la fois : texte brut et HTML avec un bandeau coloré.

  • Les notifications Telegram survivent à une tempête — les alertes accumulées sont regroupées dans le plus petit nombre de messages que la limite de 4096 caractères autorise, et sur une réponse de limitation de débit le nœud attend le délai indiqué et réémet au lieu d’abandonner la notification.

  • Le délai de notification s’étend à l’entrée de réserve — l’avertissement indiquant qu’un flux fonctionne sur son entrée de réserve n’est levé que si la situation a duré plus que alert-delay ; une source qui se rétablit puis retombe ne produit donc plus une série de levées et de retraits. Avec alert-delay à zéro, le comportement est inchangé.

  • Moniteur TR 101 290 — contrôle continu de la conformité du flux d’entrée à la norme : un verdict unique (« Normal », « Problème », « Vérification… ») et un rapport structuré par priorités 1, 2 et 3, où sont indiqués pour chaque indicateur la clause de la norme, la valeur mesurée et la limite. Un multiplex MPTS est évalué dans son ensemble — sur tous les PID, tous les programmes et toutes les tables SI. Le flux est automatiquement classé comme CBR ou VBR, et les contrôles qui n’ont de sens qu’à débit constant ne sont pas évalués sur une source VBR et ne produisent pas de faux déclenchements. Pour plus de détails — Moniteur TR 101 290.

  • Dérive de l’oscillateur de référence — l’écart systématique de la fréquence d’horloge de la source est mesuré par régression linéaire en ppm, pour une tolérance ISO/IEC 13818-1 de ±30 ppm, et est présenté comme une métrique distincte. Une dérive lente est compensée par de légers micro-décalages du point de synchronisation (« Compensation de la dérive de synchronisation », activée par défaut), ce qui évite les à-coups en sortie.

  • Modèle de tampon T-STD — analyse du tampon vidéo du décodeur de référence selon ISO/IEC 13818-1, avec compteurs de débordements et de sous-alimentations pour MPEG-2, H.264 et HEVC ; le comptage suit l’horloge PCR et la vitesse de vidage s’ajuste au débit vidéo réel. Activé par le paramètre « Analyser le tampon vidéo T-STD ».

  • Analyse pour l’insertion publicitaire — interprétation des sections SCTE-35 avec les événements de raccord, les points de raccord de la couche transport avec anticipation configurable et les marques d’accès aléatoire. Les données sont affichées dans les statistiques du flux lorsque l’analyse approfondie est activée.

  • Assistant de réclamation — pour un flux présentant des violations persistantes, une consigne textuelle prête à l’emploi est constituée pour un chat IA, à partir de laquelle celui-ci rédige une lettre de réclamation formelle au fournisseur du flux : liste des violations persistantes, valeurs mesurées, clauses de la norme et impact sur le décodeur. La consigne est fournie par la requête GET /data/stream/<id>/ai-complaint-prompt ; le nom du flux et l’adresse de la source ne sont pas inclus dans le texte.

  • CI/CAM (EN 50221) — hôte Common Interface intégré : détection du module, lecture de son nom et de la liste des CA_system_id pris en charge, sélection des programmes à désembrouiller et transmission du CA_PMT pour chacun d’eux. Un module combiné au récepteur DVB désembrouille les programmes sélectionnés du multiplex reçu en ligne, plusieurs à la fois ; l’état des slots et le verdict pour chaque programme sont visibles dans l’interface.

  • Désembrouilleur logiciel BISS-1 / BISS-E — il s’applique non seulement à la réception depuis une carte DVB, mais aussi à toute entrée de flux : la clé est définie pour le SPTS entier ou par programme du multiplex et se change à chaud, sans redémarrer l’entrée. Lors d’une réception depuis une carte DVB, le résultat est en outre vérifié sur le flux lui-même, si bien qu’une clé erronée ne se présente pas comme un désembrouillage réussi mais déclenche une alerte dédiée.

  • Nettoyage de l’accès conditionnel à la réception DVB — un paramètre distinct de l’adaptateur supprime du multiplex reçu par une carte DVB les PID ECM et EMM, et retire de la PMT les descripteurs CA des programmes en clair : un flux FTA propre poursuit son chemin dans la chaîne. En cas de perte de la clé, la signalisation d’accès conditionnel est rétablie afin qu’un récepteur situé plus loin dans la chaîne puisse redemander l’accès.

  • Télémétrie du transcodeur — pour chaque encodeur sont publiées les informations média de la sortie réencodée : format d’image, codec vidéo, ensemble des codecs audio et débit courant ; pour chaque processus — la charge CPU et la mémoire occupée.

  • RTMP et RTMPS — une chaîne est publiée vers n’importe quel récepteur RTMP, y compris YouTube et Facebook : vidéo H.264 ou HEVC (HEVC via Enhanced RTMP) et une seule piste AAC ; pour rtmps://, le nœud se connecte en tant que client TLS. Dans l’autre sens, l’entrée récupère elle-même le flux depuis une source rtmp:// ou rtmps:// et remultiplexe le FLV en MPEG-TS.

  • Basculement de source sans coupure — lors du changement de l’entrée active sur l”émetteur, les peers PS1 en réception ne se reconnectent pas : la numérotation et les marques temporelles restent continues, une pointe de file d’attente est absorbée par l’abandon des paquets les plus anciens, et le manque est comblé par la retransmission normale.

  • Retransmission adaptative PS1 — le récepteur mesure le RTT réel jusqu’à l’émetteur et ajuste lui-même les intervalles de demandes de répétition ; le RTT mesuré, l’intervalle de redemande courant et l’indication d’une latence trop faible sont reportés dans les statistiques de la liaison. La latence du tunnel de réception se définit directement en millisecondes, au lieu de l’ancien multiplicateur du RTT.

  • États « Reconnexion » et « Action administrateur » — une entrée ou une sortie ayant perdu sa source est rouverte sur place et reste à l’état « Reconnexion » pendant toute la durée des tentatives, ne levant qu’un seul avertissement par épisode au lieu d’un message à chaque tentative. Une cause qu’une nouvelle tentative ne permet pas de lever — port occupé, interface absente, données qui ne sont pas du MPEG-TS, échec SRT sur le chiffrement — fait passer l’entrée ou la sortie à l’état « Action administrateur » avec une alerte persistante, tandis qu’une modification des paramètres est appliquée immédiatement.

  • Date de la dernière erreur — l’heure de la dernière erreur d’une entrée ou d’une sortie est publiée à côté de son texte (last-error-ts, le même champ existe aussi dans le flux d’événements), de sorte qu’une cause ancienne restée sur une entrée en pause se distingue de la panne en cours.

  • Diagnostic lorsque le contenu de l’entrée est inexploitable — le message sur la perte de synchronisation MPEG-TS nomme la cause probable : des paquets ont été trouvés mais sont décalés d’un nombre d’octets connu, ou bien il n’y a aucune structure MPEG-TS ; pour les entrées PS1 et Pro-MPEG, une indication sur la phrase secrète de chiffrement est ajoutée.

  • Taille réelle du tampon de réception — l’entrée publie socket-buffer-actual, la taille accordée par le noyau, tandis que socket-buffer-size ne reste qu’une demande, rabotée par la limite système ; l’écart est donc visible immédiatement au lieu de se manifester par des pertes à haut débit.

  • Multiplexeur MPTS : identité d’origine — les programmes peuvent conserver leurs PID d’origine et l’ordre des programmes dans la PAT, la SDT et la NIT se définit manuellement, si bien qu’un multiplex est migré vers Perfect Streamer sans changer l’identité du flux pour les équipements de réception. Les programmes avec embrouillage TS sont migrés avec leurs marques temporelles d’origine.

  • Numérotation automatique des PID pour le SPTS — enable-autopid avec autopid-base déplace tout le programme dans une fenêtre prévisible de 64 identifiants, en commençant par la PMT, puis la vidéo, l’audio et les autres flux élémentaires dans l’ordre de la table source ; un programme qui ne tient pas dans la fenêtre conserve intégralement ses PID d’origine.

  • La taille du datagramme se règle sur toutes les sorties — le paramètre packets s’applique désormais non seulement en SRT mais aussi sur les sorties UDP, RTP, Pro-MPEG et RIST, et pour la sortie vers un fichier ou vers le flux standard il fixe la taille du bloc écrit. Les valeurs par défaut reprennent le comportement antérieur, une configuration dans laquelle le paramètre n’a jamais été défini ne change donc pas ; une valeur enregistrée différente de la valeur par défaut était ignorée par les versions antérieures et prend désormais effet dès le premier redémarrage — vérifiez-la avant la mise à jour.

  • Intégration avec une facturation externe — chaque session de spectateur est autorisée dans un système de facturation ou de CRM externe, maintenue par une réautorisation périodique et signalée à ce même système à son terme : cycle de vie Start / Interim / Stop dans le style RADIUS, la révocation d’un abonnement interrompt la session en pleine visualisation. L’OTT, le peering PS1 et les sorties SRT sont couverts, et le système de facturation lui-même se raccorde au moyen de modèles de requête et d’analyse de la réponse, sans modification logicielle.

  • Client ACME intégré (Let’s Encrypt) — émission et renouvellement automatique des certificats pour le serveur web, le serveur HTTP/OTT et le serveur EPG : un certificat est commandé pour chaque nom d’hôte configuré, le renouvellement est vérifié quotidiennement et une alerte est déclenchée en cas d’échec. Une autorité de certification arbitraire et la liaison de compte externe sont prises en charge, et un nouveau certificat est appliqué sans redémarrer le service.

  • Arrêt rapide du service — l’arrêt n’attend plus un client qui a cessé de lire les données : à charge égale, le nœud se termine en 2–4 secondes au lieu d’environ une minute, un redémarrage prend donc quelques secondes et ne laisse pas l’antenne sans diffusion.

  • pss_lic 2.0 — l’utilitaire en ligne de commande de gestion de la licence est passé aux commandes apply, c2v, fingerprint, recipient, keys, detach, rehost et cancel avec des options longues : il applique une mise à jour de licence reçue, exporte l’état de la clé pour le fournisseur et transfère la licence d’un nœud à l’autre, y compris temporairement, et il accepte tout fichier sur l’entrée standard et écrit sur la sortie standard. En détail — pss_lic.

  • Modification manuelle du fichier de configuration — un JSON Schema pour pss.json (strict et compatible) est publié avec la documentation, accompagné d’un guide pas à pas pour modifier et transporter le fichier : la configuration d’un nœud arrêté peut désormais être modifiée directement et transportée entre installations et versions après vérification du résultat avec le schéma, alors que l’API HTTP était auparavant le seul moyen pris en charge. En détail — Le fichier de configuration pss.json.

  • Nouvelle interface web — la gestion du nœud est passée à une nouvelle console, qui s’ouvre à l’adresse du nœud (chemin /admin) : vue d’ensemble, flux, supervision du système, DVB, DVR, transcodeurs, clients, journal, alertes et tous les paramètres du serveur. Des schémas dédiés montrent la topologie du domaine Meshwork et la chaîne du flux sélectionné, des entrées jusqu’aux sorties. L’ancienne interface est conservée à l’adresse /classic. Pour plus de détails — Interface web.

  • Authentification unique dans le domaine — un compte peut être autorisé à se connecter automatiquement : après une seule connexion par mot de passe, le navigateur ouvre le panneau de ce nœud sans formulaire de connexion pendant 14 jours et survit à un redémarrage. Suivre un lien depuis ce panneau transmet la session à un nœud voisin du domaine si les conditions du transfert sont remplies (Serveur web et comptes) ; une adresse de voisin saisie à la main ne transmet pas la session. Un script ou un panneau tiers présente la même clé dans l’en-tête X-Auth-Token ou le paramètre auth-token, et un administrateur révoque la connexion automatique dans tout le domaine d’un coup.

  • CORS pour l’API d’administration — les nœuds d’un même domaine Meshwork sont autorisés sans aucun réglage, les autres origines se déclarent dans web-server/cors-origin (la valeur * autorise toute origine, none désactive le mécanisme), de sorte que l’interface d’un nœud s’adresse à l’API d’un autre ; une requête inter-domaines doit porter le jeton explicitement — le cookie et Digest n’y ont pas d’effet.

  • Jeton de sa propre session — GET /data/auth-token renvoie au client son propre jeton et sa date d’expiration absolue, et le champ web-login-expires a été ajouté à /data/server, de sorte que l’interface indique jusqu’à quand la connexion est valable sans lire le jeton lui-même.

  • Fin d’une session d’ouverture automatique — POST /data/auth-tokens/revoke?login=<login> ferme toutes les sessions actives d’un compte, et ?id=<hex> en ferme une, par l’identifiant issu de la liste des sessions ; la réponse indique le nombre de sessions fermées, et la révocation se propage à tout le domaine.

  • Motif du refus lors du passage à un nœud voisin — si le passage n’a pas donné d’ouverture automatique, le nœud renvoie dans l’adresse un paramètre jump valant no-session, foreign-domain, autologin-off ou token-refused, au lieu d’afficher silencieusement le formulaire de mot de passe.

  • Mise à jour en temps réel — le nœud publie son état sous forme de flux d’événements sur /data/events : à la connexion, un instantané complet est reçu, puis les instantanés des flux, des ressources système, des clients et des adaptateurs DVB sont rafraîchis une fois par seconde, tandis que les alertes et les changements d’état arrivent sous forme d’événements. L’interface et les tableaux de bord externes fonctionnent sans interrogation périodique.

  • Aide contextuelle — chaque écran et chaque fenêtre importante de la nouvelle interface disposent d’un appel à l’aide qui ouvre la section de documentation correspondant précisément à ce qui est ouvert à cet instant : le bouton d’aide général pour l’écran, le bouton « ? » dans l’en-tête de la fenêtre pour cette fenêtre. La section s’ouvre dans la langue de l’interface.

  • Langues, thèmes et dispositions — l’interface est traduite en six langues (russe, anglais, allemand, français, espagnol, portugais), prend en charge un thème clair et un thème sombre et adapte d’elle-même la densité de la disposition au téléphone, à la tablette, au poste de travail et au mur d’images.

  • Accès sans limite du nombre de connexions — les limites de connexions du destinataire ont acquis un troisième état, « Sans limite », à côté de « Protocole interdit » et de « Au plus » avec un nombre ; auparavant, un accès illimité se représentait par un nombre délibérément grand. Zéro signifie toujours l’interdiction du protocole, si bien que le sens des réglages enregistrés ne change pas après la mise à jour. En détail — Utilisateur : ajout et modification.

  • La modification de l’accès aux flux n’affecte pas les sessions étrangères — ajouter un flux à la liste des flux autorisés et revenir à une liste vide ne rompent aucune session, tandis que restreindre la liste ferme les sessions PS1 et SRT uniquement sur les flux qui en sont sortis. Auparavant, toute modification de la liste coupait le compte entièrement sur tous les protocoles.

  • Activation de la licence depuis l’interface web — l’écran « Licence » s’est doté d’une section « Activation » : l’export de l’état de la clé pour le fournisseur — sous forme de fichier C2V ou vers le presse-papiers — et l’application de la clé V2C reçue, par fichier ou par collage du texte. L’application de la clé redémarre le nœud. En détail — Licence.

  • Avertissement d’expiration de la licence — le nœud déclenche une alerte deux semaines avant la fin du terme et l’élève au niveau nécessitant une intervention une fois le terme échu. L’alerte est répliquée à l’échelle du domaine, si bien que la licence expirante d’un voisin est visible depuis n’importe quel nœud (Alertes (alerter)).

  • Une licence jugée non authentique arrête le nœud — un nœud dont la licence est jugée non authentique lève une alerte nécessitant une action de l’administrateur, redémarre le service, et le démarrage est refusé : le service reste arrêté tant qu’une licence authentique n’est pas présente sur le nœud. L’alerte est répliquée à l’échelle du domaine (Alertes (alerter)).

  • Repli sur la dernière configuration fonctionnelle — le nœud conserve une copie des paramètres avec lesquels il a démarré proprement la dernière fois et, lorsque pss.json est inacceptable, il démarre sur cette copie — avec tous ses flux, et non sur les paramètres par défaut, qui ne contiennent aucun flux. L’archive des fichiers rejetés a été mise en ordre : noms en UTC, suffixe numérique au lieu d’un écrasement lorsque deux échecs tombent dans la même seconde, les vingt copies les plus récentes ; l’alerte nomme directement le chemin de la copie archivée. En détail — Comportement au démarrage et en cas d’erreurs de configuration.

  • La priorité des entrées se modifie à la souris et au clavier — un administrateur peut réordonner les entrées d’un flux par glisser-déposer ou avec Alt+↑ et Alt+↓, dans l’onglet « Entrées » de l’éditeur et dans la ligne dépliée de la liste des flux (sur téléphone, l’ordre est seulement affiché) ; une entrée ajoutée se place toujours en dernier et ne remplace jamais l’entrée principale (Flux).

  • Le numéro d’une entrée est sa place dans la liste de redondance — un seul et même numéro figure désormais dans la ligne du flux, dans la ligne dépliée, dans l’éditeur et dans le texte de l’alerte. Les entrées de même valeur de priorité conservent l’ordre dans lequel elles sont enregistrées, y compris lors des modifications ultérieures des paramètres (Redondance des sources).

  • La défaillance d’une entrée abandonnée se lit comme un historique — l’entrée que le flux a quittée pour une entrée de secours est arrêtée mais conserve sa cause : l’interface l’affiche en ligne atténuée avec un âge, et non comme une défaillance en cours, et l’alerte sur l’erreur de cette entrée est levée. La cause est alors la sienne, de niveau transport, si l’entrée a eu le temps de la signaler elle-même (Redondance des sources).

  • Tri de la liste des clients — sur l’écran « Clients », l’en-tête de colonne trie la liste : les colonnes numériques s’ouvrent en ordre décroissant, les colonnes textuelles de A à Z, et un troisième clic rétablit l’ordre du nœud. C’est toute la liste trouvée qui est triée, et non la page affichée (Clients).

  • Accès au flux depuis l’écran des transcodeurs — la ligne du décodeur et de chaque encodeur a reçu un bouton qui ouvre la liste des flux sur le flux concerné. Disponible dans tous les rôles (Transcodeurs).

  • Le programme du démultiplexeur se choisit dans une liste, y compris pour un adaptateur DVB — un adaptateur en marche publie son multiplex, et le champ « PNR » propose ses programmes avec leurs noms, y compris les programmes internes T2-MI sous leurs numéros composites (Démultiplexeur (demuxer)). L’adaptateur d’une entrée dvb se choisit lui aussi par son nom au lieu d’être saisi comme numéro d’enregistrement (Adaptateur DVB (dvb)).

  • La réception DVB ne dépend plus de la version compilée — le type d’entrée dvb et la section des adaptateurs DVB sont disponibles sur tout nœud ; la seule condition est un frontend détecté et un pilote qui permette au service de l’ouvrir (Récepteur DVB).

  • Le scanner DVB cède le tuner à un adaptateur configuré — un multiplex trouvé peut être appliqué sans attendre la fin du passage : l’adaptateur prend le tuner et démarre en une seconde environ, tandis que le balayage se termine comme annulé en conservant ses résultats à l’écran. Un passage s’arrête avec le bouton « Stop » et par la fermeture de la fenêtre (Balayage).

  • Les panneaux de la vue d’ensemble du nœud suivent la présence du sous-système — « Transcodeurs » et « Adaptateurs DVB » apparaissent dans la vue d’ensemble là où le matériel ou les instances existent, ou là où il y a une défaillance à signaler. Sur un nœud sans transcodeurs et sans tuner, ces panneaux sont absents, et l’accès à leurs sections depuis la vue d’ensemble l’est aussi (Vue d’ensemble du nœud).

  • Adresses des interfaces dans le moniteur système — la carte « Réseau » et les graphiques d’historique portent l’adresse IPv4 de l’interface lorsque le nœud la communique, VLAN imbriqués compris (Moniteur système).

  • Le chemin d’un stockage DVR s’écrit sans séparateur final — l’interface et l’API HTTP rejettent une telle valeur : deux écritures d’un même répertoire passeraient le contrôle d’unicité comme deux stockages distincts (Stockages DVR).

  • Le paquet exige le service de protection 10.33 ou plus récent — pstreamer fournit les bibliothèques de nouvelle génération du système de protection, et un aksusbd plus ancien ne les accepte pas (Configuration système requise). Le service se trouve dans le même dépôt et s’installe avec le paquet, mais sa mise à jour est irréversible, quel que soit le type de clé — la marche à suivre et ses conséquences sont décrites sur les pages d’installation (Installation sur les systèmes de la famille RHEL, Installation sur les systèmes de la famille Debian).

  • Sélection explicite du PLP en DVB-T2 — le champ « Stream id (ISI/PLP) » a reçu une valeur « auto » (-1) : aucun filtre n’est appliqué, le tuner prend le flux par défaut du pilote, et un nouvel adaptateur est créé exactement ainsi. Un zéro explicite est de ce fait devenu une véritable sélection du flux zéro et non plus « non défini » ; un adaptateur dont le zéro est enregistré dans les paramètres ne recevra donc, après mise à jour du nœud, que ce flux (Adaptateurs).

  • Le scanner trouve les PLP — le champ « Sonder les PLP jusqu’à » balaie les PLP des transpondeurs DVB-T2 et affiche chaque PLP trouvé sur une ligne distincte avec sa propre liste de programmes ; le numéro est repris dans l’adaptateur créé, et les statistiques de l’adaptateur ont reçu une ligne « PLP / ISI » (Balayage).

  • Recherche dans les catalogues du scanner — des centaines de satellites et de bandes régionales sont triés par nom et filtrés par une chaîne de recherche ; une ligne déjà sélectionnée ne disparaît pas de la liste, quoi que l’on saisisse (Scan DVB).

  • Correction de la référence PCR dans la PMT — un nouveau paramètre MPEG-TS pour les sources dont la table ne déclare pas de PCR utilisable : le nœud déclare dans la PMT le PID sur lequel la PCR est réellement transportée (Modification du flux).

  • Reconstruction de la mémoire de gigue après un creux de la source — une entrée qui a survécu à un arrêt de sa source ne poursuit plus avec une file presque vide en transmettant aux sorties chaque à-coup suivant : le nœud reconstruit la mémoire tampon une seule fois, au prix d’une unique coupure (Synchronisation).

  • Mode de contrôle du débit du codeur vidéo — le transcodeur a reçu le choix entre un débit constant et deux modes variables : le nombre indiqué se lit soit comme le débit moyen (les pics atteignent une fois et demie cette valeur), soit comme un plafond strict (le débit moyen représente alors les deux tiers de celui-ci). Il n’y a toujours qu’un seul nombre — le codeur déduit lui-même la seconde limite d’un rapport pic/moyenne fixe de 1,5. Dans les modes variables, le codeur cesse de bourrer le flux élémentaire ; l’économie de bande passante n’est donc obtenue que là où le flux récepteur ne réaligne pas le débit (Paramètres de l’encodeur).

  • Un redémarrage du transcodeur est expliqué dans le journal — chaque redémarrage du processus fils nomme sa cause et son code de sortie au niveau « Notification », et non en silence dans la trace. Par ailleurs, le nœud a cessé de rouvrir indéfiniment un canal qui ne répond pas : après deux tentatives infructueuses, il demande un nouveau processus (Supervision).

  • Un flux supprimé reste visible dans l’éditeur ouvert — si un flux est supprimé du nœud alors que son éditeur ou son schéma de traitement est ouvert, le nœud le signale sur une ligne dédiée, et l’enregistrement devient indisponible avec la même raison énoncée à côté du bouton. Auparavant, toutes les listes d’un tel flux se vidaient simplement, ce qui ressemblait à un flux sans entrées ni sorties configurées (Configurer le flux).

  • Un enregistrement refusé nomme sa cause — au lieu d’une phrase générale valable pour tous les cas, le formulaire indique ce qui a précisément fait obstacle : un délai d’attente de réponse dépassé, une interdiction liée au rôle, ou le refus du nœud lui-même, dans ses propres termes.

  • Libellés et choix des PID dans les règles de filtrage — chaque numéro est libellé avec son type et son codec et, sur un multiplex, également avec le programme auquel il appartient ; la ligne d’ajout a reçu la liste des PID que la source transporte réellement. La saisie manuelle demeure : le transport peut porter un PID à propos duquel rien n’a été décodé (Éditeur d’entrée et de sortie).

  • Les écrans DVB affichent le numéro de programme adressable — pour un service situé dans une porteuse T2-MI, la liste des programmes de l’adaptateur et ses statistiques portent le PNR composite, celui-là même par lequel le programme est adressé dans les sélecteurs du démultiplexeur, de BISS et de CAM. Son numéro propre à l’intérieur de la porteuse se répète sur chaque porteuse d’un transpondeur à groupes en miroir et ne désigne rien (Statistiques de l’adaptateur).

  • Un slot BISS est toujours proposé sous forme de liste — les programmes en clair y figurent en dernier, marqués · clear ·, si bien que sur un multiplex sans un seul programme chiffré la liste n’est plus vide : la clé est souvent saisie à l’avance, et un feed événementiel est en clair entre les événements (Désembrouillage).

  • Des statistiques du flux vers le transcodeur et vers sa source — si l’entrée active d’un flux a été créée par un transcodeur, sa valeur est devenue un lien vers l’écran des transcodeurs avec la ligne de l’instance concernée dépliée, et une pastille portant le nom du flux que cette instance décode est apparue à côté. Les deux liens sont accessibles dans tous les rôles (Statistiques du flux).

  • Limites des exécutions dans le journal — chaque démarrage du service est marqué dans le fil par une ligne dédiée portant l’instant du démarrage et la version compilée sur laquelle l’exécution a démarré : l’exécution en cours affiche à côté sa durée de fonctionnement, les précédentes indiquent combien de temps elles ont tourné et combien de temps le nœud est resté à l’arrêt avant le démarrage suivant, et une exécution terminée sans arrêt régulier est signalée à part. Le séparateur est posé même lorsque le filtre par gravité est actif (Journaux).

  • Limite de taille de la base de statistiques — la base de métriques est bornée non seulement par la fenêtre de conservation, mais aussi par la taille. Le nœud rend compte du dernier nettoyage — combien d’historique subsiste, quelle est la taille de la base et combien de temps le nettoyage a pris — et indique explicitement si la limite de taille s’est avérée plus stricte que la fenêtre configurée (Paramètres du serveur).

  • Les valeurs ramenées aux bornes au chargement sont annoncées aussitôt — si le nœud, en lisant les paramètres, a ramené une valeur à la limite admissible, il l’indique à l’écran dès le démarrage et non seulement par une ligne dans le journal (Comportement au démarrage et en cas d’erreurs de configuration).

  • Une licence d’une génération obsolète n’est pas acceptée — un nœud muni d’une licence authentique de la génération précédente ne démarre pas et lève une alerte distincte. Il ne s’agit ni d’un terme échu ni d’une contrefaçon : la génération 2 n’est acceptée que comme licence d’essai temporaire, aussi une licence perpétuelle de cette génération est-elle rejetée d’emblée au lieu de vivre jusqu’à sa date (Catalogue des codes d’alerte).

  • Le bourrage automatique calcule sa cible d’après le contenu — en mode de débit automatique, le nœud part du débit réel du contenu et non de sa propre sortie ; la cible ne dérive donc plus vers le haut sans revenir et redescend dès que le contenu tient de nouveau dans le débit configuré (Gestion du débit).

  • La fenêtre de compensation de dérive est proportionnée à la mémoire tampon — la fenêtre souple est plafonnée au quart de la taille cible de la mémoire de gigue, sans jamais descendre sous 100 ms : une entrée dotée de la mémoire tampon standard ne fonctionne plus sans marge, la compensation rattrape la synchronisation plus tôt, et la reconstruction d’urgence de la mémoire tampon en cas d’épuisement se déclenche enfin (Synchronisation).

  • Autres améliorations et corrections de bogues.