Conversion failed. The transcoder exited due to an error

When i start playback of a 4K media file with subtitles, it plays for a couple of seconds then exits with the title message. If i turn off subtitles, it’s fine. It’s not transcoding either way, so i don’t know what it’s erroring about. (also, audio selection is still broken on lg, please fix)

Probably has to do with the long time faulty transcoding engine for audio+subtitles.

Server Version#: 1.18.3.2129
Player Version#: Plex for LG 4.17.1

FreeNAS 11.2 (FreeBSD)

Server logs:

Dec 15, 2019 22:31:32.220 [0x811461800] ERROR - Unable to find client profile for device; platform=webOS, platformVersion=4.1.0, device=, model=OLED55C8PLA
Dec 15, 2019 22:31:32.567 [0x811257300] ERROR - [Transcoder] [segment @ 0x803a99600] Failed to open segment list 'http://127.0.0.1:32400/video/:/transcode/session/kj7o0e94tdlhnpvpcodrogpo/a48ba772-cfe6-4a8b-b0b8-f2b31870e0c6/seglist'
Dec 15, 2019 22:31:32.567 [0x80ca22200] ERROR - [Transcoder] av_interleaved_write_frame(): Broken pipe
Dec 15, 2019 22:31:32.568 [0x80c870c00] ERROR - [Transcoder] Error writing trailer of chunk-%05d: Invalid argument
Dec 15, 2019 22:31:32.584 [0x80c36fc00] ERROR - [TranscodeOutputStream] Streaming Session 0x818135018 appears to have died from under us
Dec 15, 2019 22:31:32.584 [0x80c36fc00] ERROR - Session 0x818135018 terminated
Dec 15, 2019 22:31:33.043 [0x80c870c00] WARN - Denying access to direct play of part 391519 due to terminated session
Dec 15, 2019 22:31:33.233 [0x80c870c00] ERROR - Unable to find client profile for device; platform=webOS, platformVersion=4.1.0, device=, model=OLED55C8PLA
Dec 15, 2019 22:31:33.436 [0x80ca22200] ERROR - Unable to find client profile for device; platform=webOS, platformVersion=4.1.0, device=, model=OLED55C8PLA
Dec 15, 2019 22:31:33.448 [0x80c870c00] ERROR - Unknown metadata type: folder
Dec 15, 2019 22:31:33.451 [0x80ca22200] ERROR - Unknown metadata type: folder

Now i can’t really watch anything with subtitles, especially if they have to be burned in.

Must be a faulty update pushed out.

If I were you, I’d go back to 1.17 until this issue is resolved. Just my personal opinion.

Doesn’t that cause issues if the database has updated?

Not a clue. Worked for me. Create a backup first.

Backup the whole metadata/config? I’ll wait for this to get fixed instead :wink:

So this post pinpointed the error: OpenSubtitles SRT Image Format Causing Transcoder Error

Got the queue overflow in my messages log. So it’s known about!

1 Like

Took me about 3 seconds to create a snapshot of the jail before downgrading.
According to mikec_pt there’s a proposed fix already. Why it wasn’t included in the last three releases is anybodys guess.

Never used the snapshot feature before, it’s like a shadow copy/diff, right?

Yes. It’s even compatible with windows shadow copy on the folders you share with your windows clients.

This is fixed in beta (1.18.4)

Actually there’s a larger issue that is still being addressed but we were also tied to the OS limits and in FreeBSD this happens to be supper low (128) and can’t actually be changed via sysctl since it comes from a header… but I don’t want to get into super detailed stuff, the tl;dr is that in 1.18.4 we now take control of that limit rather than relying on the header. This will fix the crashes on BSD servers. But there’s still work to be done to improve why we actually end up n this situation when transcoding subs (and a few other cases that you might not even noticed before)

The question is why it transcodes subtitles to begin with. It’s the age old bug/feature that transcodes audio if there’s a subtitle too. My TV can handle 7.1 audio, but when paired with a subtitle it has to transcode.

Well if the client can’t DP subtitles (i.e SRTs) it ofc needs to transcode, but that is off topic!

Still not working in 1.18.4.2164. Check my other thread.

Yeah i saw it. The “forced subtitle burning because of audio” issue is another one for sure, but i heard it was gonna get fixed eventually.

I’m on 1.18.4.2171 and it works sometimes, but some files still get the queue overflow, now with 193.

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