Throttling Not Happening

[Neminem 1864]

Tdarr can monitor libraries and automate it

[specy 0]

Any update? Can we have an ETA On the fix please?

[derfy79 9]

@Luke@sa2000

 

Hello, as I would really appreciate it if you could fix this bug, I've set up a test environment to properly diagnose the problem.

Unraid server 7.2.3 with official 4.9.3 Emby Docker with hardware transcoding enabled.

What happens when I have a problematic file is that after a few minutes of playback (2 or 3), the video pauses for 1 second and then resumes... this happens repeatedly.

I have a file with 3 different subtitles (SUBRIP).

I've noticed that only one of the subtitle files is problematic. The one called "forced." If I extract it from the MKV file, I no longer have the problem; if I don't select it when playing the video, I don't have the problem. But I'm still seeing some strange things in the logs.

Another observation: if I use Emby Web with Chrome or Edge, it doesn't seem to have any problems either. Even though I'm still seeing some strange things in the logs.

If I install Diagnostic Option Plugins and enable "Disable HLS subtitles," I don't have any problems.

If you'd like me to provide you with logs and/or run some tests, I can do that for you. Thank you.

[visproduction 369]

Here is a guess.

Subrip is graphic based subtitles and if there no subtitles in the first few minutes, perhaps estimating the transcoding seems fine and begins, but when the graphic subtitles hit, the hardware cannot handle the transcoding in real time at the current transcoding settings.  There is no way for Emby to predict that several minutes into the media, the transcoding settings will take longer than in real time and so the transcoding will buffer and stall.

This would fit all the symptoms, I read.  Maybe I missed something.

Can anyone else recreated the problem? 

I made a case in an earlier post, that this is a file mangement issue.  If an admin wants to transcode, easily without any stuttering, then add hardware or support encoders cards to handle the resolution, even when a subrip graphic subititle starts 3 minutes into a media, or, lower the resolution transcoding settings.  Trying to get Emby to analyze an entire media length, prior to transcoding, is not a good solution.  If this was setup, it would probably fail to work well, cause delays for any user who leaves it switched on and make people think that Emby is broken.   WIth better hardware or transcoding settings, even the tough subrip might work fine.  At most, I would suggest just to have an analzye test that goes further into the media and helps a user find the best transcoding settings and not make this feature into anythng automatic.

If several people can see this issue then maybe adjust Emby to look a little further into the media to test for transcoding. I don't think there is anything to fix, if it only happens to one setup.

 

Edited April 10 by visproduction

[derfy79 9]

I'm not the only one in this situation... and I don't think my hardware is the problem either... this problem didn't occur with version 4.7 and below of Emby.

[donniedarko83 12]

I am in the same boat but no one really cares. I have made a thread with the exact same issue years ago. Just disappointing 

[visproduction 369]

Aha... OK. That subrip graphic does force, a full video transcoding, I believe, in order to burn in the subtitles.  So, starting perhaps with no transcoding is needed and then the first subtitle appears and forces a transcoding. that could fit the symptoms.  Maybe the orced subrip title is no longer noticed in the media and that fools the test and transcoding is not started at all or at some higher quality setting that just fails when the subs finally show up, three mnutes in, or whatever.
Maybe the fix is to make sure Emby notices subrip forced graphic sub in the media metadata. 

Also an issue would be that some metadata for some media does not have all the data at the beginning of the media file. This is the optimized way to have media for streaming, but who knows where the media was created and by what software.  If it is not optimized with the metadata available at th start of the file, then the forced sub info can be missed.  This can happen when anyone makes a copy with a 3rd party software encoder. You cannot easily tell from one media to another if the data is optimized.  That is an issue that is not the fault of Emby, if that is what's happening.

 

Edited April 10 by visproduction

[derfy79 9]

If I watch the same video without transcoding, with the problematic subtitle enabled, everything works fine.

[visproduction 369]

