Télémétrie (session olfp14) : le panneau n'avait envoyé que ~18 s
d'avance au démarrage ; la réserve est restée à 13-20 s et un silence du
panneau a fini en coupure de 5,5 s. Le lecteur ne fabriquait pas de
réserve : il gardait seulement celle offerte par le panneau.
Régulateur de vitesse unique pour le direct MPEG-TS, chaque seconde :
sous 20 s d'avance, x0,97 (hauteur du son préservée) jusqu'à 25 s ;
au-delà de 35 s (rafale de rattrapage), x1,1 jusqu'à 28 s. Seuils
d'entrée/sortie distincts : pas d'oscillation. liveSync de mpegts.js
désactivé : il ne sait qu'accélérer et remettait la vitesse à 1 sous sa
cible, ce qui annulerait le ralenti.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Télémétrie (session de 25 min avec la réserve de 25 s) : un silence du
panneau a été absorbé sans coupure (avance 27 → 14,7 s), mais à la
reprise le panneau renvoie d'un coup tout le retard. L'avance dépassait
alors le seuil de rattrapage (45 s) et le lecteur sautait 20 s de
programme — deux fois en une minute.
Saut seulement au-delà de 90 s de retard ; liveSync (x1,1 au-delà de
35 s) résorbe l'excédent en douceur. Vidéo déjà vue purgée plus tôt
(30 s) pour rester sous le quota du SourceBuffer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Télémétrie d'un freeze en prod : le panneau s'est tu ~15-20 s sur une
connexion restée ouverte (aucune reconnexion FFmpeg dans les logs).
Le lecteur n'avait gardé que 11-16 s d'avance — il « consommait » à x1,1
celle que le panneau envoie au démarrage pour revenir à 12 s — puis,
après la coupure de 6,3 s, il repartait avec 1 s de stock et recoupait
aussitôt (1,7 s puis 2,0 s).
- réserve visée 25 s (liveSync 25/35, saut au-delà de 45 s) : ~25 s de
retard sur le direct en échange de la traversée de ces silences
- après une coupure, attente de 4 s de réserve avant de relire (comme
mpv cache-pause), 15 s au plus ; une pause utilisateur l'annule ; le
lecteur lite affiche « Reconstitution de la réserve » au lieu du
bouton lecture
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Les freezes (image et son figés puis reprise) se produisent dans le
navigateur de l'utilisateur ; le serveur n'en voyait rien. Le lecteur
envoie désormais chaque coupure (durée, buffer), saut (de → vers),
erreur MPEG-TS/HLS, recréation, repli HLS et changement de profil, plus
un bilan toutes les 60 s, à POST /api/player-log (authentifié). Le
serveur écrit une ligne « [Player] … » par événement.
Entrée filtrée : événements et champs connus seulement, texte borné,
URL masquées (une erreur réseau peut recopier les identifiants Xtream),
pas d'injection de lignes. Envoi jamais bloquant pour la lecture.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mesure après déploiement : premier octet de turbo.ts à 4,5–4,8 s avec la
source HLS, contre 4,3–4,7 s en .ts — aucun gain. Les logs confirment
que le HLS était bien utilisé (aucun repli). La sonde qui annonçait
0,5 s ouvrait le .ts AVANT le .m3u8 : la chaîne était déjà démarrée chez
le panneau. Les ~4,5 s sont le temps de démarrage d'une chaîne chez le
fournisseur, quel que soit le format.
Retour au .ts, déjà validé en lecture, plutôt que de garder un chemin
plus complexe (segments de 10 s, repli) sans bénéfice mesuré.
This reverts commit 0ea60cc.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mesuré en prod après le premier correctif : 69 chaînes sur 149 avec
guide. Les vides restantes relevaient surtout de formes de nom que le
dump écrit autrement, ou de pays non couverts :
- « F3 ALPES » → France 3 Alpes (France.3.-.Alpes.fr) : F2 à F5 développés
- clé souple en dernier recours, dans son propre espace de noms :
sans code pays ni « channel/tv/hd » (« AB3 » → AB3.Channel.fr)
- chaîne « +1 » absente du dump (TF1 +1) : guide de la chaîne principale
décalé d'une heure ; une +1 qui a son propre guide le garde
- sources par défaut : FR1 puis CH1 (RTS…) et BE2 (même fournisseur),
le dump français reste prioritaire
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mesuré en prod avec la sonde admin : le panneau met 4,2 à 4,4 s à
répondre la redirection d'un .ts, contre 0,2 à 1,3 s pour un .m3u8 dont
le premier segment arrive ensuite en 50 ms.
turbo.ts et les sessions HLS live lisent désormais le .m3u8 du panneau
(-live_start_index -2 : deux segments d'avance d'un coup), avec repli
automatique sur le .ts si le HLS ne livre rien — dans la même réponse
pour turbo.ts, le lecteur ne voit qu'un démarrage plus long. Pas de
reconnect_at_eof en HLS : chaque segment finit par un EOF (leçon de
xtremobile). Le navigateur reçoit toujours le même flux MPEG-TS.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
~4,3 s des ~4,6 s d'un zap se passent avant le premier octet du panneau.
Le compte autorise aussi le HLS (allowed_output_formats : m3u8, ts) ;
GET /api/admin/upstream-probe?stream=<id> mesure, pour .ts et .m3u8,
chaque redirection, les en-têtes, le premier octet et le premier segment,
pour décider du format à utiliser. Admin uniquement ; seuls l'hôte et les
durées sont rendus, jamais les identifiants ni les jetons.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sans charset annoncé, Response.body pouvait décoder le JSON du panneau en
latin-1 et abîmer les noms accentués ou décorés (« Chérie », « ◉ »), donc
leur correspondance avec le guide XMLTV. Le test simule désormais des
octets UTF-8 sans charset, comme le panneau réel.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Constaté en prod : chaque /api/epg répondait 500 en 4 s. Un appel
player_api qui lève (connexion coupée, délai) n'était pas rattrapé, et le
dump XMLTV externe, qui couvre pourtant TF1, France 2, M6…, n'était jamais
consulté. Et 59 % des chaînes françaises n'ont pas d'epg_channel_id : leur
nom brut (« FR - TF1 FHD ◉ ») ne correspondait à aucune entrée XMLTV.
- échec player_api rattrapé : la chaîne passe à la source suivante
- dump externe (déjà en mémoire) avant l'appel lent chaîne par chaîne
- correspondance par nom nettoyé : préfixe pays, FHD/HD/UHD/4K/HEVC…,
symboles retirés, forme « nom.pays » tentée ; « +1 » conservé
- tous les display-name XMLTV indexés, plus seulement le premier
- table des chaînes : un seul téléchargement partagé, décodé hors de la
boucle principale, et un échec n'est plus gardé 6 h (2 min)
- guide vide gardé 5 min au lieu de 30
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AccountLimits interrogeait player_api.php avant d'ouvrir le flux quand
sa valeur n'était pas en cache (premier flux, puis toutes les 10 min).
Le panneau met jusqu'à 4 s à répondre (mesuré en prod) : autant de
retard au démarrage d'une chaîne ou d'un film.
La valeur connue, même périmée, ou le repli (1) est rendue tout de suite ;
la lecture chez le panneau se fait en arrière-plan, une seule à la fois.
Sans risque : le quota ne sert qu'à choisir quels flux orphelins couper.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La règle « le dernier flux gagne » coupait aussi un flux en cours de
lecture. Deux lecteurs ouverts sur un compte à une connexion se coupaient
alors en boucle (chacun relance aussitôt) : plus aucune image nulle part.
Constaté en prod : tant qu'un autre onglet lisait, chaque ouverture
échouait après 5 s sans un octet.
Une connexion n'est désormais coupée que si son spectateur ne donne plus
signe de vie depuis 15 s : aucune requête de playlist/segment (HLS, film)
ni octet remis au client (turbo.ts). Les orphelins partent toujours, un
second lecteur actif est refusé par le panneau comme avant.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le serveur réclamait toujours <id>.mkv au panneau. Un film stocké en .mp4
était refusé (HTTP 551 constaté en prod). Le client transmet désormais
container_extension (?ext=), validé côté serveur ; mkv reste le défaut
pour un client qui ne l'envoie pas. Même approche que xtremobile, qui lit
ces films sans souci.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
main.dart.js, flutter_bootstrap.js et xf-player-core.js gardent le même
nom d'une build à l'autre. En prod, Nginx Proxy Manager les met en cache
(Cache Assets) jusqu'à 12 h, même sur rechargement forcé : après le
dernier déploiement, l'ancienne app et l'ancien lecteur tournaient avec
le nouveau serveur.
Au démarrage, le serveur réécrit index.html, flutter_bootstrap.js et
player*.html pour référencer ces fichiers avec ?v=<empreinte du contenu> :
chaque version a sa propre URL, aucun cache ne peut les confondre.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
L'abonnement n'autorise qu'une connexion simultanée (max_connections = 1,
vérifié en prod). Or un FFmpeg de lecture survivait au spectateur : 4 min
pour un direct HLS, jusqu'à 15 min ou la fin du téléchargement pour un
film, le temps de détecter la déconnexion pour turbo.ts. Le flux suivant
trouvait le slot pris : HTTP 551 ou timeout côté panneau (film qui ne
démarre pas, zap qui échoue).
Avant d'ouvrir une connexion amont, le serveur coupe désormais les plus
anciennes connexions de lecture du même compte, dans la limite du quota
max_connections lu chez le fournisseur (cache 10 min, 1 par défaut). Les
enregistrements ne sont jamais coupés.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Les panneaux Xtream livrent le flux par rafales (~6 s de contenu puis
plusieurs secondes de silence). Le rattrapage mpegts.js réglé à 5 s max /
1 s de marge sautait en avant à chaque rafale puis tombait à sec : mesuré
en prod, 12 sauts et 14 coupures en 30 s sur une chaîne FHD.
Marge portée à 12 s, saut seulement au-delà de 30 s de retard, retard
résorbé par liveSync (x1,1) et purge du buffer déjà lu. Rejoué en prod
avec cette config : 0 coupure en continu.
Ajoute des tests Node du moteur web, lancés par la CI.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le repli XMLTV journalisait l'URL `xmltv.php?username=…&password=…` du
panneau en clair, et le texte des `ClientException` / `ProcessException`
recopiait aussi l'URL : les identifiants de l'abonné finissaient dans
`docker logs`. Passage par `LogRedactor.redactUrl` dans XmltvEpgService,
EpgApi, le relais live, FFmpegSessionManager et RecordingScheduler.
Test : capture des `print` via une Zone pour vérifier le masquage.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le serveur n'a qu'une boucle d'événements. La décompression et le
parsing des dumps XMLTV (7000+ chaînes, ~90 Mo) la gelaient pendant
plusieurs secondes : plus rien ne répondait, y compris le relais
turbo.ts. La lecture se coupait donc au démarrage, au moment où
l'écran des chaînes demandait le guide (EPG à 19-26 s dans les logs).
- Téléchargement inchangé, puis gunzip + utf8 + parse dans Isolate.run
- _parse devient statique (aucune capture de this, client HTTP non
transférable)
- Test : la boucle d'événements ne doit pas geler plus de 250 ms
pendant l'indexation d'un dump de taille réelle (1,65 s avant)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La montée en Dart 3.13 / Flutter 3.47.6 n'avait ajusté que la section
`sdks` à la main. `flutter pub get` réaligne les paquets que le SDK
épingle via flutter / flutter_test : characters 1.4.1, matcher 0.12.20,
material_color_utilities 0.13.0, meta 1.19.0, test_api 0.7.12,
vector_math 2.4.3. bin/pubspec.lock était déjà cohérent.
Vérifié en local (Flutter 3.47.6 / Dart 3.13.5) : dart analyze et
dart test côté serveur (94 tests), dart analyze lib test (infos
seulement) et flutter test côté front.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
L'image ghcr.io/cirruslabs/flutter:stable n'est plus publiée depuis
Flutter 3.44.0 : le build Docker compilait toujours avec Dart 3.12.0
(mai 2026), alors que la CI testait le serveur en Dart 3.13 et le
front en Flutter 3.38.4. Trois SDK différents selon l'endroit.
- Dockerfile : SDK Flutter officiel 3.47.6 (Dart 3.13.5) téléchargé
depuis flutter_infra_release, version en ARG
- CI : Flutter 3.38.4 → 3.47.6, Dart 3.13.2 → 3.13.5 — même SDK que
l'image
- pubspec : contrainte sdk ^3.13.0 (au lieu de >=3.0.0) pour pouvoir
utiliser les nouveautés du langage (constructeurs primaires,
raccourcis `.valeur`, éléments `?x`). Les lockfiles exigeaient déjà
3.10.3 / 3.11.0 : le minimum affiché était faux
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Serveur chargé ou VRAM limite : NVENC refuse d'ouvrir l'encodeur
(OpenEncodeSessionEx failed: out of memory), FFmpeg meurt en une
seconde et la playlist part en 502. Chaque relance retombait sur le
même GPU saturé : le flux restait illisible.
- Serveur : un échec imputable au GPU (NVENC, CUDA, mémoire) relance
la session une fois en libx264, sous le même identifiant — les
segments suivent sans que le lecteur s'en aperçoive. Direct, VOD et
enregistrements
- Le GPU est écarté 2 min après une panne : les sessions suivantes
partent directement sur le CPU au lieu d'échouer une à une
- Source injoignable ou délai dépassé : pas de repli, il doublerait la
charge d'un serveur déjà occupé
- Process.start qui échoue (serveur à court de ressources) : 502/503
au lieu d'une exception remontée en 500
- Client : une erreur réseau fatale avant la première playlist
appelait hls.startLoad(), qui ne relance pas ce chargement → spinner
infini, aucune erreur, relances de page jamais déclenchées. L'erreur
remonte désormais à la page
- mpegts.js : au-delà de 3 erreurs en 60 s, bascule sur HLS au lieu de
recréer sans fin (un FFmpeg neuf toutes les 1,2 s)
- player_lite.html : 3 relances avant l'erreur, comme les autres pages
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
L'hébergeur des picons du fournisseur (51.158.145.100) répond toujours
503 sur toutes ses URL. Couper le flot de requêtes ne suffisait pas : la
grille restait sans logo. Pire, le pixel transparent servi en 200 était
pris pour une image valide par Flutter, qui n'affichait plus son icône
de repli — d'où des tuiles entièrement vides.
- Nouvelle route `/api/logo?src=…&name=…` : URL du panneau d'abord (via
le proxy, mêmes protections anti-SSRF et même mémoire des hôtes
morts), puis recherche par nom dans le dépôt public tv-logo/tv-logos
- Appariement par nom : préfixe pays et suffixes de qualité ignorés,
`+` → `plus`, variante plus longue (`bein-sports-1-french`), puis
marque sans numéro pour les canaux événementiels. Aucune approximation
sur un mot seul
- Liste de logos en cache 24 h (API GitHub : 60 requêtes/h non
authentifiées), 15 min de recul après échec, images en mémoire
- Image indisponible : 410 mis en cache au lieu du pixel. 410 et non
404 : la Cascade du serveur rattrape les 404 et renvoyait celui du
handler statique, sans cache-control
- Client (grille bureau, mobile, enregistrements) : logo toujours
demandé au backend, nom compris, même sans stream_icon. L'onglet
Enregistrements chargeait l'URL http brute, bloquée en HTTPS
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Logos absents : l'hébergeur des picons du fournisseur répond 503 sur
tout, y compris sa racine (serveur en maintenance). Le proxy relayait
ce 503 au navigateur, qui redemandait chaque logo à chaque affichage de
la grille — des centaines de requêtes sortantes mortes par seconde.
- Un statut >= 400 sur une image rend désormais un pixel transparent
avec `Cache-Control: max-age=600`, au lieu de propager l'erreur
- Après trois échecs consécutifs, l'hôte est marqué hors service cinq
minutes : plus aucun appel sortant, réponse servie localement
- Le corps d'erreur amont est drainé, sinon la connexion restait
ouverte jusqu'au timeout
Guide TV très lent (4 à 8 s par chaîne dans les logs) : `player_api`
demande un appel par chaîne, et le panneau met ~4 s à répondre — une
grille de trente chaînes dépassait la minute.
- Le dump `xmltv.php` du panneau passe en premier : une requête couvre
toutes les chaînes, réutilisée trois heures
- L'interrogation chaîne par chaîne reste le repli, puis la source
XMLTV externe
- Une source XMLTV en échec n'est plus retéléchargée à chaque
consultation : quinze minutes de recul
- Index borné à 48 h en avant : un dump national couvre sept jours pour
un millier de chaînes, soit des centaines de Mo pour un guide qui
n'affiche que le programme courant
Lecture saccadée : le relais FFmpeg -> navigateur de `/turbo.ts` ne
transmettait pas la pause du client à la source. Un lecteur plus lent
que le flux laissait FFmpeg produire à pleine vitesse et le serveur
empilait les paquets en mémoire, d'où la dérive derrière le direct. La
contre-pression est maintenant propagée (`pipeWithBackpressure`).
Le serveur tourne sur un seul isolate : le flot de requêtes mortes et
les attentes EPG de plusieurs secondes partageaient la boucle
d'événements avec les paquets vidéo.
Tests ajoutés : cache d'échecs par hôte, contre-pression du relais,
priorité des sources EPG, recul après échec XMLTV, horizon d'index.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Certains conteneurs ou horodatages ne se prêtent pas à `-c:v copy`.
Plutôt qu'un écran d'erreur définitif là où le ré-encodage fonctionnait
jusqu'ici, la session est relancée une fois sans copie quand la première
tentative ne produit pas de playlist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T1A6WRnoktWcT7ZG4b2rbC
La lecture d'un enregistrement démarrait au milieu du programme et se
coupait aussitôt ; il fallait relancer une deuxième fois pour qu'elle
tienne.
Cause principale, introduite avec le passage de la playlist en `EVENT` :
tant que le transcodage n'est pas terminé, la playlist n'a pas
d'`EXT-X-ENDLIST`, et hls.js traite alors tout contenu comme du direct.
Sans `startPosition` explicite il démarre au « bord du direct » — donc
collé au front d'encodage, sans la moindre avance de segments. D'où un
départ en plein milieu, puis une coupure immédiate. Au second essai, le
transcodage était terminé (ENDLIST présent, contenu traité en VOD) et
tout se passait bien.
Hors direct : `startPosition: 0` (ou la position de reprise), rattrapage
de latence neutralisé (il accélérait la lecture puis forçait un saut en
avant vers un direct inexistant), et délai d'attente de playlist porté de
10 s à 45 s — une session FFmpeg qui démarre n'est plus prise pour un
manifeste mort.
Cause de fond : la lecture ré-encodait la vidéo. Or la capture se fait en
`-c copy`, donc le fichier contient le codec de la chaîne, presque
toujours du H.264, directement lisible en HLS. Le ré-encodage tenait à
peine le temps réel en 1080p, ce qui laissait le lecteur courir après
l'encodeur en permanence. La vidéo est désormais copiée telle quelle
quand elle est en H.264 (seul l'audio est converti en AAC) : la
segmentation va à la vitesse du disque, l'enregistrement devient
navigable en quelques secondes et les sauts ne redémarrent presque plus
jamais FFmpeg. Les codecs que le navigateur ne sait pas lire (HEVC,
MPEG-2…) restent ré-encodés.
En complément :
- le serveur attend trois segments d'avance avant de servir la playlist,
et sert ce qu'il a plutôt qu'une erreur si le délai expire ;
- le lecteur de bureau réessaie seul jusqu'à 3 fois, comme le lecteur
mobile le faisait déjà ;
- `XFPlayer.destroy()` retire ses écouteurs : sans ça, une relance
laissait l'instance précédente réagir aux commandes du parent et
republier des positions périmées ;
- les appels ffprobe passent par `MediaProbe`, qui mémorise durée et
codec tant que le fichier ne change pas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T1A6WRnoktWcT7ZG4b2rbC
La lecture d'un enregistrement ne permettait ni de reculer, ni d'avancer,
ni de reprendre où on s'était arrêté.
Cause côté serveur : la playlist était servie en
`EXT-X-PLAYLIST-TYPE:VOD`. hls.js la considère alors comme définitive et
ne la relit jamais — il ne voyait donc que les quelques secondes déjà
transcodées à l'ouverture, d'où une durée absurde et une barre de
progression inutilisable. Elle passe en `EVENT` : la zone navigable
grandit au rythme de l'encodage.
FFmpeg transcodant séquentiellement, sauter à 45 min imposait malgré tout
d'attendre qu'il y arrive. La playlist accepte donc `?start=<secondes>` et
démarre une session dédiée (`-ss` avant `-i`). Les segments y sont
préfixés par l'offset (`t2700/segment_000.ts`) : la query string ne
survit pas aux URLs relatives de la playlist, deux sessions du même
enregistrement se seraient mélangées. Les sessions d'offsets abandonnés
sont fermées dès qu'aucun lecteur ne les consomme (killIdleSiblings).
Côté lecteur, tout ce qui sort du moteur est désormais en temps absolu
(`offset` réinjecté) : une recherche dans la zone déjà transcodée est un
simple `currentTime`, au-delà le lecteur répond `seek_out_of_range` et
l'app relance le flux à cet instant.
Ajouts visibles :
- reprise proposée à l'ouverture d'un enregistrement entamé, et mention
« Reprendre à … » avec sa progression dans la liste ;
- durée réelle mesurée par ffprobe (`duration_seconds`), mise en cache
tant que le fichier ne bouge pas — `end_time - start_time` n'est que la
durée programmée ;
- sauts ±10 s et ±1 min, sélecteur de vitesse (0,5× à 2×), portion déjà
transcodée visible sur la barre ;
- raccourcis K/espace, J/L, Maj+←/→, 0-9, F, M, virgule/point.
L'identifiant de vue de plateforme porte maintenant un numéro de
génération : sans lui, réutiliser le même identifiant laissait l'ancienne
iframe en place (`registerViewFactory` conserve la première fabrique
enregistrée) — ce qui affectait déjà le retour sur une chaîne
précédemment zappée.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T1A6WRnoktWcT7ZG4b2rbC
L'écran « Échec du chargement : vendor/mpegts.min.js » était un cul-de-sac :
la moindre requête ratée sur la lib condamnait la chaîne, alors que le flux
restait parfaitement lisible autrement.
- xf-player-core : le chargement des libs est retenté une fois en
contournant le cache HTTP (les libs sont servies en max-age=86400, une
entrée tronquée bloquait le lecteur jusqu'au vidage manuel du cache), et
seul un succès est mémorisé — la promesse rejetée restait en cache et
rendait tout réessai impossible pour le reste de la session.
- Repli automatique : si mpegts.js reste introuvable, le live bascule sur la
route HLS équivalente (où FFmpeg réencode déjà l'audio en AAC) ; si hls.js
reste introuvable, on tente le HLS natif. Plus d'écran d'erreur quand un
chemin de lecture est encore disponible.
- Message d'erreur exploitable : la cause réelle est affichée (HTTP 404,
429, réseau injoignable) au lieu d'un échec indifférencié.
- Préchargement corrigé : les trois players préchargeaient hls.js en dur,
soit 618 Ko téléchargés pour rien à chaque zap TV — c'est mpegts.js qui
sert au direct — au détriment du flux et du chargement de mpegts.js
lui-même. Le préchargement suit désormais le flux demandé, avec la même
décision que XFPlayer.start() (et ne charge rien sur Safari/iOS).
- Serveur : avertissement explicite au démarrage si web/vendor/*.min.js
manque, au lieu de laisser le navigateur échouer sans explication.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014FSovdudi3KBwZK3aC42fw
Son manquant sur certaines chaînes :
- Nouvelle route GET /api/live/<id>/turbo.ts pour le player web : vidéo
copiée (-c:v copy), audio TOUJOURS réencodé en AAC. mpegts.js ne démuxe
que l'AAC/MP3 : les chaînes en AC-3/E-AC-3/MP2 passaient par le proxy
brut → image sans son, et le fallback HLS côté client ne couvrait pas
les codecs démuxés mais non décodables par le navigateur (MP2)
- getLiveStreamUrlTs pointe sur la route turbo ; le proxy brut
/api/live/<id>.ts reste inchangé pour le scheduler d'enregistrement
- FFmpeg turbo tué dès que le client zappe (onCancel) ; stderr redacté
- Le fallback client (_hlsEquivalent) reconnaît le nouveau format d'URL
et reste en filet de sécurité
Temps de chargement :
- Players vendorisés mis à jour : hls.js 1.6.7 → 1.7.1,
mpegts.js 1.7.3 → 1.8.2
- Live HLS et turbo : -fflags nobuffer + probesize/analyzeduration 1 Mo
(sans borne, FFmpeg pouvait sonder plusieurs secondes avant le premier
segment)
- VOD : probesize 10 Mo → 5 Mo, analyzeduration 5 s → 2 s
- Live 'high' : preset medium → veryfast (zerolatency déjà actif) ;
lecture d'enregistrement : medium/crf18 → veryfast/crf20 (medium ne
tenait pas le temps réel en 1080p sur CPU modeste)
- waitForPlaylist : polling 500 ms → 100 ms
- Suppression du cache-buster &v=timestamp qui re-téléchargeait
player.html à chaque zap ; les .html sont servis en no-cache côté
serveur pour garder la fraîcheur après déploiement
- mpegts.js : liveBufferLatencyChasing activé en profil « fast » — les
micro-coupures ne font plus dériver la lecture derrière le direct
Validé : dart analyze (0 issue) + dart test (48/48) sur bin/, syntaxe JS
vérifiée.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015oEu9QayWsw7hCKhenxgVa
Lockfiles :
- pubspec.lock et bin/pubspec.lock versionnés (le .gitignore les excluait
via *.lock ; le Dockerfile résolvait des versions fraîches à chaque
build, comme son commentaire l'assumait) ; le Dockerfile les COPY
désormais, .dockerignore ajusté
CI (ci.yml) :
- flutter-version 3.38.4 et Dart 3.13.2 épinglés (channel: stable seul
fait dériver le SDK et peut casser la CI sans changement du dépôt)
- cache pub activé, concurrency: cancel-in-progress
Publication (docker-publish.yml) :
- Chaîné sur la CI via workflow_run : l'image :latest n'est publiée
qu'après analyze/test/build verts sur main (l'ancien push: [main]
tournait en parallèle et pouvait publier une image cassée) ; build du
head_sha validé par la CI
docker-compose :
- Défaut RECORDINGS_PATH: ./data/recordings au lieu du chemin unRAID
spécifique à une machine (/mnt/user/Data/Sport)
- Variable TZ (défaut Europe/Paris)
Docs :
- README réécrit : il décrivait une architecture disparue (Hive/
IndexedDB, hachage SHA-256, dhttpd port 8080, --web-renderer html)
au lieu de l'état réel (SQLite serveur, bcrypt, binaire natif port
8089, enregistrements, transcodage, CI)
- DEPLOYMENT_CHECKLIST.md archivé (6 fichiers cités inexistants,
versions de dépendances fausses)
- docs/archive/README.md : avertissement que ces documents sont
historiques (plusieurs se déclarent « COMPLETE » à tort)
Non traité ici : l'épinglage de la release FFmpeg du Dockerfile (l'accès
aux releases BtbN est bloqué depuis cet environnement, impossible de
vérifier un tag valide) et la suppression du code mort (reportée après le
merge des PRs #7/#8/#9 pour éviter les conflits).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015oEu9QayWsw7hCKhenxgVa
Onglet Enregistrements :
- TabBar à 3 vues : Guide TV (programmer depuis l'EPG), liste des
enregistrements, Season Passes. _EpgGuideView et _SeasonPassesView
(~800 lignes fonctionnelles) n'étaient plus instanciés depuis une
refonte — programmer depuis le guide et les enregistrements
récurrents étaient devenus inaccessibles
- Confirmation avant suppression d'un enregistrement (la corbeille
supprimait immédiatement, sans retour ni annulation)
- Erreur de chargement avec bouton Réessayer
Favoris :
- Bouton cœur sur les tuiles chaînes desktop (overlay) et mobile :
toggleFavorite() n'était appelé nulle part, le filtre « Favoris »
affichait toujours une liste vide
Reprise de lecture :
- Films et épisodes lisent playbackPositionsProvider et passent
startTime au player : les positions étaient écrites mais jamais
relues, tout repartait de zéro
- Plus de sauvegarde de position en live (une entrée bidon par chaîne
zappée)
Mobile :
- 5e onglet REC réutilisant RecordingsTab
- IndexedStack au lieu du switch : les onglets conservent scroll et
catalogues chargés (aligné sur le dashboard desktop)
Dashboard :
- Menu profil sur l'avatar de la sidebar (nom d'utilisateur +
déconnexion) : le bouton était mort, aucune déconnexion possible
depuis le dashboard desktop
- Erreur de chargement des chaînes avec bouton Réessayer
Validé : flutter analyze (202 issues, identique à la baseline main,
0 erreur/warning), flutter test (OK), flutter build web --release (OK).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015oEu9QayWsw7hCKhenxgVa
Proxy /api/xtream :
- Authentification de session rétablie (Authorization ou cookie HttpOnly
session — les requêtes navigateur même-origine le portent) ; le proxy
était volontairement ouvert, offrant un rebond SSRF non authentifié
- Redirections suivies manuellement avec revalidation à chaque saut
(hôte privé interdit + allowlist de domaine) : avec followRedirects,
seule l'URL initiale était validée, une 302 amont suffisait pour
atteindre un hôte interne
- Erreurs proxy sans détail d'exception (ClientException porte l'URL
amont, credentials Xtream inclus), logs redactés
Logs :
- redactedLogRequests remplace logRequests() de shelf : l'URI de
/api/xtream/<url> écrivait username/password Xtream en clair à chaque
requête, annulant l'effort de LogRedactor partout ailleurs
- Les 500 d'epg_api ne renvoient plus e.toString() au client (même
risque ClientException) ; détail redacté en log serveur
Middleware :
- X-Forwarded-For honoré uniquement depuis un proxy de confiance
(loopback + RFC1918 par défaut, surchargables via TRUSTED_PROXIES) :
un client direct forgeait l'en-tête et contournait le rate limit
global comme la limite de tentatives de login
- Honeypot comparé sur chemin exact/préfixe : l'ancien
contains(trap.replaceAll('/','')) bloquait toute URL contenant
console, env ou wpadmin, y compris des URLs proxifiées légitimes
Comptes :
- Mot de passe admin initial aléatoire (Random.secure, affiché une fois
au démarrage) ou ADMIN_INITIAL_PASSWORD ; fini le admin/admin persistant
- Longueur minimale de 8 caractères à la création et au changement
Divers :
- CleanupService ne cible plus Directory.systemTemp en récursif (il
supprimait les temporaires de la VM Dart et le parent des sessions HLS)
- web/xf-player-core.js : postMessage vers location.origin au lieu de
'*', et filtrage d'event.origin à la réception (le côté Flutter le
faisait déjà)
Validé : dart analyze (0 issue) et dart test (48/48) sur bin/.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015oEu9QayWsw7hCKhenxgVa
Fuseaux horaires :
- POST /api/recordings rejette en 400 les dates sans fuseau et normalise
tout en UTC à l'écriture (l'interprétation des dates naïves dans le TZ
du conteneur décalait les enregistrements de 1-2 h)
- Helper frontend unique postRecording() : les 2 points de création
(modal, guide EPG) envoient la même convention UTC
Contrôle d'accès :
- stop/delete/logs d'un enregistrement et delete d'un season pass
vérifient la propriété (userId ou admin), comme playlists_handler
- Suppression des replis 'dev_user_id' et 'admin' (401 sans session)
SQLite :
- PRAGMA foreign_keys/WAL/busy_timeout (les ON DELETE CASCADE déclarés
ne s'appliquaient pas : sessions et playlists orphelines)
- Migrations de schéma versionnées (schema_version) + index user_id,
start_time, season_passes(user_id)
Gestion disque :
- Refus explicite de capture sous MIN_FREE_DISK_MB (défaut 500 Mo)
- Rotation par quota d'octets (RECORDINGS_QUOTA_GB, opt-in) qui ne touche
jamais un enregistrement actif et supprime fichiers + ligne ensemble ;
l'ancienne rotation « 50 fichiers » pouvait effacer une capture en cours
- DELETE /api/recordings/<id> supprime aussi .mkv/.log/parties (SafePath)
Scheduler :
- Arrêt gracieux orchestré par server.dart : clôture des enregistrements
(fusion des parties, statut) avant killAll des sessions de streaming ;
l'ancien handler SIGTERM de FfmpegSessionManager faisait exit(0) direct
- Noms de fichiers uniques par fragment d'id (deux enregistrements du
même programme s'écrasaient mutuellement avec -y)
- Requête filtrée scheduled/recording au lieu de toute la table / 10 s
- Statut cancelled pour un scheduled arrêté (completed sans fichier
cassait la lecture)
Season passes :
- Playlist du propriétaire du pass résolue à chaque scan (l'injection
figée du 1er utilisateur rendait les passes muets après ajout de
playlist, et mélangeait les credentials en multi-utilisateurs)
- Correspondance exacte par défaut (match_mode, migration en 'contains'
pour l'existant), plafond de créations par scan, réalignement des
horaires déplacés dans l'EPG, déduplication tolérante ±2 min
- Redaction des erreurs de scan (ClientException contient l'URL amont)
API de suivi (polling conservé) :
- GET /api/recordings enrichi : progress_pct, file_size_bytes,
retry_count, is_active ; barre de progression + taille dans la liste
Validé : dart analyze (0 issue) et dart test (48/48) sur bin/.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015oEu9QayWsw7hCKhenxgVa
- Nouveau bus de notification (recordingsRefreshBus) : la liste se recharge
immédiatement dès qu'un enregistrement est créé, planifié ou arrêté depuis
n'importe où dans l'app (guide EPG, modal, widget rapide)
- Polling en arrière-plan : 5 s quand un enregistrement est en cours ou
planifié, 20 s sinon, pour suivre les changements de statut sans clic
- Rafraîchissement silencieux (pas de spinner ni de vidage de liste) pour
éviter le clignotement ; les erreurs transitoires ne remplacent pas la liste
- Indicateur « Suivi auto » avec l'heure de dernière actualisation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015oEu9QayWsw7hCKhenxgVa
Chaque enregistrement arrivé au bout de sa fenêtre était marqué
« Échoué / Interruption inattendue du serveur » alors que le fichier était
bien sur le disque : le tick lisait la base AVANT d'arrêter les captures
terminées, si bien que l'instantané annonçait encore « recording » pour un
enregistrement déjà retiré de la table des processus actifs — la détection
d'orphelin le requalifiait aussitôt en échec. La base est désormais lue
après les arrêts, et la requalification revérifie le statut courant.
Deux autres façons de perdre un enregistrement sont corrigées au passage :
- FFmpeg livre encore des morceaux de stderr après la résolution de
`exitCode` ; écrire sur l'`IOSink` déjà fermé levait une `StateError`
depuis un callback de stream, donc une erreur asynchrone non rattrapée
qui tue l'isolate — et avec lui le serveur et toutes les captures en
cours. Le log passe par un écrivain tolérant et n'est fermé qu'une fois
stdout et stderr drainés.
- Une coupure amont terminait la capture définitivement. FFmpeg reçoit
maintenant les options de reconnexion (comme le proxy live), et le
planificateur relance la capture sur la fin de fenêtre quand le process
sort trop tôt (backoff 3→30 s, quota remis à zéro après une capture
saine). Les parties issues des relances sont recollées dans le fichier
principal via le demuxer `concat`, la lecture reste donc un seul fichier.
Également :
- reprise des captures interrompues par un redémarrage du conteneur tant
que la fenêtre est ouverte, au lieu d'un échec sec ; fichier partiel
conservé (statut « terminé ») quand la fenêtre est passée
- `-t` calculé sur le temps restant jusqu'à la fin programmée : un
démarrage tardif ne rogne plus la fin du programme
- `-hide_banner -nostats` : le log d'enregistrement redevient lisible (et
ne pèse plus des mégaoctets, il est relu en entier par l'API)
- `RECORDINGS_DIR` et `FFMPEG_PATH` surchargeables, et le motif d'erreur
est effacé au (re)démarrage d'une capture
Vérifié avec un faux ffmpeg sur un planificateur réel : avant correctif,
un enregistrement mené jusqu'à la fin de fenêtre ressort « failed /
Interruption inattendue du serveur » ; après, « completed » — de même que
la reprise après interruption, la relance après coupure et la fusion des
parties.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E5xWYTbtZwJuYB3E51K243
MichaelandClaude Opus 5.5
LogiFlow
MichaelandClaude Opus 5