Error when transcoding movie - Conversion Failed

[Luke 40069]

On 4/15/2025 at 11:16 AM, smokey7722 said:

I have this same issue and the diagnostics options workaround posted aboved seems to be resolving it for me...

• Install the Diagnostic Options plug-in
• Scroll down to the Parameter Adjustment section
• In Text to Replace:  -segment_write_temp 1
• In Replacement Text: -segment_write_temp 1 -max_muxing_queue_size 100000
• Save

The stream fail / end user freeze or pausing happens on all 4K/transcoding streams to those external of my network but so far with the above max_muxing_queue_size setting in place, the issue has stopped.

HI, yes we've looked at that before. The problem is that will also cause other failures, but yes in certain situations it might help.

[ctaranto 14]

Luke,

This appears to be an issue with ffmpeg.  I would be good to rebase on the latest and add all the magic Emby sprinkles into it.  Hopefully that would resolve it (but certainly not a guarantee).  The latest Emby ffmpeg is from 2023 and I'm sure a lot of development has been done since.

Alternatively, a more sticky option for the many of us who NEED this setting for Emby to work at all.

-Craig

 

[smokey7722 15]

9 hours ago, Luke said:

HI, yes we've looked at that before. The problem is that will also cause other failures, but yes in certain situations it might help.

Yea I get it.  So far I haven't run into other failures but without this workaround almost all 4K transcoded streaming external of my network (90% of it) constantly fail.  So while this may not be the permanent fix, it's certainly needed - or another workaround is.

[himisk71 3]

On 4/13/2025 at 2:12 PM, ctaranto said:

On March 10 you mentioned that without the diagnostic setting, your videos would pause every so often.  That means with the setting, things worked.

What changed between then and now?

I didn't really see any rules about when something played well and when it didn't. But the ffmpeg line often helped.But it wasn't a cure-all.
I'm currently doing the following:
- Using TDarr to delete all internal subtitles from the video files, as well as other stuff (image files, etc.)
- Setting up a new Docker with Emby Stable 4.8.11
- Using Bazarr to download new subtitles (external, srt)
And now when I transcode, it either takes 3-5 seconds to start, or it might freeze for a few seconds after 2 seconds – but then the stream runs! Subtitles aren't a problem with this either, since they're external.
It'll probably take another week until all my transcoding is complete, but if it works like this – OK.

Edited April 18 by himisk71
language

[smokey7722 15]

6 hours ago, himisk71 said:

I didn't really see any rules about when something played well and when it didn't. But the ffmpeg line often helped.But it wasn't a cure-all.
I'm currently doing the following:
- Using TDarr to delete all internal subtitles from the video files, as well as other stuff (image files, etc.)
- Setting up a new Docker with Emby Stable 4.8.11
- Using Bazarr to download new subtitles (external, srt)
And now when I transcode, it either takes 3-5 seconds to start, or it might freeze for a few seconds after 2 seconds – but then the stream runs! Subtitles aren't a problem with this either, since they're external.
It'll probably take another week until all my transcoding is complete, but if it works like this – OK.

Interesting thing is it's often content with no subtitles for me that have issues.

[FranBeltran 2]

Any ETA to see the fix in stable?

[ctaranto 14]

On 4/18/2025 at 11:42 AM, himisk71 said:

- Setting up a new Docker with Emby Stable 4.8.11
 

Personally, I wouldn't run Emby on anything but bare metal with native access to the CPU and GPU.  While others may have success with running it in a VM or Docker, that's just another variable with infinite settings/options which can affect the outcome.

Running on my very old hardware, Emby can transcode anything I throw at it (as long as I use the max_muxing_queue_size override).

 

[BuzStringer 33]

7 minutes ago, ctaranto said:

Personally, I wouldn't run Emby on anything but bare metal with native access to the CPU and GPU.  While others may have success with running it in a VM or Docker, that's just another variable with infinite settings/options which can affect the outcome.