Der,
Transcoding starts based on the end use's bandwidth.  What do you mean watch without transcoding?  Are you using a different player.  Is this local verus remote?  Is it with a different TV or connection?

Some end user player app or browser can play video directly and some cannot?  Transcoding clicks on when the end user needs it.  So, one user can get direct and the another with a different setup cannot and has to have transcoding. Maybe something like that is happening.

 

 

Edited April 10 by visproduction

[derfy79 9]

yes it's local vs remote playback.... this is the reason of trancoding : TranscodeReasons=ContainerBitrateExceedsLimit 

[Lessaj 549]

1 hour ago, visproduction said:

Subrip is graphic based subtitles

Incorrect, it's an SRT embedded in the MKV, so it's just text.

[visproduction 369]

OK.  I thought subrip is the term used for graphic subs that probably originally came with a blu-ray disc, which I think mostly uses graphic subs. You can often tell just by the size of the embedded file which shows up with MKVTools.  Subtitle graphics are usually 15 to 25 MB, while srt files are always just 150 KB or so. 
https://blog.thescorpius.com/index.php/2017/07/15/presentation-graphic-stream-sup-files-bluray-subtitle-format/

Converter online - useful link: https://subtitletools.com/convert-sub-idx-to-srt-online

Edited April 11 by visproduction

[visproduction 369]

8 hours ago, derfy79 said:

yes it's local vs remote playback.... this is the reason of trancoding : TranscodeReasons=ContainerBitrateExceedsLimit 

Remote playback can get restricted streaming from all sorts of network, Wifi, TCP cable and even hardware issues.  Sometimes it can be hidden.  I've seen TV Ethernet ports only able to do 10 / 100 and the incoming signal from a workstation has a 1GB Ethernet cable and bandwidth. Just that cross connection kills the feed after 20 seconds. If there is a Wifi connection, then even a fireplace iron stoker rod 2 feet away can kill the signal.  Then there is the TV App, the browser, the OS that doesn't support direct, kicks it to transcoding and the transcoding is set high that works locally but not for remote with streaming issues.  That can kill the stream and start a stutter.

[pwhodges 2091]

7 hours ago, visproduction said:

OK.  I thought subrip is the term used for graphic subs that probably originally came with a blu-ray disc, which I think mostly uses graphic subs

DVD and Bluray subs are called VobSub and PGS.  As I recall, Subrip was originally named after an old program (called Subrip) which ripped text from VobSub (and subsequently other graphical formats) using OCR.  The extension SRT is short for SubRip Text, I think.

Paul

[derfy79 9]

11 hours ago, visproduction said:

Remote playback can get restricted streaming from all sorts of network, Wifi, TCP cable and even hardware issues.  Sometimes it can be hidden.  I've seen TV Ethernet ports only able to do 10 / 100 and the incoming signal from a workstation has a 1GB Ethernet cable and bandwidth. Just that cross connection kills the feed after 20 seconds. If there is a Wifi connection, then even a fireplace iron stoker rod 2 feet away can kill the signal.  Then there is the TV App, the browser, the OS that doesn't support direct, kicks it to transcoding and the transcoding is set high that works locally but not for remote with streaming issues.  That can kill the stream and start a stutter.

That has nothing to do with any of this; the logs clearly indicate that there is a problem.

[visproduction 369]

Thanks.  I was wrong. SubRip is the srt.  So that's not it.  Sorry. 

So, does transcoding gets triggered because either the connection speed or some test of the end user's ability to play back fails?  Did an older version of Emby work and now a new version doesn't? 

Maybe get some quality test media with different resolutions and see which media works for direct play.  That could help find what forces the transcoding and make it easier to fix.

Edited April 11 by visproduction

[derfy79 9]

On 4/10/2026 at 11:20 AM, derfy79 said:

@Luke@sa2000

 

Hello, as I would really appreciate it if you could fix this bug, I've set up a test environment to properly diagnose the problem.

Unraid server 7.2.3 with official 4.9.3 Emby Docker with hardware transcoding enabled.

