Un buon container sparisce. Ora Quven Server vive lì dentro.

Il momento peggiore per scoprire che un container non è una scatola neutra è subito dopo avere premuto Play. Il server parte, la libreria viene letta e tutti gli health check sono verdi, e poi il primo film richiede una transcodifica, la GPU esiste soltanto fuori dal container e un’installazione ordinata diventa una serata passata a leggere permessi dei device.

Non volevamo che il supporto Docker significasse soltanto che Quven riusciva ad avviarsi dentro un’immagine. Doveva comportarsi come un vero Quven Server: farsi trovare in casa, collegarsi allo stesso account, conservare il proprio stato, trattare la libreria con cautela e dire con chiarezza quale hardware stesse lavorando.

Quella versione ora è pubblica.

Non volevamo pubblicare soltanto un’immagine

In un registry può finire quasi tutto ciò che arriva in fondo a una build, e non per questo diventa una release. L’immagine Quven è costruita per Linux AMD64 e ARM64, riunita sotto un’unica coordinata versionata, firmata con Cosign e accompagnata da un’attestazione SPDX. Il manifest pubblico registra sia il digest dell’image index sia quello di ogni piattaforma.

Può sembrare cerimonia da supply chain, finché un container non viene ricreato su una macchina diversa. Un tag dice cosa hai chiesto. Un digest dice cosa è arrivato davvero. Pubblichiamo entrambi perché anche un server domestico merita di saper spiegare che cosa sta eseguendo.

Il bundle Compose segue la stessa regola. È legato a una release pubblicata invece che a un tag latest in movimento, così un riavvio non può trasformarsi di nascosto in un aggiornamento.

La libreria entra, ma non viene consegnata

Un container si sostituisce facilmente. Una libreria personale no. La configurazione predefinita nasce da queste due verità.

Quven conserva database, configurazione e log in un volume persistente. La cartella dei media è l’unico posto in cui scrive dentro la tua libreria, e l’unica cosa che ci mette è un sottotitolo che ha generato per un film, accanto a quel film. Il processo gira senza capability Linux, non può elevare i privilegi e vede un filesystem radice in sola lettura. Nulla di questo rende magicamente sicuro un host amministrato male, ma dà a un’installazione normale confini sensati prima ancora che il proprietario debba pensare all’hardening.

Rende anche il ciclo di vita piacevolmente noioso. Ricrei il servizio e lo stato è ancora lì. Cambi immagine e i percorsi dei media non si spostano. Torni indietro e il digest precedente continua a indicare esattamente ciò che funzionava prima.

L’accelerazione hardware non è una casella

Una GPU non diventa utile a un container soltanto perché compare nella scheda tecnica dell’host. NVIDIA, VA-API e V4L2 espongono interfacce diverse. Il decode HEVC del Raspberry Pi usa la stateless Request API, che è ancora un’altra strada. Fingere che un solo device mount le copra tutte produce configurazioni comode da leggere e fragili al primo file difficile.

Il bundle pubblicato tratta quindi i profili hardware come alternative, non come passaggi di una checklist. Parti dal servizio base. Se il playback CPU copre già la libreria, fermati lì. Se l’host espone un’interfaccia verificata, aggiungi il profilo NVIDIA, Intel/AMD oppure ARM corrispondente e soltanto i device che gli servono. I valori mancanti bloccano l’avvio invece di esporre in silenzio tutto /dev.

È meno magico di un interruttore accelerate=true. È anche molto più semplice da capire quando qualcosa cambia dopo un aggiornamento del kernel o dei driver.

Abbiamo provato l’immagine pubblica, non quella del banco

Il percorso ARM64 doveva dimostrare più di un’etichetta di architettura. Abbiamo scaricato sul Raspberry Pi 4 l’esatta immagine pubblica multi-architettura, collegato il server reale, riprodotto via HLS autenticato e usato i profili Compose pubblicati invece di un comando privato da laboratorio.

Decode e encode H.264 hanno lavorato tramite V4L2. Una sorgente HEVC ha usato il decoder Request del Pi e l’encode hardware H.264, mantenendo circa un secondo e mezzo di output per ogni secondo misurato. Nella prova manuale più lunga, il buffer si è portato molto avanti rispetto alla visione. Resta un piccolo computer economico, non una workstation, ma i blocchi hardware stavano facendo il lavoro per cui esistono.

Questa evidenza appartiene alla configurazione Pi 4 che abbiamo provato. Non trasforma ogni scheda ARM o NAS nella stessa macchina, e la guida lo dice. Il supporto hardware va dimostrato dalle interfacce attive, non dedotto dal logo sul case.

Scarica una release, non una promessa

Il percorso rapido è volutamente corto: scarica il file Compose versionato e il template dell’ambiente, indica a QUVEN_MEDIA_DIR dove si trova la libreria, valida, avvia e collega il server. Le strade opzionali arrivano dopo e sono separate per famiglia hardware, così nessuno deve eseguire comandi che non appartengono alla propria macchina.

L’immagine è Server-only. I client nativi continuano a offrire l’esperienza locale premium, mentre il web client hosted raggiunge un server collegato attraverso il relay gestito con Pro. Docker cambia il luogo in cui vive il server; non cambia ciò che Quven è.

Parti dal riquadro Docker nella pagina Download, poi segui la guida completa all’installazione Docker. Il container dovrebbe essere la parte meno memorabile della serata film.

Domande frequenti

Perché pubblicare anche il digest oltre al tag di versione?

Il tag dice cosa hai chiesto; il digest dice cosa è arrivato davvero. Nel manifest pubblico ci sono entrambi, per l’image index e per ogni piattaforma, così un container ricreato su un’altra macchina si può dimostrare essere lo stesso.

Il container può toccare i miei media?

Solo per mettere accanto al film un sottotitolo che ha generato, e QUVEN_MEDIA_READ_ONLY=true nel tuo .env ferma anche quello. Il processo gira senza capability Linux, non può elevare i privilegi e vede un filesystem di root in sola lettura, mentre database, configurazione e log stanno in un volume persistente che sopravvive alla ricreazione del servizio.

La transcodifica hardware funziona su un Raspberry Pi?

Sul Pi 4 che abbiamo provato sì: decodifica e codifica H.264 sono passate da V4L2, e una sorgente HEVC ha usato il decoder Request del Pi con codifica hardware H.264, sostenendo circa un secondo e mezzo di uscita per ogni secondo misurato. Quell’evidenza appartiene a quella configurazione e non rende uguale ogni board ARM o NAS.