Quven Server ya funciona en un contenedor Docker

Un contenedor parece una caja neutra hasta que algo necesita el hardware. El servidor arranca, la biblioteca se analiza, las comprobaciones de estado están en verde y entonces la primera película necesita una transcodificación y resulta que la tarjeta gráfica solo existe fuera del contenedor. En ese momento estás leyendo sobre permisos de dispositivos en lugar de ver algo.

No queríamos que la compatibilidad con Docker significara que Quven arrancaba por casualidad dentro de una imagen. El contenedor debe comportarse como cualquier otro Quven Server: detectable en la red doméstica, vinculado a la misma cuenta, conservando su estado entre reinicios, respetando la biblioteca y capaz de indicar qué componente de hardware realiza el trabajo. Ya es público.

No queríamos publicar solo una imagen

Un registro acepta cualquier cosa que llegue al final de una compilación, y eso por sí solo no la convierte en una versión publicada. La imagen de Quven se construye para Linux AMD64 y ARM64, se publica bajo una única coordenada versionada, se firma con Cosign y se acompaña de una atestación SPDX, y el manifiesto público registra el resumen criptográfico del índice de la imagen y de cada plataforma, que es el detalle que permite demostrar qué se está ejecutando. Eso importa el día en que un contenedor se vuelve a crear en otra máquina, porque una etiqueta de versión te dice lo que pediste y un resumen criptográfico te dice lo que realmente llegó.

El entorno de Compose apunta a la etiqueta latest, y es una decisión deliberada. docker compose pull y docker compose up -d llevan cada versión y sus correcciones a tu servidor, mientras que un número de versión fijado impediría que una corrección posterior llegara a él. Seguirás sabiendo qué versión llegó, ya que cada manifiesto registra su resumen criptográfico.

La biblioteca entra, pero no se entrega

Un contenedor es fácil de sustituir y una biblioteca personal no lo es, y la configuración predeterminada parte de esa diferencia. Quven guarda su base de datos y su configuración en un volumen persistente, con los registros al lado. El directorio multimedia es el único lugar en el que escribe dentro de tu biblioteca, y lo único que deposita allí es un subtítulo que ha generado para una película, junto a esa película, mientras el propio proceso se ejecuta sin capacidades de Linux, no puede elevar sus propios privilegios y ve un sistema de archivos raíz de solo lectura. Nada de eso puede volver seguro un anfitrión mal administrado. Pero ofrece a una instalación corriente unos límites razonables antes de que nadie haya pensado en reforzarla.

Y el ciclo de vida sigue sin sobresaltos. Vuelve a crear el servicio y el estado sigue ahí. Cambia la imagen y las rutas de los archivos multimedia no se mueven. Vuelve a la versión anterior, y el resumen criptográfico previo sigue designando exactamente lo que se ejecutaba antes.

La aceleración por hardware no es una sola casilla

¿Ve un contenedor la tarjeta gráfica del anfitrión? No por sí solo. NVIDIA, VA-API y V4L2 exponen interfaces distintas, y la decodificación HEVC de la Raspberry Pi usa la API Request sin estado, que es una cuarta, así que un único montaje de dispositivos que pretende cubrirlas todas parece cómodo y falla con el primer archivo difícil.

Por eso el paquete publicado trata los perfiles de hardware como alternativas. Empieza con el servicio básico. Si la reproducción por procesador ya cubre tu biblioteca, puedes detenerte ahí. Si el anfitrión tiene una interfaz que has comprobado, añade el perfil de NVIDIA, Intel/AMD o ARM correspondiente, solo con los dispositivos que necesita. Un valor que falta provoca un error antes del arranque en lugar de exponer en silencio todo /dev. Es menos cómodo que un interruptor accelerate=true, pero mucho más fácil de entender cuando algo cambia después de una actualización del núcleo o de un controlador.

Probado con la imagen pública

Para ARM64 descargamos exactamente la imagen pública multiarquitectura en una Raspberry Pi 4, vinculamos un servidor real y transmitimos mediante HLS autenticado, con los perfiles de Compose publicados, los mismos que descargarías tú. La decodificación y la codificación H.264 pasaban por V4L2, y una fuente HEVC usaba el decodificador Request de la Pi con codificación H.264 por hardware y producía aproximadamente un segundo y medio de salida por cada segundo medido, mientras que en una reproducción manual más larga el búfer se mantenía claramente por delante de quien miraba. Aunque la Pi es un ordenador pequeño y económico, sus bloques de hardware realizaban el trabajo para el que se diseñaron.

Pero otra placa ARM o un NAS pueden exponer interfaces distintas, y la guía lo indica: comprueba qué está realmente activo en la máquina antes de elegir un perfil.

Descarga una versión publicada, no una promesa

El camino rápido es corto a propósito. Descarga el archivo de Compose y la plantilla de entorno, apunta QUVEN_MEDIA_DIR a la biblioteca y después valida la configuración, iníciala y vincula el servidor. Los perfiles de hardware opcionales vienen después, uno por familia de hardware, así que solo ejecutas los comandos que corresponden a tu máquina.

La imagen corresponde a la edición Solo servidor. Los clientes nativos siguen ofreciendo la experiencia local, y con Pro el cliente web alojado puede llegar a un servidor vinculado a través del relé gestionado. Docker cambia el lugar donde vive el servidor y nada más. Empieza por la descarga de Docker en la página de descargas de Quven y sigue después la guía completa de instalación con Docker.

Preguntas frecuentes