What happens when I have a problematic file is that after a few minutes of playback (2 or 3), the video pauses for 1 second and then resumes... this happens repeatedly.

I have a file with 3 different subtitles (SUBRIP).

I've noticed that only one of the subtitle files is problematic. The one called "forced." If I extract it from the MKV file, I no longer have the problem; if I don't select it when playing the video, I don't have the problem. But I'm still seeing some strange things in the logs.

Another observation: if I use Emby Web with Chrome or Edge, it doesn't seem to have any problems either. Even though I'm still seeing some strange things in the logs.

If I install Diagnostic Option Plugins and enable "Disable HLS subtitles," I don't have any problems.

If you'd like me to provide you with logs and/or run some tests, I can do that for you. Thank you.

Perhaps the Emby dev could start to stop ignoring us and try to find a solution to this problem?
 

@sa2000 @Luke

[sa2000 822]

16 hours ago, derfy79 said:

Perhaps the Emby dev could start to stop ignoring us and try to find a solution to this problem?

This is an open issue with the development team. 

I understood that there was a workaround for the issue outlined in a post in this thread here 

 

Edited April 13 by sa2000

[derfy79 9]

14 hours ago, sa2000 said:

This is an open issue with the development team. 

I understood that there was a workaround for the issue outlined in a post in this thread here 

 

Yes, there is a workaround, but you need to have the diagnostic plugin installed, and you have to reapply the workaround every time you restart. That said, if you need someone to test and/or provide logs to help you, I'm here for that...

[derfy79 9]

Two months later and still nothing... it seems the developers aren't working very hard on this problem.

[BlackDub 52]

7 hours ago, derfy79 said:

Two months later and still nothing... it seems the developers aren't working very hard on this problem.

Two months or two years? XDDDDDD

[FranBeltran 2]

Root cause found + working workaround for "Too many packets buffered for output stream 1:1" / "Conversion failed" (and the "throttling not happening" symptom)

After two years with this bug I spent a day reproducing it on my server (Emby 4.9.3 → 4.9.5, ffmpeg 5.1-emby_2023_06_25_p4, GTX 1080, Emby for Android/Android TV, Proxmox LXC). Here is what is actually happening and a server-side workaround that needs no changes to the media files and no Diagnostics-plugin tricks.

1. What ffmpeg is asked to do

For every embedded *text* subtitle track, Emby adds a WebVTT HLS output and copies the full video stream into it, so the segment muxer cuts the .vtt files every 3 s in sync with the video:

-map 0:6 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt ... -segment_format webvtt ... _s6_%d.vtt
-map 0:8 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt ... -segment_format webvtt ... _s8_%d.vtt

Stream mapping in the log:

Stream #0:6 -> #1:0 (subrip (srt) -> webvtt (native))
Stream #0:0 -> #1:1 (copy)

 

2. Why it dies

ffmpeg 5.1 cannot write the header of that output until the WebVTT encoder has received its first cue. Until then every copied video packet is queued in the muxing queue. With a sparse track (in my case "Castellano Forzados (SRT)": 4 cues in 2 h 01, the third at 4:53 and the fourth at 2:02:11) the header is never written, the queue reaches ~10k packets after ~60 s and ffmpeg exits:

09:24:50.323 Too many packets buffered for output stream 1:1.
09:24:50.399 Conversion failed!

Two side effects explain the other symptoms reported in these threads:
- `>> ThrottleBySegmentRequest: ... TranscodingPosition: 00:12:57` stays frozen for the whole session (Emby measures progress on the stalled subtitle output), so throttling never kicks in → ffmpeg races at full speed and fills the queue even faster.
- After ffmpeg dies, every request for a `.vtt` of the sparse track waits 6030 ms before Emby answers with an empty file; with 3 s segments the client plays at half speed and re-buffers every 6 s.

