Entender

Metadatos en el fichero

Por qué Styx guarda el título, los ids externos y la portada dentro del propio vídeo, cuándo lo hace y cuándo no.

Especificado. Esta página describe el comportamiento objetivo. El diseño está en dec-0126, lockeado el 2026-10-02 junto con dec-0127, que lo enmienda. Todavía no hay código. Lo que dice obliga a la implementación.

La idea

Cuando añades una película a la biblioteca, Styx la identifica por su contenido (dec-0114). Después, el plugin propio metadata-embed busca sus metadatos y su portada, y Styx los escribe dentro del fichero. No crea ficheros aparte (.nfo, poster.jpg). El fichero se describe a sí mismo: si lo mueves, lo renombras, lo copias a otro servidor o pierdes la base de datos, Styx lo reconoce otra vez sin conexión a Internet.

Por eso el servidor es semi-stateless respecto al fichero:

Vive en el fichero (reconstruible)Vive sólo en el servidor (necesita backup)
título, fecha, géneros, sinopsis, serie, temporada y episodiolo que has visto y por dónde vas, por perfil
ids externos: IMDb, TMDb, TheTVDBvaloraciones, listas y colecciones manuales
tipo (película o episodio), edición y locks manualescola de revisión e historial de cambios
portadafondos y resto del artwork

Nada tuyo viaja en el fichero: ni datos de usuario, ni de perfil, ni de hogar, ni rutas. Sólo metadatos públicos de la obra.

Dónde se escriben

  • MP4 (lo habitual en una biblioteca normalizada): en moov/udta/meta/ilst. Son los items de siempre (©nam, ©day, ©gen, desc, tvsh, tvsn, tves, stik), con la portada en covr. Los ids externos van como items libres ---- en el espacio dev.mks2508.styx, con los nombres y formatos de Matroska.
  • Matroska / WebM: en Tags (SimpleTag con TargetTypeValue 50 para la película o el episodio, y 60 y 70 para la temporada y la serie), con IMDB (tt…), TMDB (movie/… o tv/…) y TVDB2. La portada va en Attachments como cover.jpg, siguiendo la convención de matroska.org.

Los navegadores ignoran estas cajas. Un MP4 con metadatos se reproduce en Chrome exactamente igual que sin ellos.

Quién escribe y cómo

  • El plugin decide qué se escribe: una proyección pura del catálogo a tags.
  • catalog-svc decide cuándo.
  • El daemon Zig escribe los bytes:
    • el JavaScript nunca toca el fichero de vídeo (r01);
    • la apertura es relativa a la raíz y sin symlinks (dec-0117 I7);
    • cada escritura exige una capability de un solo uso con scope annotate, ligada al fichero y al plan exacto.

Hay dos modos de escritura:

  1. In-place sobre padding (el normal). Si el fichero tiene espacio reservado (una caja free en MP4, o el añadido al final con SeekHead en MKV), sólo cambian unos KB de metadatos.
    • No se mueve ni un byte del vídeo.
    • Antes de escribir, el daemon guarda en un journal los bytes que va a pisar. Si se corta la luz a mitad, al arrancar los restaura.
    • Después de escribir, verifica que el contenido sigue siendo idéntico; si no, deshace.
  2. Reescritura (sólo si la raíz lo permite con allowRewrite). Se escribe un fichero nuevo al lado, con padding para el futuro, se verifica y se sustituye de forma atómica. Cuesta leer y escribir el fichero entero una vez, en segundo plano y sin competir con la reproducción.

Cuándo no se escribe

Incrustar viene activado en las raíces que gestiona Styx (ingesta, canónicas, creadas desde la UI). En una biblioteca que ya tenías, el asistente te ofrece activarlo y no se activa sin tu sí. Aun activado, Styx no escribe:

  • en fuentes remotas (Storage Box, WebDAV, S3, HTTP, Jellyfin, Xtream): ahí el catálogo guarda los metadatos, y se incrustan cuando Styx escribe el fichero (al subirlo o al promoverlo);
  • en raíces o montajes de sólo lectura;
  • en ficheros que se están sembrando o que tienen hardlinks (nlink > 1), porque cambiar un byte rompe el torrent o la copia enlazada;
  • si la identificación no es segura: sólo con confianza alta o confirmada por ti;
  • encima de tags que puso otra herramienta sin pasar por la adopción de Modelo de datos.

Identidad que no cambia

La huella de contenido que identifica un asset se calcula sobre el vídeo y el audio (mdat en MP4, Clusters en MKV) y sobre los datos de códec. Deja fuera los tags, la portada y el padding. Incrustar metadatos no cambia la identidad del asset y no obliga a re-identificarlo.

Si vienes de Jellyfin

Los .nfo de Jellyfin se importan. Su uniqueid de TMDb o IMDb identifica la película con total confianza. Si la raíz tiene el embed activo, lo importado acaba dentro del fichero. Styx nunca borra ni modifica tus .nfo.

Preparar la biblioteca

Si tu flujo de normalización deja el MP4 con moov delante y una caja de padding, la primera incrustación ya es in-place, también en un 4K x265. Si no, styx library prepare hace una pasada única que reserva el padding.

Decidido en el lock

  • El fichero es la fuente de verdad y el catálogo un índice derivado (dec-0127). Ver Modelo de datos.
  • Dentro del fichero sólo va la portada vertical en bytes. El resto del artwork va por referencia.
  • Vienen activados los proveedores que no necesitan clave, y el primer arranque te pide la de TMDb.