Server Version#: 1.43.4.10903-e5521bd8c
Platform: Docker (plexinc/pms-docker), Debian 13 host
Player Version#: Android 2026.13.0 (also reproducible via Plex Web)
Issue:
When TranscoderCanOnlyRemuxVideo=“1” is set in Preferences.xml, and a client
requests playback that genuinely requires re-encoding (not just a container
remux — e.g. because of a client-side bandwidth cap forcing resolution/bitrate
reduction), the server refuses the transcode as expected, but reports the
wrong reason to the client:
Transcode=4010, This item cannot be played at this time. The server has
reached its configured limit for maximum simultaneous video transcodes.
This is misleading. /status/sessions showed 0 active sessions, and
Maximum simultaneous video transcode / Maximum simultaneous CPU transcodes
were both set to finite, non-zero values — there was no actual session-limit
condition. The real (correct) reason is visible only in the server debug log:
MDE: E1 - : no remuxable profile found, so video stream will be transcoded
…
Streaming Resource: Reached Decision id=… codes=(
MDE=3001, Not enough bandwidth for direct play of this item…
General=2000, Neither direct play nor conversion is available.
Direct Play=3000, App cannot direct play this item…
Transcode=4010, … maximum simultaneous video transcodes.)
The Transcode=4010 code appears to be a generic fallback used whenever the
transcode decision fails for any reason, not specifically a session-count
limit — the client (Android app, and presumably others) surfaces this generic
code’s message verbatim, which sent us down a lengthy, wrong troubleshooting
path (restarting sessions, changing transcode-count settings, disabling
hardware acceleration, etc. — none of which were the actual cause).
Suggested fix: Either give Transcode=4010 a distinct, accurate message
when the real cause is “remux-only mode + no remuxable profile available”, or
at minimum expose the actual MDE=3001 / bandwidth-exceeded reason to the
client UI instead of (or alongside) the generic transcode-limit text.
Steps to reproduce:
Set TranscoderCanOnlyRemuxVideo=“1” in Preferences.xml (restart PMS).
Play a file that direct-plays fine locally but whose bitrate exceeds a
client-side remote-bandwidth cap (e.g. Android app’s "Maximum remote
bitrate" set below the file’s bitrate), forcing the server to consider a
real re-encode rather than a remux.
Server correctly refuses (remux-only can’t downscale/re-encode), but the
client reports "reached its configured limit for maximum simultaneous
video transcodes" even though 0 sessions are active and the transcode
count limits are unrelated.
Confirmed via debug log (Plex Media Server.log) that the true decision
code is MDE=3001 (bandwidth) / General=2000, not a session-count limit.
Fix applied on our end (for anyone finding this via search): the
TranscoderCanOnlyRemuxVideo=“1” value in Preferences.xml was not something
we had knowingly set — possibly a leftover from an earlier Docker
image/config. Setting it back to “0” and restarting the container resolved
playback immediately.