Everything that "helps" in these threads is consistent with this: `-max_muxing_queue_size 100000` just delays the overflow (and costs GBs of RAM because the queued packets are the 4K video), "Disable HLS Subtitles" removes the WebVTT outputs (but forces burn-in, which on a 59 GB remux takes >15 s to start and gets killed by the watchdog: exit code 137 in a loop), removing/stripping subtitle tracks makes the track dense or absent. Most Spanish/other-language remuxes carry a "forced" text track with a handful of cues, so this hits "every file".

Fix suggestion for the devs (@Luke @sa2000): don't copy the 4K video into the WebVTT outputs. A 16x16 @ 1 fps dummy video split off the filter graph gives the same segment cadence with 1 packet/s (hours of headroom before the header), or initialise the WebVTT encoder eagerly so the header is written at start. The first option is exactly what my workaround does and it fixes all three symptoms.

3. Workaround (Linux native install, root)

A small wrapper replaces `/opt/emby-server/bin/ffmpeg` (real binary kept as `ffmpeg.real`) and rewrites only the subtitle outputs:

[0:0]split=2[__m0][__d0];[__d0]fps=1,scale_cuda=w=16:h=16:format=nv12,hwdownload,format=nv12,scale=16:16,format=yuv420p,split=2[__dummy0][__dummy1];[__m0]<Emby's original graph>
-map 0:6 -map [__dummy0] -an -c:v:0 rawvideo -c:s:0 webvtt ...

Verified on my server: no `Too many packets`, throttling works (`ThrottleBuffer 130s`), forced cues at 0:54 and 4:53 render in Emby for Android, 100 segments without a single stall, CUDA and software paths, remux commands too (a GPU decode is added just for the dummy). Survives Emby updates via a systemd path/timer unit. Attached zip with README, wrapper, installer, systemd units and a curl-based HLS client simulator that prints a pass/fail summary from the ffmpeg log.

apt install -y busybox-static          # Emby >= 4.9.5 ships its own glibc; the wrapper needs a static shell
mkdir -p /root/emby-fix && cd /root/emby-fix   # unzip here
chmod +x *.sh && ./install-ffmpeg-wrapper.sh && ./install-autoupdate.sh

Uninstall: `mv /opt/emby-server/bin/ffmpeg.real /opt/emby-server/bin/ffmpeg` and disable the two systemd units.

Not covered: Docker images (would need the same wrapper inside the container), OpenCL/Vulkan filter graphs (passed through untouched). Use at your own risk; it is a shell script, read it before installing.

Happy to provide logs or test a beta build.

-- version --

Causa raíz encontrada + solución funcional para "Too many packets buffered for output stream 1:1" / "Conversion failed" (y el síntoma "throttling not happening")

Tras dos años con este fallo he dedicado un día a reproducirlo en mi servidor (Emby 4.9.3 → 4.9.5, ffmpeg 5.1-emby_2023_06_25_p4, GTX 1080, Emby for Android/Android TV, LXC en Proxmox). Esto es lo que ocurre realmente y una solución en el servidor que no requiere tocar los archivos ni trucos con el plugin Diagnostics.

1. Qué le pide Emby a ffmpeg

Por cada pista de subtítulos de *texto* embebida, Emby añade una salida WebVTT para HLS y copia dentro el stream de vídeo completo, para que el muxer de segmentos corte los .vtt cada 3 s en sincronía con el vídeo:

-map 0:6 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt ... -segment_format webvtt ... _s6_%d.vtt
-map 0:8 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt ... -segment_format webvtt ... _s8_%d.vtt

Mapeo en el log:

Stream #0:6 -> #1:0 (subrip (srt) -> webvtt (native))
Stream #0:0 -> #1:1 (copy)

 

2. Por qué muere

ffmpeg 5.1 no puede escribir la cabecera de esa salida hasta que el codificador WebVTT recibe su primer cue. Hasta entonces, cada paquete de vídeo copiado se acumula en la cola de muxing. Con una pista escasa (en mi caso "Castellano Forzados (SRT)": 4 cues en 2 h 01, el tercero a 4:53 y el cuarto a 2:02:11) la cabecera nunca se escribe, la cola llega a ~10.000 paquetes a los ~60 s y ffmpeg termina:

