[Ubuntu / Docker 17.09 / PMS] Transcoder fails optimising / streaming




I've been running into this error a lot, but only now taken the time to report it properly.

PMS transcoder seems to crash when transcoding some files. I've replicated the issue by generating a sample file using the instructions (https://support.plex.tv/hc/en-us/articles/201035968-Generating-Sample-Files-from-Media) and have attached the logs to this post.

The smallest sample file I managed to replicate this with is 200MB, and I'll add a link to it when I've finished uploading (this may take a while as my internet is very slow).

Oct 09, 2017 13:23:46.308 [0x7ff0ed3f5700] ERROR - [Transcoder] [matroska,webm @ 0x2b980a0] Read error

Two possibilities are the most likely:

  • Permissions issue such that the plex user in the container cannot read the media
  • The file itself is corrupted or not actually an MKV file.


I double-checked the permissions and confirmed that the plex user has access to the files. I had to set the PLEX_UID and PLEX_GID when creating the container and I confirmed that the plex user in the container inherited the uid and gid correctly.

# ls -hAil
369 -rw-r--r-- 1 plex plex 200M Oct 11 14:54 John Wick (2014) 1080p Blu-ray.mkv

It's possible that the mkv is damaged in some way, but it plays in VLC without issue. I opened VLC's message window and set it to verbose and it didn't log any issues.

I've been trying without success to run the transcoder directly in the hopes of getting some debug information from it. I just end up with Unknown decoder 'h264', so clearly I'm doing something wrong because it does decode other h264 streams (e.g. if I make the file a little smaller). I also captured the full paramaters that Plex Transcoder was being run with and ran it with my local ffmpeg without issue.

Sample file: (removed - was too small to produce the issue in question)


When you say you ran your local FFmpeg with the same parameters, I presume that you mean you pruned some of them because Plex runs its transcoder with some options which are not present in a vanilla FFmpeg.

What happens if you run Plex's transcoder with these options? The logs give you the environment variables as well so you should be able to do that. Just note you should create an empty directory and run from within there as the command line arguments tend to put the output in the current working directory.


I pruned the loglevel_plex, nostats, and -progressurl options, and changed the loglevel from quiet to trace. I obviously changed the file paths as well.

Aha! Running the Plex Transcoder with all the environment variables from the logs runs properly. I can also see that my sample file is generally too small to trigger the error, but somehow just large enough to trigger a read error (it doesn't trigger a read error when it's 50mb smaller...).

I now get a segfault when transcoding (ran it a bunch of times with the same result - might be worth noting that it actually caused the server to reboot the ninth time I did it). It doesn't crash at or even near the same frame each time, so I'm not sure what it could be doing that's causing this issue.

I've attached one of a bunch of logs (the smallest one, because my internet is terrible) that'll show you the error.


When you said might be worth noting that it actually caused the server to reboot the ninth time I did it are you talking about the Plex Media Server rebooting, the container rebooting (since this is posted in docker I'm assuming you're using that), the docker daemon rebooting, or the host rebooting? TBH, none of these should be happening and could be speaking to a more fundamental problem. Since the arguments you posted are not using hardware transcode, running this transcoder instance should at worst only be capable of crashing the process.

I don't see anything in the logs which stands out to me (though given how verbose the logs are, I could have missed something). From your past comments, I'm going to assume that you know you way around FFmpeg a little bit.

  • Now that you have a sample file that confirms a crash, try it with a vanilla FFmpeg (obviously changing some arguments as you mentioned earlier). I'm not sure if you ran it on a crashing sample or only the non-crashing but read-error sample.
  • Try changing the output to only have 1 stream. It appears to have 1 video stream, 2 audio streams (which is interesting), and 2 sidecar sub streams. What happens if you prune this down to one at a time and try each one individually?
  • If you are willing to try, does this reproduce on the host instead of in the container?


If you can build ffmpeg yourself, the run configure with --disable-stripping --disable-optimizations. Probably best to use our ffmpeg source code dump, or ffmpeg git. Then run the transcoder under valgrind and gdb.

gdb can be started with gdb --args ffmpeg -i ... (then type run and hit enter - if it crashes, do bt and paste the output here).

valgrind is run with just valgrind ffmpeg -i ..., and will print errors to stderr as they happen.


I tested this on the host (Ubuntu server 17.04) , and was able to reproduce the issue with the ffmpeg obtained from the standard repositories.

On the host:
I tried modifying the parameters to process one stream at a time:
* Video stream only (h264 > h264): segfault
* Audio #1 (dts -> aac): segfault
* Audio #2 (ac3 -> aac): transcoded successfully
* Subtitle #1: success
* Subtitle #2: success

I got the exact same results in the container, (the streams did crash at different points, but that seems to be the case anyway).

Since the crashes happen with both the container's Plex Transcoder and Ubuntu's ffmpeg (and since I'm not sure where to get your ffmpeg source code dump), I'll try to compile ffmpeg from git.

I'll report back after this, as it will probably take me some time and there's something else I want to try first...


So as I was testing the transcoding I eventually noticed some interesting errors in dmesg - something along the lines of "internal parity error".

After puzzling over this for quite some time, I concluded that my hardware must be faulty. Nevertheless a couple stress test and a memcheck turned up nothing. I was about to give up and start compiling ffmpeg when I read something about overclocking...

Now I'm a software guy, a developer, I don't overclock stuff. I rarely game and when I do it's Age of Empires, not Crysis on maximum settings. So imagine my confusion when I go into my BIOS and find settings related to overclocking set to "Manual".

I guess the guy who owned this motherboard before me was into that kind of thing. Anyhow, I reset all that stuff to "Auto" and ran the transcoding tests again - everything works!

So I apologise for wasting your time guys, and I thank you kindly for your help. I guess I hope we've all learned something from this...

Tl;dr unexpected overclocking == segfault


Glad to hear that you tracked it down and resolved it. At least as a result of this you should have a more stable server overall as this likely fixed other things as well.

Internally we were guessing it was a hardware fault of some sort and overclocking can certainly cause such an intermittent fault.