Perché in Docker il sottotitolo di Quven è altrove

Questa settimana un tester che usa Quven Server in Docker su Ubuntu ci ha scritto con una domanda a cui non avevamo ancora risposto pubblicamente, ed è una domanda giusta. Aveva chiesto al player un sottotitolo per un film che ne era privo, e il server lo ha generato dal parlato, il player lo ha elencato come generato dall’audio e lo ha riprodotto senza intoppi. Poi ha aperto la cartella del film sull’host, aspettandosi di trovare il file dei sottotitoli accanto al video, e la cartella era vuota. Dov’era finito? Accanto al film non era mai stato scritto.

La risposta era nel log del server, in due righe consecutive. La prima dice che il sottotitolo generato è stato salvato per il flusso audio scelto, e la seconda è un avviso secondo cui la copia portabile di un sottotitolo trascritto non ha potuto essere scritta, per cui il server si tiene la propria nel suo archivio. Sotto c’è il motivo: IOException: Read-only file system, su un percorso dentro /media.

Due copie, e ne serve una sola

Quando Quven produce un sottotitolo, conserva il risultato in un archivio suo. In un’installazione normale quell’archivio sta nella cartella dei dati dell’applicazione, e nel container sta dentro il volume quven-data. Tutti i client riproducono il sottotitolo da lì, ed è per questo che il player del tester lo elencava e lo riproduceva senza problemi.

A parte, il server prova a scrivere una seconda copia accanto al video, come un normale file a fianco, e anche se Quven stesso non la rilegge, quella copia serve a te. Permette al testo di viaggiare con il film se sposti la cartella su un’altra macchina o la passi a qualcuno che Quven non lo usa. Se non si può scrivere, il server registra l’avviso di cui sopra e va avanti. Un’impostazione per questo non esiste. La riproduzione ne è del tutto indipendente.

Vale per ogni sottotitolo che Quven produce, in qualunque modo sia stato prodotto: una traccia tradotta in un’altra lingua, un sottotitolo grafico riconosciuto in testo e una traccia che hai corretto nell’editor delle battute seguono tutti la stessa strada, salvati nel volume dei dati e copiati accanto al film quando la cartella lo permette.

Perché la cartella non lo permetteva

Il file Compose pubblicato fino alla 1.1.21 monta i tuoi media con read_only: true, ed era una scelta voluta: è la garanzia che il server può catalogare e riprodurre la libreria senza poterne modificare un byte, qualunque cosa succeda dentro il container. Ma quella riga blocca anche la copia accanto al film, e la guida ora descrive sia la copia sia l’impostazione che la controlla.

Cosa abbiamo cambiato

Dalla 1.1.22 il file Compose pubblicato monta i tuoi media in modo che quella copia possa arrivare. La garanzia non è sparita, è passata nelle tue mani: QUVEN_MEDIA_READ_ONLY=true nel tuo .env richiude il montaggio, e siccome quell’impostazione si trova in un file che non sovrascriviamo mai, sopravvive all’aggiornamento successivo. Cancellare una riga da compose.yaml non lo faceva, dato che la guida ti chiede di riscaricare quel file a ogni versione.

Due cose vale la pena saperle comunque tu lo lasci. Il container gira con l’utente 10001, quindi la cartella dei media sull’host deve essere scrivibile da quell’uid, altrimenti la copia fallisce di nuovo, stavolta con un errore di permessi invece che di file system in sola lettura, cioè lo stesso sintomo con un messaggio diverso nel log. E Quven continua a non toccare i tuoi file video. Quello che scrive accanto a loro è il sottotitolo che ha fatto per te, con il nome del film a cui appartiene, ed è l’unica cosa che abbia mai scritto dentro la cartella di una libreria e l’unica che scriverà nella tua.

Se usi un pacchetto più vecchio

Apri compose.yaml e togli la riga read_only: true sotto il bind dei media. Rendi la cartella scrivibile dall’uid 10001 e ricrea il container con docker compose up -d. Aggiornare fa la stessa cosa senza la modifica, e continua a farla, cosa che una modifica a un file che riscarichi a ogni versione non può garantire.

Domande frequenti