09:24:50.323 Too many packets buffered for output stream 1:1.
09:24:50.399 Conversion failed!

Dos efectos secundarios explican el resto de síntomas de estos hilos:
- `>> ThrottleBySegmentRequest: ... TranscodingPosition: 00:12:57` se queda congelado toda la sesión (Emby mide el progreso sobre la salida de subtítulos bloqueada), así que el throttling nunca entra → ffmpeg va a máxima velocidad y llena la cola aún antes.
- Cuando ffmpeg muere, cada petición de un `.vtt` de la pista escasa espera 6030 ms antes de que Emby responda con un fichero vacío; con segmentos de 3 s el cliente reproduce a mitad de velocidad y rebufferiza cada 6 s.

Todo lo que "ayuda" en estos hilos encaja: `-max_muxing_queue_size 100000` solo retrasa el desbordamiento (y cuesta GB de RAM porque lo encolado es vídeo 4K), "Disable HLS Subtitles" elimina las salidas WebVTT (pero fuerza el burn-in, que en un remux de 59 GB tarda >15 s en arrancar y el vigilante lo mata: código 137 en bucle), y quitar pistas de subtítulos las hace densas o inexistentes. La mayoría de remuxes en castellano (y otros idiomas) llevan una pista de texto "forzados" con un puñado de líneas, por eso afecta a "todos los archivos".

Propuesta de corrección para los desarrolladores (@Luke @sa2000): no copiar el vídeo 4K en las salidas WebVTT. Un vídeo de relleno de 16×16 a 1 fps sacado del grafo de filtros da la misma cadencia de segmentos con 1 paquete/s (horas de margen antes de la cabecera); o inicializar el codificador WebVTT de forma anticipada para que la cabecera se escriba al inicio. La primera opción es exactamente lo que hace mi solución y corrige los tres síntomas.

3. Solución (instalación nativa en Linux, root)

Un pequeño wrapper sustituye a `/opt/emby-server/bin/ffmpeg` (el binario real se conserva como `ffmpeg.real`) y reescribe solo las salidas de subtítulos:

[0:0]split=2[__m0][__d0];[__d0]fps=1,scale_cuda=w=16:h=16:format=nv12,hwdownload,format=nv12,scale=16:16,format=yuv420p,split=2[__dummy0][__dummy1];[__m0]<grafo original de Emby>
-map 0:6 -map [__dummy0] -an -c:v:0 rawvideo -c:s:0 webvtt ...

Verificado en mi servidor: sin `Too many packets`, throttling operativo (`ThrottleBuffer 130s`), los forzados de 0:54 y 4:53 se pintan en Emby for Android, 100 segmentos sin un solo corte, rutas CUDA y software, y también comandos de remux (se añade una decodificación en GPU solo para el relleno). Sobrevive a las actualizaciones de Emby mediante unidades systemd path/timer. Adjunto zip con README, wrapper, instalador, unidades systemd y un simulador de cliente HLS con curl que imprime un resumen pasa/falla a partir del log de ffmpeg.

apt install -y busybox-static          # Emby >= 4.9.5 incluye su propia glibc; el wrapper necesita un shell estático
mkdir -p /root/emby-fix && cd /root/emby-fix   # descomprimir aquí
chmod +x *.sh && ./install-ffmpeg-wrapper.sh && ./install-autoupdate.sh

Desinstalar: `mv /opt/emby-server/bin/ffmpeg.real /opt/emby-server/bin/ffmpeg` y desactivar las dos unidades systemd.

No cubierto: imágenes Docker (habría que meter el mismo wrapper dentro del contenedor) y grafos OpenCL/Vulkan (se dejan intactos). Úsalo bajo tu responsabilidad; es un script de shell, léelo antes de instalarlo.

Puedo aportar logs o probar una beta.

embyffmpegwrapper.zip