Saltar a contenido

Plex: optimización, acceso solo local para video y Fire TV (2026-10-24)
Pedido Arreglar los cortes al transcodificar películas 4K con TrueHD, aprovechar el T7 y revisar la configuración de Plex
Resultado Configuración en el SSD, transcodificación en el T7, video solo por la red local y las dos Fire TV reproduciendo 4K TrueHD y los openings AV1
Scripts scripts/nas-arranque/plex-optimizar.sh (cambio único) y respaldo-nocturno.sh (incluye Plex)

Cambios en el servidor

Antes Ahora Por qué
Configuración y base de datos (3 GB) en el HDD sdb, compartido con Docker En el SSD (/DATA/ssd-appdata/plex, enlace desde /media/HDD-Storage/AppData/plex) Había 88 consultas lentas en 3 horas; en el SSD, casi ninguna
Transcodificación en /run/plex-temp, dentro de la capa del contenedor (HDD al 70 %), y TranscoderTempDirectory apuntando a una ruta que no existía /transcode → /DATA/t7/plex-transcode (create_host_path: si el T7 no está, usa el SSD) Un 4K REMUX con TrueHD acumula 40–60 GB de segmentos por sesión
Imagen :latest lscr.io/linuxserver/plex:1.43.5.11029-6bf8af3f0-ls329 Que no se actualice sola
IPv4 + IPv6 Solo IPv4 (IPNetworkType=ipv4) IPv6 está apagado en el NAS
Escaneo cada 15 min + detección de cambios Escaneo diario + detección de cambios Lecturas del HDD sin necesidad
Caché de base de 100 MB 512 MB Hay 15 GB de RAM
Las apps conocían IP de DHCP que cambian customConnections = http://192.168.68.61:32400, https://plex.cruzcloud.net:443 El NAS tiene tres IP (.61 fija; .55 y .56 por DHCP)
Relay de Plex activo RelayEnabled=0 El video no sale de la red local

La GPU no se usa

/dev/dri está pasado al contenedor y el i3-8100 tiene Quick Sync, pero las estadísticas de transcodificación muestran transcodeHwRequested="0": hace falta Plex Pass. Todo se transcodifica por CPU. Por eso es clave que los clientes copien el video y solo se convierta el audio.

Video solo en la red local, música también por el dominio

plex.cruzcloud.net (Nginx Proxy Manager → Plex) tiene este bloque en Advanced del proxy host:

# --- plex.cruzcloud.net: por el dominio publico SOLO musica (2026-10-24) ---
location ~* ^/video/ { return 403; }
location ~* ^/library/parts/[0-9]+/[0-9]+/file\.(mkv|mp4|m4v|avi|mov|ts|m2ts|webm|wmv|mpg|mpeg|flv|iso)$ { return 403; }
location ~ /\.(?!well-known) { return 404; }

Se probó primero en un nginx descartable (13 casos) y después desde afuera: la web da 200, file.mp3 da 401 (pasa y Plex pide sesión), el video da 403 y /.git/config o /.aws/credentials dan 404. Esas rutas son las que buscó un escáner automático el mismo día.

Fire TV: la configuración que funciona

Opción de la app (Configuración → Video) Valor
Permitir reproducción directa Prendida
Permitir transmisión directa Prendida
Forzar reproducción directa Apagada
Passthrough HDMI

Con las dos prendidas, la app decide por archivo:

Contenido Qué pasa Carga en el NAS
Openings / trailers en AV1 o VP9 (YouTube) Reproducción directa: la Fire TV 4K Max decodifica AV1 Ninguna
Películas 4K HEVC con TrueHD Atmos La app pide directPlay=0: el video se copia y el audio pasa de TrueHD a EAC3 Baja (solo el audio)

Síntomas de una configuración mala

Configuración Síntoma Por qué
Reproducción directa prendida, transmisión directa apagada Las películas con TrueHD no arrancan; la app crea la cola y a los 5–20 s se detiene sin pedir nada al servidor La app intenta TrueHD por su cuenta y se rinde
Transmisión directa apagada Los openings AV1 4K60 arrancan, se traban y se paran Plex transcodifica el video AV1 → H.264 por CPU (libx264, 370 % de CPU, menos que tiempo real)

Después de cambiar la configuración: forzar la detención de la app (Configuración de la Fire TV → Aplicaciones → Plex) y, si sigue raro, borrar la caché.

Qué cliente usar para cada cosa

Cliente 4K HEVC Dolby Vision + TrueHD Atmos AV1/VP9 (openings)
App de Plex de la LG OLED55CX (webOS) Reproducción directa completa: el audio TrueHD llega sin pérdida (eARC) y el NAS no transcodifica nada —
Fire TV Stick 4K Max Video copiado, audio TrueHD → EAC3 (convierte el NAS) Reproducción directa

Verificado el 2026-10-25: Michael desde la LG se reprodujo con decision=direct play, sin ningún proceso Plex Transcoder y con /transcode vacío.

Cómo se diagnosticó

  1. Ver qué pide el cliente, en el log de Plex (Logs/Plex Media Server.log): 
    grep -E "Request: \[192.168.68.53.*(playQueues|universal/decision|library/parts)" "Plex Media Server.log"
    Si hay POST /playQueues y después state=stopped sin ninguna decision ni library/parts, el cliente se rinde antes de pedir el video: es un problema del cliente.
  2. Ver qué decidió Plex: Reached Decision ... decision=... Video=(decision=copy|transcode).
  3. Ver con quién habla el cliente (descarta problemas de red): 
    docker run --rm --net=host --cap-add NET_RAW alpine sh -c \
  'apk add -q tcpdump && timeout 150 tcpdump -i any -nn -q "host <IP-cliente> and not port 53"'
  4. Comparar con la última vez que funcionó, sobre todo los parámetros directPlay, directStream y directStreamAudio del pedido decision.

Lección

Antes de sospechar del servidor (IP, formatos, subtítulos), hay que pedir la configuración del cliente y el mensaje de error en pantalla, y compararlos con la última reproducción buena. En este caso se descartaron tres hipótesis del lado del servidor antes de mirar el cliente.

Pendientes

  • La reserva del Deco (30:9C:23:E0:7D:93 → .61) no toma: el Deco sigue dando la .55 aun pidiendo IP desde cero. No afecta a Plex, porque las apps usan la .61.
  • Los originales de las fotos de Immich (313 GB) no tienen respaldo. Se resuelve con discos nuevos.