¿Por qué desaparece el acceso a la transcodificación por hardware después de actualizar un contenedor?
La transcodificación por hardware suele desaparecer después de una actualización porque el contenedor recreado ya no ve el mismo dispositivo, grupo de permisos, capacidad del entorno de ejecución o conjunto de software de usuario compatible.
Es posible que la GPU del host siga funcionando mientras Plex, Jellyfin, Emby o una aplicación de cámaras cambien silenciosamente a la CPU después de reemplazar la imagen. La primera tarea es demostrar si el dispositivo existe dentro del contenedor nuevo y si el usuario del servicio puede abrirlo; después, hay que separar la asignación del entorno de ejecución y los permisos de una regresión específica de códecs o controladores de la imagen.
Confirma que la carga de trabajo realmente cambió al modo de software
Fuerza la reproducción de un archivo que requiera transcodificación y registra el panel del servidor multimedia, el registro de FFmpeg o del transcodificador, el uso de la CPU del host y la actividad del motor de la GPU. La reproducción directa no prueba la ruta de hardware.
Un caso de la comunidad de LinuxServer recomienda comprobar un indicador de hardware explícito y la telemetría de la GPU, ya que la actividad de la CPU por sí sola puede resultar engañosa. El indicador decisivo es el uso activo del motor de la GPU durante una transcodificación controlada.
Si los registros muestran que el codificador de hardware se abre correctamente, investiga los filtros no compatibles, los subtítulos, el mapeo de tonos o la aceleración parcial. Si no se puede abrir el dispositivo, continúa con la detección del host y el acceso desde el contenedor.
Compara los dispositivos de la GPU en el host y dentro del contenedor
Enumera los nodos de dispositivo esperados en el host y dentro del contenedor actualizado. Para VA-API de Intel o AMD, compara /dev/dri/card* y /dev/dri/renderD*; para NVIDIA, compara la visibilidad del entorno de ejecución y los dispositivos que informa su herramienta de administración.
Un caso de Quick Sync en Unraid muestra que el host puede necesitar el módulo de kernel correcto antes de que exista /dev/dri, y que el contenedor también necesita que se le pase ese dispositivo. El límite que falta suele ser la asignación del dispositivo /dev/dri, no la biblioteca multimedia ni la base de datos de la aplicación.
Si el dispositivo no está presente en el host, repara primero el controlador, la BIOS, el kernel o el estado del hardware del host. Si existe en el host pero no dentro del contenedor, compara la configuración de dispositivos generada por Compose o por la interfaz anterior y la actual.
Verifica el acceso a los grupos render y video
Registra los ID numéricos del propietario y del grupo de los nodos de dispositivo de la GPU en el host; después, inspecciona los grupos asignados al usuario del servicio dentro del contenedor. Los nombres como render pueden corresponder a ID numéricos distintos entre imágenes.
Un caso de resolución de problemas de Jellyfin en Docker muestra una configuración funcional que iguala explícitamente el ID del grupo render del host y comprueba los permisos de renderD128. Esa asignación numérica del grupo render puede cambiar cuando una imagen modifica sus usuarios o grupos internos.
Añade el grupo suplementario necesario mediante la definición del contenedor en lugar de hacer que el dispositivo sea escribible para todos. Recrea el contenedor y prueba el acceso como el usuario real del servicio multimedia.
Comprueba las opciones del entorno de ejecución y las capacidades específicas de la imagen
Compara las definiciones de la imagen anterior y la actual para revisar devices, group_add, la configuración del entorno de ejecución de la GPU, las variables de capacidades, el modo privilegiado y cualquier cambio en las plantillas del administrador de contenedores.
Un informe sobre Emby describe cómo la aceleración por hardware dejó de funcionar en Docker mientras la aplicación seguía disponible, lo que ilustra el cambio al modo de software después de perder la GPU, que hace que este problema sea fácil de pasar por alto.
No resuelvas un problema limitado de acceso al dispositivo concediendo acceso privilegiado amplio. Restaura únicamente los permisos mínimos de dispositivo y grupo necesarios para la ruta del codificador.
Distingue una regresión de la imagen del contenedor de un fallo del host
Ejecuta una prueba sencilla de GPU o FFmpeg en el contenedor actualizado y compárala con la imagen anterior fijada, usando los mismos montajes, asignaciones de dispositivos, archivo multimedia y configuración de la aplicación.
Si la imagen anterior funciona de inmediato y la nueva falla con un estado idéntico del entorno de ejecución, conserva los registros y considera la actualización como una posible regresión del software de usuario, los códecs, FFmpeg o la aplicación. No reescribas los permisos repetidamente cuando la comparación controlada de imágenes ya haya aislado la versión responsable.
Limpia únicamente las cachés de códecs regenerables documentadas cuando los registros apunten a ellas, y no modifiques la base de datos de la aplicación ni los metadatos multimedia. Fija la imagen que sabes que funciona hasta comprender o corregir la regresión.
Valida toda la canalización después de la reparación
Prueba la decodificación por hardware, la codificación, el mapeo de tonos, la incrustación de subtítulos y al menos un cliente que fuerce la transcodificación. Confirma que el dispositivo de GPU esperado aparece en los registros y que el host muestra actividad sostenida del motor.
El procedimiento de ZimaSpace para verificar una transcodificación real por hardware ofrece una prueba de finalización más sólida que un interruptor en la página de configuración.
El problema solo está resuelto cuando el contenedor actualizado o fijado conserva el acceso al dispositivo después de recrearse y reiniciarse, utiliza la GPU para la ruta de códec prevista y deja de cambiar silenciosamente al modo de software. Conserva el resumen de la imagen anterior y la definición del entorno de ejecución como límite de reversión para la próxima actualización.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
