OpenSubtitles SRT Image Format Causing Transcoder Error

Server Version#: 1.18.2.2029 on FreeNAS 11.2-Stable
Player Version#: Web Client

Sorry, I posted the same topic under the wrong sub forum yesterday under Deskptops&Laptops, can Mod please remove that one? I have flagged it for moderation. Thanks!
For some reason the web player keeps running into playback error with the message “Conversion Failed. The transcoder exited due to an error.” when the player tries to use image format for the OpenSubtitles SRT subtitles. The is for all web clients. I tried it on multiple computers. I can play the videos if I choose to always burn in the OpenSubtitles SRT subtitles and the streams play fine without subtitle or non OpenSubtitles SRT subtitles in Image Format or on other clients where image format subtitle is not an option.
I have tried to reinstall another instance of Plex and it ran into the same issue. I haven’t tried to revert my PMS to a previous version.
A little more context, at the same time I updated to run into the issue when I swapped out my G4560 with a Ryzen 2700X on my FreeNAS, but not sure if it’s a server side issue since play back and transcoding is fine with all other situations.
Here is a transcoder log for the stream with image format subtitle that failed.

Not sure I follow, SRT should be text.

Do you mean it fails for SRT (text) I have other reports of issues while using SRT subs on FreeBSD actually so I wonder if this is the same.

I’m referring to the Player -> Burn Subtitle option. The option to either burn the subtitles into the stream using the transcoder or rendering the subtitles as image format on top of the stream. Plex calls the latter as Only image formats. The transcoder will 100% crash if I choose that option if the subtitle chosen is SRT from OpenSubtitles.
It might be the same issue? I just haven’t seen any reports on it when I searched.

They are burned into the VIDEO but the original format would still be whatever it was, I was getting confused cause it sounded like you were saying you had imaged based SRTs.

Here a more detailed explanation of those settings


    Automatic – (Default) Burn in subtitles when the subtitle is an image-based format (e.g. VOBSUB, PGS, SUB/IDX, etc.) as well as for complex ASS/SSA subtitles.
    Only image formats – Only burn in subtitles when the subtitle is an image-based format (e.g. VOBSUB, PGS, SUB/IDX, etc.)
    Always – When used, subtitles will always be burned into the video, regardless of the original source type of the subtitle.

So this means the setting will either brun/not burned based on the SOURCE TYPE, so if you set always the SRT will be overlayed into the video so to speak (like a video on top of another) and this is super expensive to the CPU hence why it goes up to 100%, so that part is normal.

We’ve had more reports of SRTs failing to transcode in FreeBSD, I can’t repo it but if you could please add a sample (or DM it to me) and the XML info for that file it would be great (you already posted logs and it looks like the same issue as others), I’ve raised this internally and we are looking into it but so far the log doesn’t help much, I’ll have to repo it locally and the samples migh help.

@jingweizhang0302 while trying to help another user over DM we were able to confirm the issue only happens on WEB TV not the actual web app, can you please tell me how are you accessing the web app?

Is it via app.plex.tv? or the one bundled with the server?

I understand how these work and that’s not what’s at the center of the topic here.
I would appreciate it if we don’t start from the very basics and go ahead assume that we both have sufficient fundamental knowledge of how things work.
As an additional test to make sure it’s not some weird permission issue, I went ahead and chmod 777 -r the entire meta data folder and localhost folder and of course that didn’t help…
I also pulled the SRT file out of the media/localhost folder path and dropped it directly into the same directory as the video file and that didn’t work either, so it’s not a path issue.
The only thing that I have not tried to to download SRT files from other places and drop it into the directory to see if that will work.
However, I can confirm that embedded SRT (SRT subtitles built into the video file) can be displayed using image format without any issue.
Here is a sample of the localhost sub folder where the agents download and store the subtitle file. Let me know if you need anything else.
https://drive.google.com/open?id=1Pf5V_P4gb3SxqraRngujJuCxCSZqK4Ol

As for web tv vs web app, if you mean the app.plex.tv access vs 32400/web access. It makes no difference whatsoever. It will crash both ways. The only thing that makes a difference is whether or not the SRT file is burnt into the stream.

Ah sorry for the previous post, and DM, it seemed there was some confusion there, but no worries.

Other users are reporting this fails on LG (Web TV) but never on the Web App via the browser which complicates things cause it might then be a different issue.

In any case both only experience the issue with “sidecar/downloaded” subs (not embedded).

I doubt it would be a case of permissions, since there’s indeed a Transcode Error, so if possible can you please upload a sample of a media file affect ? (Just the file not the SRT) and also the XML you get from the “Info” context menu on the same item?

I need to compare and try that against my own freebsd server, as so far I was not able to repo with any of my files (using the Web app or Web TV).

5499.zip (5.0 KB)
Here is the XML file for the file that I’m having problem with.
I just discovered another weird quirk with it. It appears that the issue only happens on the account with admin right (aka mine). When I log into one of the family member’s account, the SRT file loads as expected with the “Only Image Format” without transcoder error and not burnt into the stream.
I gotta play around with it more later tonight and will let you know. Otherwise, I’ll have to upload the actual source file tonight and send you a link.
Yeah, I have never used Web TV and don’t have a TV with Plex, so I won’t be able to test that. I’m running into the problem across different computers using the browser web app.

