Jellyfin 12: cómo arreglar Error loading configuration file encoding.xml
Índice de contenidos
- Puntos clave
- Error loading configuration file: /config/config/encoding.xml en Jellyfin 12
- ¿Por qué Jellyfin 12 no puede leer EncoderPreset?
- ¿Qué versiones de Jellyfin tienen el fallo?
- Cómo he reproducido el error
- Arreglo 1: actualiza directamente a la 12.2
- Arreglo 2: cambia la línea de encoding.xml a mano
- Si ya arrancaste la 12.0 o la 12.1
- ¿Cómo compruebo que no se ha restablecido la transcodificación?
- Preguntas frecuentes
- ¿Pierdo la biblioteca o los usuarios con este error?
- ¿Watchtower me puede meter en este problema?
- ¿Afecta a otros ficheros de configuración?
- Conclusión
- Fuentes
El error Error loading configuration file: /config/config/encoding.xml de Jellyfin 12.0 y 12.1 lo provoca la línea EncoderPreset xsi:nil que la 10.11 escribe por defecto. El servidor arranca, pero vuelve a la transcodificación por defecto y pierde QSV. Pasa a la 12.2 antes de migrar o cambia esa línea por auto.
El aviso Error loading configuration file: /config/config/encoding.xml de Jellyfin 12.0 y 12.1 lo causa una sola línea, <EncoderPreset xsi:nil="true" />, y se arregla cambiándola por <EncoderPreset>auto</EncoderPreset> o actualizando directamente a la 12.2. El servidor arranca igual, pero descarta todo encoding.xml y lo reescribe con los valores de fábrica: la aceleración por hardware Intel Quick Sync Video (QSV), los hilos y la calidad desaparecen sin más aviso que esa línea del registro. Lo reproduje el 18 de octubre de 2026 en Docker 29.5.2, migrando una 10.11.11 a la 12.1 y a la 12.2. Si todavía no has actualizado, empieza por la guía para actualizar Jellyfin 12 con Docker. Tienes la versión en inglés de este arreglo.
Puntos clave
- Una instalación limpia de la 10.11.11 ya escribe
<EncoderPreset xsi:nil="true" />enencoding.xml: no hace falta haber tocado nada para que te afecte. - La 12.0 y la 12.1 no saben leer ese valor, registran el error con
'' is not a valid value for EncoderPresety sobrescriben el fichero con los valores por defecto un segundo después. - La 12.2, publicada el 5 de octubre de 2026, añade la migración
FixNullEncoderPreset, que cambia el valor nulo porautoantes de cargar el fichero. - Si ya arrancaste la 12.0 o la 12.1, la 12.2 no te devuelve los ajustes: hay que restaurar
encoding.xmlde la copia, editado, o volver a escribirlos. - Restaurar el
encoding.xmlantiguo sin editar sobre una 12.2 ya migrada vuelve a dar el mismo error, porque la migración solo se ejecuta una vez.
Error loading configuration file: /config/config/encoding.xml en Jellyfin 12
El error significa que Jellyfin no ha podido convertir el fichero de opciones de transcodificación en su objeto de configuración. Es un [ERR], no un fallo fatal, así que el contenedor queda sano y /health devuelve 200. Estas son las líneas exactas que escribió la 12.1 al arrancar sobre la configuración de una 10.11.11:
[ERR] [8] Emby.Server.Implementations.AppBase.BaseConfigurationManager:
Error loading configuration file: /config/config/encoding.xml
System.InvalidOperationException: There is an error in XML document (30, 35).
---> System.InvalidOperationException: Instance validation error: ''
is not a valid value for EncoderPreset.
at Microsoft.Xml.Serialization.GeneratedAssembly.
XmlSerializationReaderEncodingOptions.Read6_EncoderPreset(String s)
En tu terminal cada línea sale entera; aquí las he partido para que quepan. La posición (30, 35) apunta a la línea 30 de encoding.xml, que es justo la de EncoderPreset. En la imagen oficial de Docker la ruta es /config/config/encoding.xml; en una instalación con paquete de Debian o Ubuntu, el directorio de configuración es /etc/jellyfin, y la incidencia original lo cita como /config/encoding.xml.
Para saber si tu servidor lo ha escrito, busca la línea en el registro del contenedor:
docker compose logs jellyfin 2>&1 | grep -A2 "Error loading configuration"
¿Por qué Jellyfin 12 no puede leer EncoderPreset?
Porque el tipo del campo cambió entre versiones y nadie migró los ficheros existentes. En la 10.11, EncoderPreset admitía un valor nulo, y el serializador del lenguaje de marcado extensible (XML) de .NET lo guarda como xsi:nil="true". La PR #17007, fusionada el 3 de junio de 2026, lo convirtió en obligatorio para que la web dejara de mostrar el campo vacío tras una instalación limpia.
El valor por defecto nuevo solo se aplica a objetos creados desde cero, no a un fichero que ya existe. Lo resumió el usuario dotspencer en la incidencia #17861:
When it’s unset, configs serialize it as
xsi:nilwhich no longer deserializes and there’s no migration. The constructor default only covers newly constructed objects and not an existing file.
Comprobé que el valor nulo es lo normal y no una rareza: arranqué una 10.11.11 sin configurar nada y su encoding.xml ya traía <EncoderPreset xsi:nil="true" />. Solo se libran los servidores en los que alguien eligió un valor en el desplegable Encoding preset.
¿Qué versiones de Jellyfin tienen el fallo?
El fallo aparece al saltar de la 10.11.x a la 12.0 o a la 12.1, y desaparece en la 12.2. Estas son las versiones implicadas y lo que pasa con un encoding.xml de la 10.11 que trae el valor nulo:
| Versión | Publicada | Con EncoderPreset nulo |
|---|---|---|
| 10.11.11 | 6 de junio de 2026 | Lo escribe así por defecto |
| 12.0 | 8 de septiembre de 2026 | Error y ajustes a valores de fábrica (incidencia #17861) |
| 12.1 | 15 de septiembre de 2026 | Error y ajustes a valores de fábrica (probado) |
| 12.2 | 5 de octubre de 2026 | Lo cambia a auto y conserva los ajustes (probado) |
La 12.2 incluye 51 cambios, y el arreglo es la PR #18059 de scr4bble, fusionada el 27 de septiembre en la rama release-12.z. A 18 de octubre de 2026, las etiquetas latest, 12 y 12.2 de Docker Hub apuntan a la misma imagen (sha256:357724bf), así que quien sigue latest ya la tiene.
Cómo he reproducido el error
Monté la 10.11.11 en un proyecto de Compose desechable sobre Linux arm64, completé el asistente y cambié por la API (interfaz de programación) nueve opciones de transcodificación. Dejé EncoderPreset sin tocar, igual que cualquier servidor en el que nadie ha abierto ese desplegable. Después paré el contenedor, guardé /config en un tar.gz de 30 KB y lo extraje en carpetas separadas para cada prueba.
Al arrancar la 12.1 sobre la primera copia, el error salió en el primer segundo, y a las 11:45:46 la 12.1 ya había reescrito encoding.xml con los valores por defecto. La API confirmó lo mismo que el fichero:
| Opción | 10.11.11 | 12.1 sin arreglo | 12.2 o fichero editado |
|---|---|---|---|
HardwareAccelerationType |
qsv |
none |
qsv |
QsvDevice |
/dev/dri/renderD128 |
vacío | /dev/dri/renderD128 |
H264Crf |
20 |
23 |
20 |
EncodingThreadCount |
4 |
-1 |
4 |
EnableThrottling |
true |
false |
true |
HardwareDecodingCodecs |
h264, hevc, vp9, av1 | h264, vc1 | h264, hevc, vp9, av1 |
Las nueve opciones volvieron a su valor de fábrica: también ThrottleDelaySeconds, AllowHevcEncoding y EnableTonemapping. No hay copia del fichero antiguo junto al nuevo, así que lo que tenías solo vive en tu copia de seguridad.
Arreglo 1: actualiza directamente a la 12.2
Si aún estás en la 10.11, salta la 12.0 y la 12.1 y cambia la etiqueta a 12.2. Antes, haz la copia de /config con el servidor parado, como pide la documentación de Jellyfin porque no hay mecanismo para volver atrás. Con la carpeta del compose de la guía de instalación de Jellyfin con Docker, el cambio es este:
docker compose stop jellyfin
sudo tar -czf jellyfin-10.11.11.tar.gz config
sed -i 's|jellyfin/jellyfin:10.11.11|jellyfin/jellyfin:12.2|' compose.yaml
docker compose pull -q jellyfin
docker compose up -d
El sudo hace falta porque la imagen oficial corre como root y los ficheros de config son suyos. En el primer arranque, la 12.2 escribió estas tres líneas y ningún error:
[INF] InternalCodeMigration: Perform migration
20260915104305_FixNullEncoderPreset
[INF] Jellyfin.Server.Migrations.Routines.FixNullEncoderPreset: Replaced
null encoder preset with auto in encoding configuration
[INF] InternalCodeMigration: Migration
20260915104305_FixNullEncoderPreset was successfully applied
El fichero quedó con <EncoderPreset>auto</EncoderPreset> y las nueve opciones de la tabla anterior intactas.
Arreglo 2: cambia la línea de encoding.xml a mano
Si por algún motivo tienes que quedarte en la 12.0 o la 12.1, edita el fichero antes de su primer arranque. Es el arreglo que propuso scr4bble en la incidencia, y con él la 12.1 cargó la configuración sin error y con QSV conservado. Para el contenedor y cambia la línea:
docker compose stop jellyfin
grep -n EncoderPreset config/config/encoding.xml
30: <EncoderPreset xsi:nil="true" />
sudo sed -i \
's|<EncoderPreset xsi:nil="true" />|<EncoderPreset>auto</EncoderPreset>|' \
config/config/encoding.xml
grep -n EncoderPreset config/config/encoding.xml
30: <EncoderPreset>auto</EncoderPreset>
auto es el mismo valor que la 12.2 escribe en su migración y el que muestra el desplegable por defecto. Si el grep devuelve un valor como veryfast o medium, tu fichero no tiene el problema y no hay que tocar nada. Cuando la 12.2 arranca sobre un fichero ya editado, ejecuta la migración igual pero no escribe la línea Replaced null encoder preset, porque no encuentra nada que cambiar.
Si ya arrancaste la 12.0 o la 12.1
En ese caso el fichero ya está sobrescrito y actualizar a la 12.2 no recupera nada. Lo probé arrancando la 12.2 sobre la copia que había pasado por la 12.1: la migración se aplicó y la API siguió devolviendo none en la aceleración por hardware y 23 en la calidad.
Tienes dos salidas. Si guardaste /config antes de actualizar, saca solo encoding.xml de la copia, edita la línea y arranca:
docker compose stop jellyfin
sudo tar -xzf jellyfin-10.11.11.tar.gz config/config/encoding.xml
sudo sed -i \
's|<EncoderPreset xsi:nil="true" />|<EncoderPreset>auto</EncoderPreset>|' \
config/config/encoding.xml
docker compose up -d
No te saltes el sed. Restaurar el fichero antiguo tal cual sobre una 12.2 ya migrada repitió el error exacto, porque FixNullEncoderPreset está marcada como aplicada y no vuelve a ejecutarse. Con la línea editada, la 12.2 cargó QSV, H264Crf 20 y los 4 hilos de la 10.11.
La otra salida es volver a configurarlo a mano en Dashboard > Playback > Transcoding (rótulos de la interfaz en inglés). Un usuario de la incidencia lo arregló así: volvió a elegir QSV y reinició. Si haces copias del volumen con el método de la guía de copias de seguridad de volúmenes Docker, puedes extraer el fichero de la misma forma.
¿Cómo compruebo que no se ha restablecido la transcodificación?
Haz tres comprobaciones después del primer arranque de la 12: el registro, el fichero y la API. La primera es el grep de la sección del error, que no debe devolver nada. La segunda mira las líneas que más se notan si se pierden:
grep -nE "HardwareAccelerationType|QsvDevice|H264Crf|EncoderPreset" \
config/config/encoding.xml
13: <HardwareAccelerationType>qsv</HardwareAccelerationType>
16: <QsvDevice>/dev/dri/renderD128</QsvDevice>
28: <H264Crf>20</H264Crf>
30: <EncoderPreset>auto</EncoderPreset>
La tercera pregunta al servidor qué valores tiene cargados, que es lo que de verdad usa al transcodificar. Necesitas una clave de API creada en Dashboard > Advanced > API Keys:
curl -s -H 'Authorization: MediaBrowser Token="tu_clave_de_api"' \
http://localhost:8096/System/Configuration/encoding \
| grep -oE '"(HardwareAccelerationType|H264Crf|EncoderPreset)":"?[^,"]*"?'
"HardwareAccelerationType":"qsv"
"H264Crf":20
"EncoderPreset":"auto"
Si ves "none" donde tenías qsv, vaapi o nvenc, tus ajustes se han restablecido. Compáralos con el encoding.xml de tu copia antes de dar la actualización por buena.
Preguntas frecuentes
¿Pierdo la biblioteca o los usuarios con este error?
No. El error afecta solo a encoding.xml, las opciones de transcodificación. En mis pruebas, la base de datos migró con normalidad, el token de la 10.11 siguió valiendo y el servidor respondió con 200 en /health. Lo que se pierde es la configuración de transcodificación, y con ella la aceleración por hardware.
¿Watchtower me puede meter en este problema?
Sí, si tu contenedor sigue latest y Watchtower actualiza los contenedores entre el 8 de septiembre y el 5 de octubre de 2026. En ese intervalo, latest apuntaba a la 12.0 o la 12.1. Hoy latest es la 12.2, pero si la 12.0 o la 12.1 llegaron a arrancar, tus ajustes ya se perdieron y toca la sección de recuperación.
¿Afecta a otros ficheros de configuración?
En mis registros, encoding.xml fue el único con Error loading configuration file. system.xml sí cambió en la migración, pero por otro motivo: la 12 pone EnableLegacyAuthorization a false, como explica la guía de actualización a Jellyfin 12.
Conclusión
Error loading configuration file: /config/config/encoding.xml no tumba Jellyfin 12, pero se lleva tu transcodificación sin avisar más que con una línea [ERR]. Si estás en la 10.11, salta directamente a la 12.2 con la copia de /config hecha. Si ya pasaste por la 12.0 o la 12.1, saca encoding.xml de la copia, cambia EncoderPreset a auto y arranca. Después comprueba la aceleración por hardware en el fichero o en la API, no solo en el registro.
Fuentes: [1] Jellyfin, incidencia 17861 sobre encoding.xml[1], [2] Jellyfin, PR 18059 con la migración FixNullEncoderPreset[2], [3] Jellyfin, PR 17007 que hace obligatorio EncoderPreset[3], [4] Jellyfin, notas de la versión 12.2[4], [5] Docker Hub, etiquetas de jellyfin/jellyfin[5], [6] Documentación de Jellyfin, copia de seguridad y restauración[6], [7] Documentación de Jellyfin, aceleración por hardware[7].
Fuentes
- Jellyfin, incidencia 17861 sobre encoding.xml
- Jellyfin, PR 18059 con la migración FixNullEncoderPreset
- Jellyfin, PR 17007 que hace obligatorio EncoderPreset
- Jellyfin, notas de la versión 12.2
- Docker Hub, etiquetas de jellyfin/jellyfin
- Documentación de Jellyfin, copia de seguridad y restauración
- Documentación de Jellyfin, aceleración por hardware
Código fuente
Accede a todo el código fuente de este artículo en GitHub.
Ver en GitHub