Cette page lit l’état de la production vidéo. Elle demande un compte administrateur.
Chargement de l’état de la production…
Ils ne changent rien à la série passée : ils écrivent les commandes ci-dessous. Le régime et la règle sont repris de la série reçue, pour que la relance reparte dans les mêmes conditions que l’échec.
L’API ne transporte que la série en cours : dès qu’elle est remplacée, ses échecs disparaissent de cette page. Collez ici la sortie du studio, ou le CSV exporté par le journal des erreurs, pour en tirer les mêmes verdicts et les mêmes commandes. Le texte collé ne quitte jamais votre navigateur : il n’est envoyé ni au site, ni au studio, ni à un service tiers. Il est lu sur place, par cette page, et il disparaît quand vous fermez l’onglet. Rien n’en est enregistré, pas même sur cette machine.
La série lance le studio dans un sous-processus, depuis la racine du
dépôt. Les commandes de cette page reproduisent cet appel : c’est
pourquoi elles portent --sans-soustitres, que la série
passe elle aussi, et pourquoi elles s’écrivent
python3 studio/… et non python3 … depuis le
dossier du studio.
--silencieux, que la série impose. Une vidéo relancée
seule dit donc tout ce qu’elle a tu pendant la série : c’est le seul
remède aux motifs qui n’expliquent rien.--minutes appartient à serie.py, qui coupe
le sous-processus, pas à studio.py. Un échec au temps
imparti peut donc aboutir sans qu’on change quoi que ce soit.studio/_atelier/lecture.json
a été réécrit depuis, la relance s’arrêtera à cette barrière.serie.py qui
appelle le moteur d’écriture entre les deux moitiés. Une vidéo morte
avant sa rédaction se reprend donc mieux par une série d’une unité.Le studio ne dépose pas de code d’erreur : il dépose, pour chaque vidéo arrêtée, une ligne de texte libre. Le verdict de reprise est donc lu dans ce texte, par mots-clefs. C’est une hypothèse de cette page, pas une donnée du studio, et elle peut se tromper : le motif exact reste affiché sous chaque verdict, et c’est lui qui fait foi.