Running Plex Media Server (official plexinc/pms-docker image) on Unraid 7.x with a large library (~39k media parts / 60k items). Deep Media Analysis, Credits detection, and Intro detection all run continuously via Butler — the scanner processes complete cleanly with no errors in their logs and consume real CPU — but the results never get written back to the database. media_analysis_version stays at 0 for every item, no matter how many times it's reprocessed. Backlog of ~20,800 items hasn't meaningfully shrunk over 8+ hours of continuous activity.

Already ruled out (each independently tested):

- Container restart — no change

- CPU pinning (tried both unrestricted 20-thread and a reduced 12-thread cpuset) — no change

- Read-only vs read-write media mount — no change

- Downgrading to the previous Plex point release — same behavior

- Full database restore from a known-good 1-day-old Butler backup — identical symptom reproduced immediately

- A real PRAGMA integrity_check using Plex's own bundled SQLite binary — returned "ok", no corruption

During a manual "Database optimization" run, the main log showed a concrete error for the first time:

SQLITE3:0x80000001, 17, statement aborts at 63: [select * from metadata_items limit 1] database schema has changed

(SQLite error 17, SQLITE_SCHEMA)

Given how thoroughly this reproduces regardless of Docker/host config, I suspect it's a Plex-internal bug (possibly related to how many concurrent scanner subprocess connections it opens against one large library DB), but wanted to check: has anyone else on Unraid with a large library seen this exact "scanner completes but DB never updates" pattern? Any storage/filesystem-level angle I haven't considered?

Full write-up with all diagnostics on the Plex forums: https://forums.plex.tv/t/deep-media-analysis-credits-intro-detection-never-persists-results-media-analysis-version-stays/942280

Setup: btrfs NVMe pool (not /mnt/user), CPU pinned 8-19, Docker with --device=/dev/dri passthrough for hardware transcoding.

Update: One more data point — checked our other backlog counters (Credits, Intro, Chapter Thumbnails), and unlike Deep Media Analysis (completely stuck), those three are almost fully complete (Credits ~14,750 of 39,380 remaining, Intro ~2,800 remaining, Chapter Thumbnails only 5 remaining). These evidently did complete successfully over the weeks since our QNAP→Unraid migration, before whatever's currently broken set in.

So this might not be a blanket "nothing ever persists" issue — could be specific to the Deep Media Analysis code path, or something that broke more recently after the other three had already mostly finished their backlogs.

Update: Tested this directly — manually triggered GenerateIntroMarkers while Deep Analysis was frozen, and watched the Intro backlog counter drop from 2813 to 2811 in real time (2 items processed and persisted successfully). So Credits/Intro/Thumbnail generation genuinely still works right now, live — it's specifically Deep Media Analysis that's stuck. Re-enabled Credits/Intro generation, kept only Deep Media Analysis/Upgrade Media Analysis disabled.

This narrows it down further: whatever's broken is specific to the Deep Media Analysis code path, not a general "nothing persists" database issue.

Update: Ran the full ChuckPa PlexDBRepair.sh (v1.17.01) "auto" sequence (Check → Repair/Optimize → Reindex → FTS check) with Plex stopped, in an isolated temporary container.

Found something concrete this time: all 4 FTS4 full-text search indexes in the main database are damaged —

fts4_metadata_titles, fts4_metadata_titles_icu, fts4_tag_titles, fts4_tag_titles_icu — all reporting "Error: stepping, database disk image is malformed (11)". (The equivalent indexes in the blobs database are fine.)

Notably, the tool itself printed: "Temporary Patch: FTS Rebuilding disabled as of PMS 1.43.x and Plex discussions until resolved." — so this appears to be a known, currently-unresolved issue specific to 1.43.x that's already being discussed with Plex directly.

The rest of the repair (export/reimport/reindex of the main tables) completed successfully and reported clean. After restarting Plex on the repaired database and re-testing Deep Media Analysis on a fresh item: same result as every previous attempt — item completes, media_analysis_version stays at 0, backlog unchanged.

So this doesn't appear to be the direct cause of our specific persistence bug (or at least, everything fixable by DBRepair being fixed didn't resolve it), but it's a real, independently confirmed corruption that Plex's own PRAGMA integrity_check doesn't catch, and ties directly to what sounds like a known open issue for this version. Wanted to document it here in case it's a useful data point for anyone else, or for Plex to connect the dots.

Final update: Also tested this on an older major version (1.42.2.10156, ~11 months old) to see if downgrading past the 1.43.x line (where the FTS rebuild patch applies) would bypass ChuckPa's FTS-rebuild guard and let us test whether fixing the FTS corruption resolves the Deep Analysis issue.

Turns out the guard isn't version-conditional at runtime — it's a blanket disable in the current DBRepair.sh release regardless of which PMS version you're running against, so we couldn't get a clean FTS rebuild either way.

Ran the same Deep Analysis persistence test on 1.42.2.10156 anyway (with the DB in the same post-repair, FTS-still-damaged state): identical result — item completes, media_analysis_version stays at 0, no persistence.

So across everything tested tonight (versions 1.43.3.10896, 1.43.3.10861, and now 1.42.2.10156; with/without the FTS corruption "fixed" as much as currently possible; full DB rebuild via .recover; fresh backup restore) — the exact same failure every time. About as thorough a bisection as I can do from the client side. Reverted back to the current release (1.43.3.10896) since there's no reason to stay on an 11-month-old build. Hoping this saves someone some diagnostic time if they hit the same thing.

Update: Credits detection persistence issue extends beyond the corrupt file

Follow-up to my earlier post about the corrupt file (moov atom not found) — after excluding that specific file, I found the problem is broader than I initially thought:

• 3,889 media parts currently carry a pv:creditsDetectionErrorCount in extra_data but have never received a successful pv:credits marker.

• The last genuinely successful Credits marker write (with real MediaPartMarkersArray data) was at 04:08 today — over 8 hours ago at time of writing.

• Since then, every triggered Credits detection attempt (multiple, manually verified via DB queries) completes its scanner subprocess with no FFmpeg/parse errors at all, yet still fails to persist a result — only the internal pv:creditsDetectionErrorCount increments.

• This affects entirely healthy, playable files (verified via direct file inspection), not just corrupted ones.

This looks like the same underlying persistence bug that affects Deep Media Analysis, just also intermittently hitting Credits detection — not purely a “one corrupt file blocks the queue” issue as I first assumed.

You are going to want to take a visit over to the Plex Support Forums for help with this as it's not unraid related.

My guess is your database is corrupt. If the Chuck PA script didnt work to repair the database, you will likely need to start over with a new one.