Now I’m confused again, as I stated before Only Image Format would have no effect on a SRT, if you see difference from “Automatic” then this would be an actual bug.

Are there any different settings for the family member, i.e Quality Settings in the web player?

I was able to repo this with a sample provided by @Pixaro who seems to experience the same issue has you. Hopefully this will be able to track it down anyway, but if you can provide a sample too it would be great.

Well. turning on Only Image Format DOES have an effect on SRT because with it on, I can adjust timing offset, size, color and etc on the fly without interrupting the stream, whereas if I choose Always Burn In, it’s no longer adjustable on the fly via the web app and any changes to the subtitle will result in terminating of the previous transcoding stream and starting a new one.
It does not seem like the family member has an option on what the subtitle burn in option is, but it was in the image format aka, I can adjust the subtitle properties on the fly.
Not sure why it works when in a family member profile but not in the admin profile. Also, this is on the same computer.

No, you’re misunderstanding me, I said vs “AUTOMATIC”, for SRT subs having that setting on Automatic or Imaged Only has the same behavior, now “Always” means just what it states… “always burn in regardless of type”.

No worries though that’s not the actual issue, the issue seems to be that for some reason when the client try to include the srt stream something bad happens (I believe its actually the clients fault not the server based on my initial finding with the sample but 100% not sure yet).

As for the other family member that person would need to go to https://app.plex.tv/desktop#!/settings/web/player (and enable advanced settings) and check the value there, if its automatic/image only, then it would indeed make no sense that it works for them and not for you :thinking:.

Another good way to see what’s really happening is checking transcoder/sessions endpoint, i.e:
http://IP:32400/transcode/sessions?X-Plex-Token=ADMIN_TOKEN this should let you see a few more details, but might not be worth spending the time on that If I can get it to repo.

Ah sorry. I read that last post too quick.
No other setting difference and yeah, I totally forgot to click on the advanced option. It was in Automatic and I changed it to Only Image Format and it still plays files with downloaded SRT without issue. I also went back to my admin account for a sanity check and nope transcoder still runs into error.
I’m extremely confused right now as to why it works under the family member’s profile but not the Admin. I see that there is another update available. Should I install it and see if it resolves it?
I’ll try to see the sessions when I get home tonight.

Its failing for me on the most recent build and even a test build so I’m pretty sure the last build won’t fix it for you.

I was working just now with one of the PMS devs to get more details into to why it crashes and we made some progress, might actually be a PMS bug after all and not the client.

Is that family member accessing the server remotely btw?

So two things.

  1. The transcode is either not starting at all or crashing in milliseconds, cuz I could not get sessions to show anything.
  2. uhhhh… yeah… the transcoder on family member’s profile runs into errors when I’m at home or using the :32400/web, but it works outside of the network. So yeah, in short, it works when I use family member’s profile remotely but not when I use family member’s profile in the network that the server is in.

We believe we found the culprit, its a BSD specific issue and should be fixed in a future build.

I’d like to thank @Pixaro for leading me in the right direction.

You should see something like this in dmesg or /var/log/messages:

sonewconn: pcb 0xfffff801865335b8: Listen queue overflow: 193 already in queue awaiting acceptance (1 occurrences)

This is actually the culprit, we are setting a very low limit (the default of 128 on freebsd) and this was done at compile time (In previous builds its probably higher) but in any case this should be handled in the app it self, we will have a patch soon.

FYI, problem still there after installing the most recent 1.18.4.2171 build. Not sure if you guys are still working on this.

This shouldn’t be happening on that version, at least not the same error, can you look at “dmesg” output in the host or /var/log/messages and make sure you see that same error regarding the “queue overflow” ?

sonewconn: pcb 0xfffff801f19fc570: Listen queue overflow: 193 already in queue awaiting acceptance (1 occurrences)

from dmesg.today
let me know if you want the full log.

Weirdly enough, not all SRTs are triggering the failure, but most still are.

@jingweizhang0302 sorry for the long wait, but aside from fixing the constraint on the queue limit (which we control in the app now) there was always the underlying issue that this shouldn’t happen anyway and this should be fixed based on my testing, can I send you a test build to try out? (Its a test build so other bugs might be there, but just one you to give it a go with known samples that failed before).

Just let me know and I’ll DM a test build

I am also experiencing this issue. I normally set always burn subtitles because they sometimes get out of sync when playing on my Roku’s if I don’t. I recently set up a new computer and since doing so I have had issues using OpenSubtitles on some media.

I see an error transcoder failed to start on the Plex media players for Roku 3 and Roku Ultra. I just tested with a video and OpenSubtitle selection I know fails on the Roku’s, and it worked fine in the localhost web player.

Plex server is Windows 10, Ryzen 7 3700X, hardware acceleration and hardware-accelerated video encoding are disabled.

Let me know if I can provide any more info to help debug.