Shim crash (segfault / "Invalid uuid length") after successful migration + multiple migration issues

[abcattell91]

Environment

Platform: Unraid 6.12.54
Docker image: ghcr.io/cgnl/plex-postgresql-linuxserver:latest (v1.2.0)
Plex version: 1.43.0.10492-121068a07 (baked into image)
PostgreSQL: postgres:15-alpine (separate container)
Library size: 108,556 metadata items, 71,550 blobs
Connection: TCP via host IP (Plex on Host networking, PostgreSQL on bridge with port 5432 mapped)

Summary
Migration completed successfully (all 33 tables, 108,556 items, 71,550 blobs) but Plex crashes immediately on startup with a segfault / Invalid uuid length exception. The shim initialises fully but Plex dies before the shim can write anything to its log file.

Issue 1 — Shim crash after successful migration (BLOCKER)
After full migration, Plex crash-loops on every startup:
[SHIM_INIT] Constructor complete (Linux, PID 769)
libc++abi: terminating with uncaught exception of type std::domain_error: Invalid uuid length
****** PLEX MEDIA SERVER CRASHED

Shim loads and completes constructor
Plex crashes before the shim writes anything to plex_redirect_pg.log (file is 0 bytes)
All data verified present in PostgreSQL (108,556 metadata_items, all library_sections with valid UUIDs, Preferences.xml has valid MachineIdentifier)
Running under gdb shows a segfault with no debug symbols:

Fatal signal: Segmentation fault
----- Backtrace -----
0x4d3574 ???
0x5cb4f9 ???
0x5cb68a ???
...

Crash occurs on Plex 1.43.0 (the version baked into the image) — not caused by auto-update
Crash also occurs on 1.43.1 (when VERSION=docker triggers auto-update)

Note: The crash may be related to our varchar(255) workaround (see Issue 2) — we had to ALTER columns to text and drop/recreate fts4_metadata_titles and fts4_metadata_titles_icu views. The views were recreated as:
sqlCREATE VIEW plex.fts4_metadata_titles AS SELECT id AS rowid, title, title_fts FROM plex.metadata_items;
CREATE VIEW plex.fts4_metadata_titles_icu AS SELECT id AS rowid, title, title_fts FROM plex.metadata_items;
These may not match the original view definitions exactly, which could contribute to the crash.

Issue 2 — varchar(255) columns cause silent migration failure on metadata_items
The PostgreSQL schema defines several columns on metadata_items as character varying(255):

guid
title
title_sort
original_title
studio
content_rating

SQLite has no length limits, so real-world Plex databases can have values exceeding 255 characters. In my case:

guid column: A file-based GUID exceeded 255 chars:

file:///data/media/movies/Borat%20Cultural%20Learnings%20of%20America%20for%20Make%20Benefit%20Glori...

title column: An anime episode title exceeded 255 chars:

Let Your Eyes Behold the Glory and Mystery of the Brothel with a Perfect Score! Take a Newlywed or a...
PostgreSQL rejects the entire COPY operation, causing all 108,556 rows to fail. Migration reports FAIL but continues with other tables.
Suggested fix: Change all varchar(255) columns on metadata_items (and potentially other tables) to text in plex_schema.sql. SQLite uses text for everything, so there's no reason to impose length limits.

Issue 3 — Migration errors piped to /dev/null
In migrate_lib.sh, the migration call suppresses stderr:
bashif python3 "$migrate_py" ... 2>/dev/null; then
When metadata_items failed, the only output was FAIL — no indication of why. The actual PostgreSQL error (value too long for type character varying(255)) was only visible in the PostgreSQL container logs, which took significant debugging to discover.
Suggested fix: Log stderr to a migration log file instead of discarding it:
bashif python3 "$migrate_py" ... 2>>"$LOG_DIR/migration_errors.log"; then

Issue 4 — pg_trgm extension not created before schema load
The schema SQL references gin_trgm_ops for an index, but the pg_trgm extension isn't created before loading the schema. This causes an error on first run:
psql:/usr/local/lib/plex-postgresql/plex_schema.sql:4040: ERROR: operator class "plex.gin_trgm_ops" does not exist for access method "gin"
Suggested fix: Add CREATE EXTENSION IF NOT EXISTS pg_trgm; to the entrypoint before loading plex_schema.sql.

Issue 5 — Entrypoint drops and recreates schema on every restart when it considers DB "empty"
When metadata_items fails to migrate, the summary reports Total items in PostgreSQL: 0 even though 32 other tables migrated successfully. On the next container start, the entrypoint sees "0 items", considers the database empty, drops the schema, and re-runs the full migration — wiping out any manual fixes (like ALTERing column types).
This creates a frustrating loop where:

Migration fails on metadata_items
User manually fixes the schema (e.g. ALTER varchar to text)
Container restarts, drops schema, recreates with varchar(255), migration fails again

Suggested fix: Don't use metadata_items count as the sole indicator of whether data exists. Check multiple tables, or add a migration state flag.

Issue 6 — VERSION=docker triggers Plex auto-update inside container
The linuxserver base image auto-updates Plex when VERSION=docker. On first start, Plex upgraded from 1.43.0 (baked into the image) to 1.43.1. If the shim is compiled against a specific Plex version, this could cause compatibility issues.
Suggested fix: Document that VERSION should be left unset or pinned to the version the image was built with. Alternatively, the entrypoint could block auto-updates.

Issue 7 — doctor.sh not included in Docker image
The README references doctor.sh for database health checks, but it's not copied into the Docker image. The Dockerfile only copies migrate_lib.sh, migrate_table.py, docker-entrypoint.sh, and schema SQL files.

Suggested fix: Add COPY scripts/doctor.sh /usr/local/lib/plex-postgresql/ to the Dockerfile.
Steps to Reproduce

