Transcoded playback kicks to main menu after ~10s as PleX keeps SIGKILLing (-9) the transcoder

Plex Media Server
, , ,
1

Server Version: plex-media-server 1.32.8.7639-1 (AUR)
Player Version: plex-media-player 2.58.1-3 (AUR)
Server Kernel: 6.6.5-arch1-1
Server Driver: nvidia-dkms 545.29.06-1

Host: IBM x3650 M4
CPU: 2x E5-2650v2's
Mem: 192G DDR3 half free (-caches)
GPU: NVIDIA Corporation GP106GL [Quadro P2000] [10de:1c30]

Hi team,

I’m experiencing more Plex server issues this month with Plex Media Server since doing this months round of updates.

All client types I have access to (iOS>Chromecast, iOS app itself, plex web access and the desktop media player app) all experience sudden halts in playback with this new transcoding problem the Plex Media Server has started running into.

Direct playback is fine and this issue seems to be related only to transcoding operations. Transcoding to any quality results in the client being kicked back to the main menu without an error after about 10 seconds.

The GPU appears fine and other CUDA operations are happy to use it without problems and at expected performance.

There is plenty of free memory and the kernel logs (dmesg) have no lines to share when Plex kills its transcoder like this. Nor does jorunalctl -f or journalctl -xe looking for any errors. Nothing.

The regular Plex Media Server logs had no output when this happens but the debug logs reveal the Plex Media Server service is sending a SIGKILL to its transcoder thread just seconds after it starts transcoding for the user. This experience is persistent for all different forms of media I’ve tried setting a lower quality setting on.

I presume the client is being kicked back to the main menu after it sends a request to fetch more of the transcoded stream only to learn the transcoder responsible for the media session is dead.

This is also evident watching nvidia-smi where the Plex Transcoder process is there to begin with and then disappears a few seconds into a client’s playback.

Here’s the chunk of log spit out when the /usr/lib/plexmediaserver/Plex Transcoder process gets shot in the back of the head:

Dec 17, 2023 14:15:37.308 [140297905720120] DEBUG - [Req#14b/Transcode/dkgjmv0923mg2390m39009/f4736b49-6911-49df-b359-197692454b54] Transcoder segment range: 0 - 0 (0)
Dec 17, 2023 14:15:37.308 [140297853639480] DEBUG - [Req#150/Transcode/dkgjmv0923mg2390m39009/f4736b49-6911-49df-b359-197692454b54] Transcoder segment range: 0 - 1 (0)
Dec 17, 2023 14:15:37.532 [140297908710200] DEBUG - [Req#114/Transcode] Codecs: Testing with profile 'High'
Dec 17, 2023 14:15:37.585 [140297908710200] DEBUG - [Req#114/Transcode] MDE: E1 - EpisodeName: Audio Direct Streaming is disabled, so video's audio stream will be transcoded
Dec 17, 2023 14:15:37.585 [140297908710200] DEBUG - [Req#114/Transcode] MDE: Cannot direct stream audio stream due to profile or setting limitations
Dec 17, 2023 14:15:37.586 [140297908710200] DEBUG - [Req#114/Transcode] MDE: Showname - S1 E1 - EpisodeName: selected media 1 / 499974
Dec 17, 2023 14:15:37.586 [140297975642936] DEBUG - [Req#114/Transcode] Killing job.
Dec 17, 2023 14:15:37.586 [140297975642936] DEBUG - [Req#114/Transcode] Signalling job ID 123952 with 9
Dec 17, 2023 14:15:37.586 [140297975642936] DEBUG - [Req#114/Transcode] Job was already killed, not killing again.
Dec 17, 2023 14:15:37.586 [140297975642936] DEBUG - [Req#114/Transcode] Stopping transcode session dkgjmv0923mg2390m39009
Dec 17, 2023 14:15:37.586 [140297908710200] DEBUG - [Req#114/Transcode] Streaming Resource: Reached Decision id=174062 codes=(General=1001,Direct play not available; Conversion OK. Direct Play=3000,App cannot direct play this item. Direct play is disabled. Transcode=1001,Direct play not available; Conversion OK.) media=(id=499974 part=(id=826609 decision=transcode container=mkv protocol=http streams=(Video=(id=4054950 decision=transcode bitrate=7246 encoder=h264_nvenc width=1920 height=1080) Audio=(id=4054952 decision=transcode bitrate=321 encoder=libopus channels=6 rate=48000))))
Dec 17, 2023 14:15:37.586 [140297988332344] DEBUG - [Req#114/Transcode] Cleaning directory for session dkgjmv0923mg2390m39009 (/tmp/Transcode/Sessions/plex-transcode-dkgjmv0923mg2390m39009-f4736b49-6911-49df-b359-197692454b54)
Dec 17, 2023 14:15:37.588 [140297975642936] DEBUG - [Req#114/Transcode] Transcoder: Cleaning old transcode directories.
Dec 17, 2023 14:15:37.588 [140298059987768] DEBUG - Completed: [127.0.0.1:46642] 200 GET /video/:/transcode/universal/decision?hasMDE=1&path=%2Flibrary%2Fmetadata%2F174062&mediaIndex=1&partIndex=0&protocol=http&fastSeek=1&directPlay=0&directStream=0&subtitleSize=100&audioBoost=100&location=wan&maxVideoBitrate=8000&directStreamAudio=0&session=dkgjmv0923mg2390m39009&offset=81&subtitles=auto&copyts=1&Accept-Language=en (5 live) #114 GZIP 4308ms 2657 bytes
Dec 17, 2023 14:15:37.588 [140297975642936] DEBUG - [Req#114/Transcode] Whacked session dkgjmv0923mg2390m39009, 0 remaining.
Dec 17, 2023 14:15:37.620 [140298059987768] DEBUG - [TranscodeOutputStream] Timed out waiting for data
Dec 17, 2023 14:15:37.620 [140298059987768] DEBUG - Removed transcode data consumer, active count 1 => 0
Dec 17, 2023 14:15:37.620 [140297659841336] DEBUG - [TranscodeOutputStream] Input processing thread exited after writing 4642998 bytes, m_closed=1, m_endOfFileReached=1, session->isStopped()=1
Dec 17, 2023 14:15:37.650 [140298064743224] DEBUG - Jobs: '/usr/lib/plexmediaserver/Plex Transcoder' exit code for process 123952 is -9 (signal: Killed)

After this happens, the next time the client fetches more content for the video playtback experience it just kicks the client back to the main menu.

2

It’s impossible to see what’s really happening from that snippet (inconclusive) but EOF (end of file) must be from either the source media or the transcoded temp output (can’t write the video output stream).

3

Yeah its quite frustrating to track down. I’ve tried the plex-media-server-plexpass 1.32.8.7639-1 package but its version is identical to the default release.

I’ve got Plex’s temp dir set to /tmp for these operations which is a tmpfs mountpoint (ramdisk). I can fill it up to half of the system memory without argument and Plex is killing its transcoder thread much sooner than that.

I recursively deleted /tmp/Transcode which had a subdirectory /tmp/Transcode/Sessions and I am actually able to lower the quality of an Original 8.9Mbps, 1080p HD from Original down to Convert to 1080p HD (High) 20 Mbps, Convert to 1080p HD (medium) 12 Mbps and Convert to 1080p HD (medium) 10 Mbps without this problem happening nor the directories coming back. I presume this is because Plex isn’t actually transcoding when it knows it can send the original 8.9Mbps content to a client compatible with the file’s embedded codecs.

But the moment I take this sample file down to Convert to 1080p HD 10 Mbps, transcoding kicks in and these /tmp directories get re-created with a session… then they disappear after about 3 seconds as Plex sigkills the transcoder again.

This seems to be happening on all forms of various video media regardless of basic h264+mp3 codecs or h265+5.1 channel codecs being used for a file.

4

Ill try an older Plex and nvidia-dkms version to see if I can get anywhere here.

5

The killing of the Plex Transcoder doesn’t happen when the NVIDIA driver isn’t loaded. I presume it’s using the CPU for it in that case. The moment I re-installed the NVIDIA driver Plex using it as seen under nvidia-smi when the conversion quality were changed and Plex resumed killing the transcoder process shortly after it starts.

Removing /tmp from Plex as the directory for transcoding work to be done in also doesn’t fix the issue.

6

Downgrading to nvidia-dkms 535.86.05-2 plus linux 6.5.3.arch1-1 for it to build successfully and rebooting had no impact.

Then tried downgrading plex-media-server-plexpass to 1.32.6.7468, then 1.32.5.7349 then 1.32.5.7349 then 1.31.3.6868 and restarting its service each time also had no impacts.

I tried unchecking Play smaller videos at original quality on my client then unchecking Direct Play then unchecking Direct Stream and I was able to play the media it using Convert (Maximum) automatically and I can see the Plex Transcoder process under nvidia-smi without issue. But the moment I select a lower conversion bit-rate (What these lower bandwidth clients must use) Plex starts then SIGKILL’s the transcoder thread again.

These continuing issues all year have been an immense frustration. I can direct-play all my items here at home but every other location with a low tolerance for high bitrate content need this conversion system to work. The host itself has no issues whatsoever using the P2000 GPU for any CUDA compute when given a task but Plex has run into countless issues all year leading to zombie processes and now a seeming lack of transcoding support at all when it has an opportunity to use this P2000. I’m out of ideas for the time being and wasted a day on this.

7

I’m sorry but I need to refer you to whomever provided you with the Plex package.

We don’t support Arch Linux.

The issues you’re having with 6.5.3 are, unfortunately, well beyond working on given we’re having troubles with the long term 6.1 kernel for the distros we do support.

I do question the stability of these latest kernels given how quickly new versions are being rolled, released, and EOL’d.

8

I too noticed kernels I were using only last month have already been marked EOL on kernel.org. Granted they’re not designated “LTS” kernels but its a fast release cycle.

I don’t feel the differences between leading distros should be fatal unless we’re seeing some form of library issue here. Running the server with kernel 6.6.7 seems to have no difference either. I’ll give 6.1 a try though at this point the problem feels like either a library or niche local issue. Might spin up a new plex server in a VM for addressing and diagnosing this problem then.

Will report back once I find the cause.

9

If you’re going to spin a VM, start all the way down at 5.15 or so kernel and work your way up.

This will let you see where it starts.

I’m not keen on upgrading just the kernel for anything.
There’s a whole lot of service / support libraries calling that kernel which also need updating.
I think that’s a detail a lot of folks forget.

10

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