Server: v1.43.1.10611 (Docker, plexinc/pms-docker)
Symptom: All transcodes of EAC3/TrueHD/MLP audio fail with Invalid decoder type ‘eac3_eae’ followed by Error opening input file.
Reproduction: Any client that requires audio transcoding of an EAC3 source.
Cause: When Plex Transcoder (ffmpeg) is spawned for a transcode, the EAE_ROOT environment variable is not set, even though the long-lived “Plex EAE Service” process has a valid watchfolder at /tmp/pms-/EasyAudioEncoder. Running ffmpeg manually with EAE_ROOT exported produces a clean decode ([eac3_eae] No EAE watchfolder set! is the underlying error). The Voice Activity Detection / sonic analysis code path does set it correctly — only the live transcode path doesn’t.
the fix for me on mac was to disable hw audio transcoding then restarting plex.
defaults write com.plexapp.plexmediaserver “HWA_CODECS_ENABLED” -bool true
@guipace can you pleasedo the following;
- Confirm server DEBUG logging is enabled, VERBOSE logging is disabled.
SAVE if changes.
- Restart PMS
- Give it two minutes to start and stabilize
- Start a playback which shows the issue
- Let it play for 20 seconds
- Stop the playback
- Download the server logs
- Attach the logs so I may see them.
Also, if you could provide a sample file of the media that is showing this issue that would be helpful.
Posting in case it helps the next person debugging this — turns out I hit the well-known “Plex doesn’t auto-re-analyze files after they’re changed in place” issue (lots of prior threads on it), but the surface error sent me down a rabbit hole that I think is worth flagging.
What I saw:
After tdarr re-encoded several files in place (h264 → hevc, audio kept as eac3), every transcode attempt on those files failed with:
ERROR - Invalid decoder type ‘eac3_eae’
ERROR - Error opening input file
I spent a while assuming this was an EAE / codec install problem (deleted Codecs/, restarted, checked Plex Pass entitlement, looked at watchfolder paths, even wrote a wrapper around Plex Transcoder to set EAE_ROOT).
What it actually was:
The transcoder spawn command was correct in every respect except the stream-codec mapping:
Plex Transcoder -codec:0 h264 -codec:1 eac3_eae -eae_prefix:1 …
-filter_complex “[0:1] aresample=…”
Real file (ffprobe):
- Stream 0: hevc (Plex DB cached “h264”)
- Stream 1: subtitle eng (Plex DB cached “eac3 audio”)
- Streams 2-3: subtitles
- Stream 4: eac3 audio (Plex DB has nothing here)
So -codec:1 eac3_eae was being applied to a subtitle stream, and ffmpeg correctly refused. The cached layout was from the original file, before tdarr re-encoded.
Suggestion (the reason for the post):
The Invalid decoder type ‘eac3_eae’ message is misleading — the decoder is fine, it’s just being applied to the wrong stream type. Something like requested decoder ‘eac3_eae’ doesn’t match stream type at index N (subtitle) would have pointed straight at the cause and saved a lot of time.
Logs attached.
before-sunrise-failure-raw.log (17.5 KB)
Thanks for reporting. Could you please share the entire zip of your PMS logs and also share a sample file that is causing this issue?
If you do that, you may need to trigger Plex to re-“Analyze” the file, to notice its changed innards.
This is why one should only move media into a folder which is monitored by Plex, after they have been completely downloaded/unzipped/prepared/re-encoded etc.
