Docker : où est passé le sous-titre généré ?

Un testeur exécutant Quven Server dans Docker sous Ubuntu nous a écrit cette semaine avec une question que notre documentation laissait jusqu’ici sans réponse, et elle est parfaitement légitime. Il avait demandé au lecteur un sous-titre pour un film qui en était dépourvu, le serveur en avait produit un à partir des dialogues, le lecteur l’avait présenté comme généré depuis la piste audio, et la lecture s’était déroulée correctement. Ensuite, il avait parcouru le dossier du film sur la machine hôte pour y rechercher le fichier de sous-titres à côté de la vidéo : il demeurait introuvable. Où était-il passé ? Il n’avait jamais été enregistré à côté du film.

Le journal de son serveur contenait l’explication, répartie sur deux lignes consécutives. La première indique que le sous-titre généré a été enregistré pour le flux audio choisi, et la seconde est un avertissement précisant que la copie portable d’un sous-titre transcrit n’a pas pu être écrite, le serveur conservant la sienne. Dessous apparaît la cause : IOException: Read-only file system, sur un chemin situé sous /media.

Deux copies, mais une seule est indispensable

Lorsque Quven produit un sous-titre, il garde le résultat dans son propre espace de stockage. Sur une installation ordinaire, cet espace réside dans le dossier de données de l’application, et dans le conteneur il se trouve à l’intérieur du volume quven-data. Chaque client lit le sous-titre depuis cet emplacement, ce qui explique que le lecteur du testeur ait affiché la piste et l’ait jouée sans difficulté.

Parallèlement, le serveur essaie d’écrire une seconde copie à côté de la vidéo, sous la forme d’un fichier annexe ordinaire. Quven lui-même ne relit jamais cette copie, mais elle existe pour votre bénéfice : le texte peut ainsi accompagner le film lorsque vous déplacez le dossier vers une autre machine, ou lorsque vous le confiez à une personne qui se passe de Quven. Si l’écriture échoue, le serveur consigne l’avertissement cité plus haut et poursuit son travail. Aucun réglage ne concerne cette copie, et la lecture ne dépend d’elle d’aucune manière.

Le même fonctionnement s’applique à chaque sous-titre produit par Quven, quel que soit son mode de production : une piste traduite dans une autre langue, un sous-titre d’image reconnu comme texte et une piste corrigée dans l’éditeur de sous-titres suivent tous le même parcours, enregistrés dans le volume de données puis copiés à côté du film lorsque le dossier l’autorise.

Pourquoi le dossier l’a interdit

Le fichier Compose publié jusqu’à la version 1.1.21 monte vos médias avec read_only: true, et cette décision était délibérée. Elle constitue la garantie que le serveur peut cataloguer et lire votre bibliothèque tout en étant incapable de modifier un seul octet, quoi qu’il arrive à l’intérieur du conteneur. Cependant, cette ligne interdit aussi la copie annexe, et le guide décrit désormais la copie ainsi que le réglage qui la gouverne.

Ce que nous avons modifié

À partir de la version 1.1.22, le fichier Compose publié monte vos médias de façon que la copie puisse aboutir. La garantie n’a pas disparu : elle est passée entre vos mains, car QUVEN_MEDIA_READ_ONLY=true dans votre propre fichier .env referme le montage, et puisque ce fichier est l’un de ceux que nous n’écrasons jamais, le réglage survit aux mises à jour suivantes. Supprimer une ligne de compose.yaml n’a jamais offert cette durabilité : le guide demande de télécharger ce fichier à chaque nouvelle version.

Deux précisions méritent d’être retenues, quelle que soit votre décision. Le conteneur s’exécute sous l’utilisateur 10001 : le répertoire multimédia de l’hôte doit donc autoriser l’écriture à cet identifiant, faute de quoi la copie échouera de nouveau, cette fois avec une erreur de permission plutôt qu’une erreur de lecture seule, c’est-à-dire le même symptôme accompagné d’un autre message dans le journal. Par ailleurs, Quven laisse toujours intacts vos fichiers vidéo. Ce qu’il écrit à côté d’eux est le sous-titre fabriqué à votre intention, portant le nom du film correspondant, unique contenu qu’il ait jamais déposé dans un dossier de bibliothèque et unique contenu qu’il déposera dans le vôtre.

Avec un ancien ensemble de fichiers

Ouvrez compose.yaml et supprimez la ligne read_only: true située sous le montage des médias. Rendez le répertoire accessible en écriture pour l’identifiant 10001, puis recréez le conteneur avec docker compose up -d. La mise à jour produit le même résultat sans intervention manuelle et continuera de le produire, ce qu’une modification d’un fichier retéléchargé à chaque version ne peut garantir.

Questions fréquentes