Plex Credits Detection Fails

Plex Media Server
, , ,
1

Hi all,

As several of you already experienced, I Do also have a problem with the local credits detection failing for almost 50% of my library.

Here is my Bug report and What I have already checked so far

Credits Detection: silent pipe failure (BufferingLineReader) — detailed reproduction across ~1900 files, ruled out several common causes

Server Version#: 1.43.3.10896-cb3ebc72d (Docker, LinuxServer.io image)
Platform: Debian 13 VM under Proxmox/QEMU, 12 vCPU (host has i7-8700T, 6C/12T), storage on USB HDDs (~230 MB/s sequential, verified)

Symptom

CreditsDetectionManager fails for the vast majority of locally-analyzed items (titles that don’t get a marker via online provider match) with:

[CreditsDetectionManager] BufferingLineReader: failed to read line (error: -1)
[CreditsDetectionManager] Credits detection for item <id> has failed too many times, we will not retry again.

The child process (Plex Media Scanner) always reports exit code 0 in the parent log — but the pipe read still fails. No exception, no stack trace, no OpenCV error (checked explicitly — see below).

Scale of the problem

Out of ~3900 TV episodes in one library, 1961 have a non-zero creditsDetectionErrorCount in the DB (media_parts.extra_data), and the failure count caps at 5-6 before Plex gives up permanently on that item. Only items matched against Plex’s online marker database (popular mainstream shows) succeed — those complete in milliseconds and never touch the local pipeline.

What we ruled out (each tested directly against affected files)

  1. Audio channel layout (5.1(side) vs 5.1) — remuxed a batch of files to force standard 5.1 tagging via -channel_layout. Made no difference; also discovered 5.1(side) is an inherent AC3/EAC3 labeling quirk in ffmpeg, not something remuxing can actually change.
  2. PGS (image-based) subtitles — 100% of failing HEVC/MKV files had PGS subs vs ~72% of successful ones, looked like a strong correlation. Removed the PGS track via stream-copy remux on a fresh (never-before-analyzed) file — still failed, same symptom.
  3. Corrupted TensorFlow model (model_v1.pb) — found a forum report (_Velop, May 2026) with an explicit OpenCV ReadTFNetParamsFromBinaryFileOrDie parse error on a 16MB (should be ~96.7MB) model file. Checked ours: 94,398 KB, essentially correct size. grep -i opencv across the main log AND the per-job Plex Media Scanner Credits*.log files returns zero hits — this specific failure mode does not appear to be present here.
  4. Missing AVX2 in the VM (CPU type x86-64-v2-AES, no AVX2) — hypothesized this could cause a silent SIGILL in an AVX2-optimized inference build. Changed Proxmox CPU type to host (confirmed avx2 now present in /proc/cpuinfo), rebooted the VM — failure persists, same file, timing even slightly longer than before (34s vs ~20s).
  5. Storage throughput — verified ~230 MB/s sequential read (post cache-drop) on the affected drive. Not a bottleneck for a ~300MB episode.
  6. Fixed timeout theory — failures consistently occurred ~15-34s after job start across hundreds of different files (different codecs, resolutions, bit depths, containers), which initially looked like a hardcoded timeout. However wall-clock time is not constant enough (15s vs 34s on the same file after a CPU change) to be a fixed timeout — more consistent with a crash that occurs after a fixed amount of work (e.g., a fixed frame count reaching a specific code path), with wall time varying by CPU throughput.

What the per-job log shows

The dedicated Plex Media Scanner Credits.log shows the thumbnail-extraction ffmpeg pass completing cleanly every time:

[FFMPEG] - [out#0/image2 @ ...] video:1231kB audio:0kB ...
[FFMPEG] - frame=   67 fps= 16 q=1.6 Lsize=N/A time=00:02:12.00 bitrate=N/A speed=31.4x

…and then nothing else is ever written to that log before the parent reports the pipe read failure ~15-20s later. No OpenCV/TensorFlow log lines, no error, no crash message — the child appears to vanish mid-stream from the parent’s perspective without writing anything about whatever comes after thumbnail extraction (presumably the actual OCR/black-frame model inference stage).

Manual reproduction attempt

Tried invoking the exact same Plex Media Scanner command from the log manually inside the container (with and without X_PLEX_TOKEN set) — both attempts exit immediately (code 0) with what looks like an encrypted/base64 protocol response instead of performing any analysis. This suggests the scanner process depends on inherited file descriptors/IPC state from the parent’s JobRunner that a manually-spawned process doesn’t have, so it can’t be reproduced this way for further debugging (e.g., under strace/gdb).

Question for Plex

Given the exit code is always 0 and no error is logged anywhere (main log, per-job log), is there a way to get more verbose output from the credits detection subprocess specifically (beyond DEBUG level), or a way to run it with a debugger attached, to see what’s actually happening between “thumbnail extraction done” and “pipe closes unexpectedly”? Happy to provide full logs, DB extracts, or test further if it helps track this down — this affects a large fraction of a personal library with no workaround found despite extensive testing.

Thankful for any help, especially from the Devs themselves.