Ran a cleaner A/B test, same app session, about 40 seconds apart. Two findings: it’s specific to HDR/Dolby Vision content, and the server logs no error at all when it fails. I’ll show where the chain stops.
Working case — Friends S05E10 (SDR H.264 .mkv), forced transcode:
[17:45:56.485] SessionManager: User "server" stopped playback of '"The One with the Inappropriate Sister"' at "1180846"ms ("Infuse-Library" "8.5.5")
[17:45:56.609] MediaInfoHelper: User policy for "server". EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
[17:45:56.766] MediaInfoHelper: User policy for "server". EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
[17:45:57.423] TranscodeManager: "/usr/lib/jellyfin-ffmpeg/ffmpeg" ... -codec:v:0 h264_nvenc ... <-- transcode starts
[17:45:58.827] TranscodeManager: FFmpeg exited with code 0
[17:45:58.832] TranscodeManager: "/usr/lib/jellyfin-ffmpeg/ffmpeg" ... -ss 00:19:40.179 ... <-- seek, respawn
[17:45:59.535] SessionManager: User "server" started playback of '"The One with the Inappropriate Sister"' <-- playing
[17:46:08.090] SessionManager: User "server" stopped playback at "1186381"ms
Chain completes: PlaybackInfo → ffmpeg spawned → playback started.
Failing case — The Perfect Neighbor (4K HEVC Dolby Vision P8.1 .mp4), forced transcode:
[17:46:21.380] MediaInfoHelper: User policy for "server". EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
[17:46:28.163] SessionManager: User "server" started playback of '"The Perfect Neighbor"' ("Infuse-Library" "8.5.5")
[17:46:38.412] SessionManager: User "server" stopped playback of '"The Perfect Neighbor"' at "5547"ms
[17:46:38.491] MediaInfoHelper: User policy for "server". EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True <-- quality switch
[17:46:38.634] MediaInfoHelper: User policy for "server". EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
<-- chain stops here. nothing follows.
This is where it breaks. The two PlaybackInfo negotiations come through, and then nothing. No TranscodeManager line, no ffmpeg, no started playback. The error appeared in Infuse at that exact moment.
And critically — I checked the window unfiltered: 48 log lines between 17:44 and 17:50, zero [WRN], zero [ERR], zero [FTL]. Jellyfin doesn’t consider anything to have gone wrong. It answered the PlaybackInfo request and was never asked for a stream. So whatever rejection happened, it happened inside Infuse and was never sent to the server.
Control — the server transcodes this exact file fine. Jellyfin Web did it earlier the same day at 10:21:31, tonemapping included:
-vf setparams=color_primaries=bt2020:color_trc=smpte2084:colorspace=bt2020nc,scale_cuda=w=960:h=540,tonemap_cuda=format=yuv420p:p=bt709:t=bt709:m=bt709:tonemap=bt2390:peak=100:desat=0
Versus the SDR file that worked in Infuse, which needs no tonemap:
-vf setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale_cuda=w=960:h=540:format=yuv420p
So GPU, server and file are all fine. The difference is that the DV file’s transcode profile requires tonemapping, and Infuse appears to reject or abandon that PlaybackInfo response before requesting the stream.
Two corrections to my earlier posts, sorry for the noise:
- No
AuthenticateByName / request.App exceptions occurred anywhere in this window. That crash is a separate issue from a periodic background auth loop, not the cause of this.
- The token rotation I flagged happened at 17:45:32, before the Friends test that succeeded, so that’s not it either.
Since the server side is silent, the answer is almost certainly in Infuse’s own log. I’ll reproduce and submit an in-app report, and can also enable Jellyfin debug logging if the full stream-selection reasoning would help.