Running on my very old hardware, Emby can transcode anything I throw at it (as long as I use the max_muxing_queue_size override).

 

It can't do AV1 / H.265 without newer hardware, and it seems a waste to dedicate all the power just for Emby imo

[ctaranto 14]

All it needs is a "cheaper" GPU.  I'm running an ancient nvidia 1660 Super and it hums right along, able to handle multiple concurrent transcodes.

I also didn't dedicate this server to Emby.  It runs all my file backups and pushes them to the cloud.  It also servers other minor purposes.

Edited April 25 by ctaranto

[Luke 40069]

22 hours ago, FranBeltran said:

Any ETA to see the fix in stable?

Hi, are you saying you've tried the beta channel?

[himisk71 3]

19 hours ago, ctaranto said:

Personally, I wouldn't run Emby on anything but bare metal with native access to the CPU and GPU.  While others may have success with running it in a VM or Docker, that's just another variable with infinite settings/options which can affect the outcome.

Running on my very old hardware, Emby can transcode anything I throw at it (as long as I use the max_muxing_queue_size override).

 

Emby for Docker is official, and I see no reason to make it worse than other systems.
The problems stem more from the video files themselves (included subtitles, fonts, etc.), and Emby isn't very good at playing them well. Maybe Plex does this better. Or Jellyfin. But since Emby is still the best system, I've gone the other way and prepared the files as best I can for playback. I extracted subtitles as SRT, deleted image and text files from the container, maintained the order of the files in the container, etc. Apart from a longer wait time at the beginning, every file now plays continuously during transcoding.

[CaiShen 0]

N150 显示有核显，无法调用。大量用户用户反应，据说飞牛已经修复

[FranBeltran 2]

5 hours ago, Luke said:

Hi, are you saying you've tried the beta channel?

Hi, I can't test the beta channel on my system at the moment. But I have seen the changelog and there are several changes related to this problem, maybe one of them will solve it...

I'll try to set up a test setup to try the beta, but I don't know when I'll be able to...

[ctaranto 14]

@himisk71Could you share 10 minutes of the video file giving you trouble?  I can try playing it on my side to see if the issue persists.

[shiremail 3]

Quote

 

For those who are having the same issue, here's what I did to fix this in my environment:

Install the Diagnostic Options plug-in
Scroll down to the Parameter Adjustment section
In Text to Replace:  -segment_write_temp 1
In Replacement Text: -segment_write_temp 1 -max_muxing_queue_size 100000
Save

 

I have the same issue and those settings solved it. This can be reproduced with the latest stable and beta Version 4.9.0.52. If this can't be solved otherwise, a direct switch in the settings which does the same than the entries in the parameter adjustment section would be great.

[allanp81 0]

i wouldn't bother posting any updates, the devs clearly have no interest in helping.

[Luke 40069]

Hi, we’ll take another look at it. Thanks.

[ctaranto 14]

In my opinion, either a rebase of the latest ffmpeg with the Emby secret sauce, or a sticky option for this override so it doesn't randomly get lost during restarts, updates, etc.

 

[smokey7722 15]

On 5/9/2025 at 7:39 AM, ctaranto said:

In my opinion, either a rebase of the latest ffmpeg with the Emby secret sauce, or a sticky option for this override so it doesn't randomly get lost during restarts, updates, etc.

 

Or really anything at this point.  I'm seeing this more often and the "workaround" isn't 100% unfortunately.

[Luke 40069]

HI, yes we are working on updating our ffmpeg build. Thanks.

[shiremail 3]

Can somebody test this issue with the Android TV client (I used the armv7 version before)? I can't reproduce this error with the 'old' client.

[smokey7722 15]

On 6/6/2025 at 1:03 AM, shiremail said:

Can somebody test this issue with the Android TV client (I used the armv7 version before)? I can't reproduce this error with the 'old' client.

All the clients i have direct access to are Shield's.  Some remote family members have random client devices though.