Plex Media Server crashes consistently on /playQueues request

Plex Media Server Plex Pass Betas
,
1

Server Version: 1.42.0.9975
(Windows 10 Pro 22H2 VM under Hyper-V on Windows Server 2022 Datacenter 21H2)

Player Version: 4.12.4 (Plexamp on iOS 18.5 – iPhone 15 Pro Max)

NOTE: Original post deleted and reposted here as I believe it is more relevant to the Plex Pass Beta section.

Description of the Issue

My Plex Media Server (music-only server with 1 library, ~500 000 tracks) is crashing immediately whenever Plexamp on iOS opens a play queue. The crash is 100% reproducible by replaying the same /playQueues request.

This has been occurring for at least a few months. I can’t remember exactly when it started happening.

Steps to Reproduce

  1. Open Plexamp (v4.12.4) on iPhone.
  2. Server receives:
    GET /playQueues/371?window=6&center=16714
  3. ~35 seconds later, server process terminates with a “crashed” status.

I confirmed it by replaying the call from PowerShell:

Invoke-RestMethod -Uri "http://10.x.x.x:32400/playQueues/371?window=6&center=16714" `
-Headers @{
 "Accept"                  = "application/json"
 "Accept-Encoding"         = "deflate, gzip"
 "User-Agent"              = "TREBLE/2.1"
 "X-Plex-Client-Identifier"= "xxx3423-x534-4d12-a4f8-x2314fsd"
 "X-Plex-Device"           = "iOS"
 "X-Plex-Device-Name"      = "iPhone"
 "X-Plex-Platform"         = "Generic"
 "X-Plex-Platform-Version" = "18.5"
 "X-Plex-Product"          = "Plexamp"
 "X-Plex-Version"          = "4.12.4"
 "X-Plex-Token"            = "YOUR_PLEX_TOKEN"
}

Relevant Log Excerpts

Jul 17, 2025 08:20:55.391 [8276] DEBUG - Request: [10.x.x.x:62863 (Allowed Network (WAN))] GET /playQueues/371?window=6&center=16714 (27 live) #bf TLS GZIP Signed-in Token (user_id) / Accept => application/json / Accept-Encoding => deflate, gzip / Host => 10-x-x-x.xXx51xX.plex.direct:32400 / User-Agent => TREBLE/2.1 / X-Plex-Client-Identifier => xXx-x29fd-as123-asdf / X-Plex-Device => iOS / X-Plex-Device-Name => iPhone / X-Plex-Platform => Generic / X-Plex-Platform-Version => 18.5 / X-Plex-Product => Plexamp / X-Plex-Token => xxxxxxxxxxxxxxxxxxxx / X-Plex-Version => 4.12.4
Jul 17, 2025 08:20:55.393 [8276] DEBUG - [Req#bf] PlayQueue: total generated: 427, before cursor: 94, after cursor: 5
Jul 17, 2025 08:20:55.504 [8492] DEBUG - [JobRunner] Job running: "C:\Program Files\Plex\Plex Media Server\CrashUploader.exe" "--directory=x:\x\x\Plex Media Server\Crash Reports\1.42.0.9975-6b2b441e1" --version=1.42.0.9975-6b2b441e1 --platform=Windows "--platformVersion=10.0 (Build 19045)" --serverUuid=xxx83xjfl1xx --userId=x@x.com --sentryUrl=https://o17675.ingest.sentry.io/api/1233455/ --sentryKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx "--vendor=Microsoft Corporation" --model=x64-x64 "--device=Virtual Machine" --sessionStatus=crashed --sessionStart=1752754820 --sessionDuration=35

What I’ve Tried

  • Disabled CollectBandwidthStatistics via registry DWORD (0)
  • Turned off all Plexamp client-side features (Loudness Levelling, Sweet Fades, Convert to Stereo)

None of these prevented the crash.

Environment:

  • Plex Media Server running on a Windows 10 Pro VM (Hyper-V host)
  • Library: Music only (~500 000 tracks)
  • Client: Plexamp for Windows and iOS (4.12.4)

Any guidance on a workaround or confirmation of a server-side bug would be greatly appreciated.

2

Update / Findings

After a deep dive, I can confirm this is not a client‑only issue. The server crashes every time it processes a /playQueues/{id} request whose queue contains a track title with a malformed UTF‑8 sequence (“ΓÇÖ” instead of the proper curly‑quote). Here’s what I discovered:

  1. Repro steps

    • On Plexamp (iOS 4.12.4), open the playlist in question (PlayQueue ID 371).
    • Server receives:
      GET /playQueues/371?window=6&center=16714
    • ~35 s later, PMS terminates with a crash report.

  2. Direct reproduction

    • I replayed the exact same HTTP request from PowerShell against my PMS, and it still crashes immediately in the PlayQueue generation code.

  3. Root cause

    • On disk and in the original FLAC tags, the filename/title is correctly:
      “Ain’t That a B*tch”
      Note: The original title contains a profanity; I’ve replaced the “i” with an asterisk in “B*tch” for decency.
    • However, Plex mis‑reads the curly apostrophe (U+2019) under the wrong encoding and stores it in metadata_items.title as:
      “AinΓÇÖt That a B*tch”
    • The PlayQueue handler crashes whenever it tries to serialize or traverse that mojibaked string.

Recommendations for Plex Media Server

To prevent malformed metadata from ever taking down the server, I’d suggest Plex devs consider:

  1. UTF‑8 Validation & Normalization at Ingest

    • When scanning tags or filenames, automatically run a Unicode‑normalization pass (e.g. NFKC) and strip or replace invalid byte sequences before inserting into metadata_items.title.
    • This would convert stray Windows‑1252 smart‑quotes, long dashes, or other non‑UTF8 bytes into safe equivalents (straight quotes, hyphens, etc.).

  2. Sanitize PlayQueue Payload

    • In the /playQueues handler, wrap string‑serialization in a try/catch, and on failure replace offending characters with ? or drop them, rather than letting the entire request crash the process.
    • Failing fast with a warning is better than full process termination.

  3. Resiliency in JSON Generation

    • Use a JSON encoder that can handle or escape unpaired surrogates/invalid Unicode codepoints, so you never get a segmentation‑fault or access violation when building the queue response.

  4. Logging & Alerting

    • If a metadata field contains invalid characters, log a clear warning (including the metadata_item_id) and continue.
    • Optionally, expose a server‑side “Clean metadata” tool or preference that scans for and normalizes known mojibake patterns.

  5. Library‑Scan Option

    • Provide an advanced setting under Library → Advanced to “Normalize Unicode in titles” on the next scan, which would apply these fixes automatically without an external script or DB hack.

I hope this helps the PMS team reproduce and patch the underlying issue. It’s trivial to trigger, 100% reproducible on any library that has a curly‑quote in a track title, and currently causes a hard crash rather than a graceful error. If there’s anything else I can provide—additional logs, a crash dump, or a minimal repro library—please let me know!

3

Thanks for report and detailed info.

2 Likes
5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.