Sonic Analysis fails due to ~259 character file path limit in Plex Transcoder

Plex Media Server
,
14

Hi chris_decker08, thanks for following up. I’ve dug much deeper since my original report and I need to significantly correct and update it.

The title of this thread says “259-character file path limit” — that’s wrong. I confirmed a 268-character path analyzing successfully, so path length isn’t the issue. I apologize for the misdirection.

Here’s what I found after analyzing (with a fair amount of help from Claude) 10,000+ MusicAnalysis transcoder invocations with verbose logging enabled:

Some of my music files had Unicode “smart quote” characters in filenames — the typographic right single quotation mark ' (U+2019) instead of a plain ASCII apostrophe '. Affected artists included The Cranberries (Can't), Joni Mitchell (Joni's), and Guns N’ Roses (N').

Sonic Analysis was failing on these files — the [MusicAnalysis/JobRunner] would log an invocation with what looked like the correct path, but the transcoder would immediately exit with error code -2 (ERROR_FILE_NOT_FOUND). Those failures were causing the system to get “stuck” and it wouldn’t scan other libraries (Music, TV, etc.) until I restarted PMS.

To work around this, I wrote a cleanup script that renamed the files on my NAS, replacing Unicode smart quotes with plain ASCII apostrophes. The files on disk are now fine and accessible.

So, the actual problem now is that Plex’s database kept the old entries pointing to the Unicode-apostrophe paths, AND created new entries for the ASCII-apostrophe paths. So now the database has duplicate entries for the same physical tracks — one that works (ASCII path, matches the file on disk) and one that fails (Unicode path, file was renamed so it no longer exists at that path). The good news is that the missing files fail quickly and don’t hang the scanning process, so it’s noisy but not fatal.

The numbers from my latest scan (verbose logging, full library):

  • 665 unique file paths attempted by MusicAnalysis
  • 297 succeed (exit code 0) — these are the entries with paths matching the current filenames
  • 368 fail (exit code -2) — I batch-checked every single one of these against my NAS:
    • 361 files don’t exist on disk — stale database entries pointing to the old pre-rename paths
    • 7 files exist but fail — all turned out to be corrupt or unusual audio files (0 kbps metadata, MP1/MP2 codec, empty FLAC streams) — not a Plex bug

As an example, The Cranberries album “Everybody Else Is Doing It, So Why Can’t We” has two sets of entries in the same log. CD 01 tracks (with ASCII apostrophe in the path) all succeed. CD 03 tracks (with Unicode smart quote in the path — the old filenames) all fail. Same album, same NAS share, same directory — the only difference is the apostrophe byte in the database path vs what’s on disk.

Failures are 100% deterministic per path — each path either always succeeds or always fails across all attempts. It’s not intermittent or timing-related.

So to directly answer your question, there are no newline characters or unusual apostrophes in my actual filenames. The filenames on disk are clean ASCII now. The failures are caused by stale Plex database entries that still reference the old Unicode-character paths from before I renamed the files.

I ran a full Scan + Empty Trash hoping it would clean up the orphaned entries, but it didn’t help — the stale entries persist. I suspect Plex doesn’t detect the mismatch because the old path (Can't with U+2019) and new path (Can't with ASCII ') look visually identical, even though they’re different bytes.

Open questions:

  1. Is there a way to purge these stale database entries without losing play history, star ratings, and playlists? I’d really like to avoid a full Plex Dance if possible.

  2. Separately from my self-inflicted rename issue — does MusicAnalysis actually handle Unicode characters in file paths correctly? The reason I renamed the files in the first place was that Sonic Analysis was failing on them. I can no longer reproduce that since the files are renamed, but if there IS a Unicode handling issue in the cmd.exe-based transcoder launch, it would affect anyone with MusicBrainz-sourced smart quotes in their filenames.

Happy to provide full log excerpts, the specific paths, or any additional data that would help.