Set up postgres:15-alpine container
Run ghcr.io/cgnl/plex-postgresql-linuxserver:latest with TCP connection to PostgreSQL
Mount an existing Plex SQLite database (~108K items) at /source-db
Migration will fail on metadata_items if any guid or title values exceed 255 characters
Even after manually fixing the varchar issue and achieving full migration, Plex crashes on startup with Invalid uuid length

Workaround Applied
To get metadata_items to migrate, I had to:

Wait for migration to complete (with metadata_items FAIL)
Drop views fts4_metadata_titles and fts4_metadata_titles_icu
ALTER all varchar(255) columns on metadata_items to text
Recreate the views
Restart the container (entrypoint re-ran migration, this time successfully)

The migration then completed fully, but Plex still crashes on startup.
Current State

PostgreSQL database is fully migrated and verified clean (108,556 items, 0 self-referential rows, 0 orphan seasons)
Plex is rolled back to standard lscr.io/linuxserver/plex:latest and running on SQLite
PostgreSQL container and data preserved, ready to retry when the shim crash is fixed

[cgnl]

Looking into this. Thanks for the detailed report.

[abcattell91]

The fixes look great but ghcr.io/cgnl/plex-postgresql-linuxserver:latest still has the old v1.2.0 digest. Could you push a new Docker build so I can test? Happy to verify all the fixes against my library.

[abcattell91]

Here's detailed debug from a clean build of latest main (cb4fb56, built Mar 30 10:40):

Key findings:

1. Shim log is 0 bytes despite PLEX_PG_LOG_LEVEL=2 — the shim isn't writing anything at all
2. PostgreSQL has 0 connections from Plex — pg_stat_activity only shows my manual query, no Plex connections. The shim constructor completes but never actually connects to PostgreSQL.
3. std::bad_cast on every single request — happens every 30 seconds on two threads, affecting all endpoints (status/sessions, websockets, recentlyAdded, etc.)
4. Shim .so is freshly built — 17MB, timestamped Mar 30 10:40, rebuilt from source
5. pidof "Plex Media Server" returns empty inside the container — the process name may be different in this image

My read: The shim loads (constructor completes), but never actually intercepts sqlite3_open or connects to PostgreSQL. All queries hit the local empty SQLite shadow database, SOCI can't cast the column types, and every request throws bad_cast. The shim appears to be a no-op after initialisation.

Plex log shows:

Opening 20 database sessions to library (com.plexapp.plugins.library), SQLite 3.39.4
Running migrations. (EPG 0)
Captured session 0 through 19
ERROR - Thread: Uncaught exception running async task: std::bad_cast

[JorisM]

Thanks for the previous bug report + fix! This helped me to get on the right track while debugging.

Hit the same Invalid uuid length crash on v1.3.1. Found the gap in cb4fb56.

Setup: k3s on Fedora, ghcr.io/cgnl/plex-postgresql-linuxserver:v1.3.1 (Plex 1.43.0.10492-121068a07), CNPG Postgres 16.13, source SQLite rsync'd from prod 1.43.2 (~275 accounts, ~50 sections, healthy library), hostPath ext4 on local NVMe.

Crash: [SHIM_INIT] Constructor complete → libc++abi: terminating … Invalid uuid length → dump. Plex log sidecar ends right after Opening 20 database sessions to library (com.plexapp.plugins.library), SQLite 3.39.4. Crashloops forever.

Why cb4fb56 didn't help in my setup: the fix runs inside migrate_sqlite_to_pg and only probes:

/config/Library/Application Support/Plex Media Server/Cache/Flags.dat
${PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR:-}/Plex Media Server/Cache/Flags.dat

In k8s I run migration as a separate Job from the Plex Deployment, source config mounted at /source-config. Both -f probes miss, loop falls through, Flags.dat stays. Plex container then reads the stale 14352-byte Flags.dat and dies.

Fix verified: mv Flags.dat aside on the host, restart Plex → no more uuid crash. Boots past sessions, runs migrations, opens blobs DB, starts plugin scanner. (Then hits the unclaimed-server gate, expected per README.)

Suggested patch: derive Flags.dat path from $SQLITE_DB (with symlinks resolved, since k8s flows often have SQLITE_DB pointing at a symlink to keep the spaces-in-path away from the inner script):

local flags_dat source_root="" sqlite_real
if [[ -n "${SQLITE_DB:-}" ]]; then
    sqlite_real="$(readlink -f "$SQLITE_DB" 2>/dev/null || echo "$SQLITE_DB")"
    source_root="$(dirname "$sqlite_real" | sed 's|/Plug-in Support/Databases$||')"
fi
for flags_dat in \
    "/config/Library/Application Support/Plex Media Server/Cache/Flags.dat" \
    "${PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR:-}/Plex Media Server/Cache/Flags.dat" \
    "${source_root}/Cache/Flags.dat"; do
    if [[ -n "$flags_dat" && -f "$flags_dat" ]]; then
        rm -f "$flags_dat"
        echo "  Cleared Flags.dat (stale SQLite cache): $flags_dat"
        break
    fi
done

Validated against my cluster: mounted the patched migrate_lib.sh via ConfigMap-overlay inside the existing v1.3.1 image and exercised the block in a one-shot Job — sqlite_real resolved through the symlink, source_root derived to /source-config/Library/Application Support/Plex Media Server, third probe matched, Flags.dat removed. Keeps existing behaviour for single-container compose/Unraid setups, covers split-Job k8s/CI flows as well.

Side question — is there a deeper fix than auto-clearing? Stamping Flags.dat with the migration timestamp and rejecting mismatches would survive sidegrades/rollbacks too.

Attached is the PR if that makes sense, close otherwise: #11

[cgnl]

Thanks a lot!