Emby clients pausing/buffering too often - Clients need bigger buffers

[pwhodges 2012]

  

6 hours ago, strichmo said:

I'm sorry I must be blind - I cannot find the diagnostic options section. Can you be more specific or maybe some other mode needs to be enabled to see it?

Emby Diagnostics is available as a plugin.  It is advised to use it with caution, as it is possible to break your installation with it.  Also many settings are not persistent, but need redoing after a restart of Emby.  Installing it also adds a page of subtitle options, to which the same warnings apply.

Paul

Edited December 11, 2025 by pwhodges

[strichmo 21]

2 hours ago, pwhodges said:

  

Emby Diagnostics is available as a plugin.  It is advised to use it with caution, as it is possible to break your installation with it.  Also many settings are not persistent, but need redoing after a restart of Emby.  Installing it also adds a page of subtitle options, to which the same warnings apply.

Paul

Thanks I can now see the options. If the other user meant "Override Throttle Buffer Length" - I don't think that does what he expected it does. According to this plugin, the buffer length is by default 200 seconds, which is absolutely not the preloaded buffer length on clients - It's much closer to 10 sec. So I can only assume the buffer length is much shorter and set on the Emby clients.

[ebr 16169]

2 hours ago, strichmo said:

If the other user meant "Override Throttle Buffer Length" - I don't think that does what he expected it does

Correct.  That setting does not have any effect on the client playback buffer.  That is controlled by each player in each client app (which is different on pretty much every platform).

[strichmo 21]

That's what I figured - I imagine each platform has its own memory budget and restrictions. It's a shame it is not something we can tweak as a server-provided variable though, as its just too low in some circumstances.

[brothom 177]

I have to agree with @strichmo this issue of small buffers becomes noticable especially when just started a stream. After the loading the first chunk, the player more often than not shows a spinner and then after the second chunk, playback starts normally. It's a minor thing on my end but still noticable nonetheless.

From what I've seen this issue is also more apparant when transcoding and thinking about it, I haven't seen this occur with DirectPlay.
That's probably because DirectPlay uses the HTTP Range Requests (correct me if I'm wrong) and transcoded results are being processed through FFMPEG by start seconds + duration.

Maybe the duration is (too) short and we might be better off increasing this to a slightly larger value in seconds? 

This obviously doesn't fix slow network issues but in the long run it should reduce the amount of requests and also the amount of times FFMPEG has to start up and unwind which, when added up over time, could save a ton of resources.

Edited December 11, 2025 by brothom

[scott46953 30]

12 hours ago, strichmo said:

I'm sorry I must be blind - I cannot find the diagnostic options section. Can you be more specific or maybe some other mode needs to be enabled to see it?

I'm sorry, I installed it as a plug-in so long ago that I had forgotten that it was a plug-in that you have to install in the plug-in section on the left side of the server page. I sincerely apologize about that, I've been with Emby for a very long time.. I would have to look at my email to find the date but somewhere between 5 and 7 years or it feels like..

[ebr 16169]

10 minutes ago, brothom said:

After the loading the first chunk, the player more often than not shows a spinner and then after the second chunk, playback starts normally. It's a minor thing on my end but still noticable nonetheless.

I doubt that is related to the client-side buffer size.  In fact increasing the buffered amount would just make it take longer to start the video.  I think the idea that the buffer size is going to solve latency and bandwidth issues is a bit outdated.

Our Android TV app actually used to have a buffer size setting but we found that increasing it just lead to memory problems on many devices and didn't improve playback experience.

[scott46953 30]

3 hours ago, strichmo said:

Thanks I can now see the options. If the other user meant "Override Throttle Buffer Length" - I don't think that does what he expected it does. According to this plugin, the buffer length is by default 200 seconds, which is absolutely not the preloaded buffer length on clients - It's much closer to 10 sec. So I can only assume the buffer length is much shorter and set on the Emby clients.

Buffer on the client is different depending on the device.  Example a smart TV that's older might have less memory then a newer Smart TV. Roku may have slightly more memory, fire stick may have more memory.  The Nvidia streaming box I use may have much more. If it does not have memory for the buffer then I would expect that each client would have its own buffer amount. However I could be wrong, that would have to be answered by the dev team.

[scott46953 30]

Why don't we work on why it's buffering instead of trying to tweak the issue?

[scott46953 30]

On the device download and install speed test app. I've had many people say I got good internet. I've even had people say they've tested it in the past. Or I get good speed on my phone so I know it's good.  Testing the speed on the device that you're watching emby on is necessary. Also doing a speed test from the computer that's serving emby. 

Does it do this on every device that tries to play that same stream? If so, after checking it with speed test, depending on the values, you can move on to server related buffering issues.  In which if it's sever related, I can help you with that too. I would not say I'm a pro but I have been through this myself similar situations off and on.  I've even blamed it on the client many times and already been down the road of wanting to extend the buffer just like you. But to be honest, the only thing that actually fixed it is fixing the problem that causes it, after the actual issue is identified, I can help you fix the problem, I'm sure 99,% it's incorrect settings for the appropriate setup.

Edited December 11, 2025 by scott46953

[strichmo 21]

13 minutes ago, ebr said:

I doubt that is related to the client-side buffer size.  In fact increasing the buffered amount would just make it take longer to start the video.  I think the idea that the buffer size is going to solve latency and bandwidth issues is a bit outdated.

Our Android TV app actually used to have a buffer size setting but we found that increasing it just lead to memory problems on many devices and didn't improve playback experience.

I really don't understand how you can come to that conclusion. There are many cases - maybe even common - where the internet connection is generally good enough for what they're trying to stream on average. But there is a ton of jitter that causes the bandwidth to fluctuate. So what happens is that for some minutes the buffer is acceptable, but then jitter causes the next buffer segments not to come in on time which causes a pause. Increasing the buffer amount CAN reduce this effect. 

Yes of course there are limits to what an increased buffer can do to help and I'm not suggesting its a perfect fix at all. And I do understand that for certain devices the memory budget is just not there to support a bigger buffer. I get that.

I can't claim to know how much extra memory budget remains on some of these devices, but if there is any head room an increased buffer will help some people.

22 minutes ago, ebr said:

In fact increasing the buffered amount would just make it take longer to start the video

Why can't the buffer have both a max size as well as a min playback size? The key problem is that a small buffer wastes time not downloading content because it waits for playback to catch up. It eats into precious download time on a poor quality connection.

[scott46953 30]

If you don't want to fix the actual problem and you want to keep pointing at the client buffer then I'm just going to stop responding. 

I'm trying to help you fix the buffer issues that you're experiencing. But if you don't want to diagnose, and keep pointing that the client buffer. Nobody can help you.

Edited December 11, 2025 by scott46953

[scott46953 30]

In order for it to work like other streaming apps since those seem to work for you and you're pointing at the buffer on emby.. emby uses a different type of stream than those other apps. It requires a constant data stream. Example, you may have a fiber line with 1000 MB up and down but you got a Wi-Fi router, your daughter has a laptop a phone and her own TV connected to the Wi-Fi she decided she wants to update her Sims game and wants to download 20 gigs at Max speed. Her laptop can only take 20 to 30 MB from your router leaving you with a trickling speed to watch emby with. Yes routers are supposed to prioritize video and audio but they don't always work. And then your lady friend wife whatever, has her phone and tablet connected at the same time, she decides it's time to go to work, she walks out the front door jumps in the car, her Wi-Fi signal on her phone goes down to -85 or worse which is trickling between losing the connection.. it stutters the hole wi-fi system and now all the devices are all trickling on 1 MB. And then as she pulls away and loses signal it disconnects causing a 3 to 5 second Wi-Fi pause on all the devices. Before completely disconnecting and the Wi-Fi routers then actually able to spit out 20 to 30 MB again.  And then you wonder why? Because you have one Wi-Fi name on a dual band router and even though it's supposed to separate and switch everything between 2G and 5G it still got his glitches and still has everybody running on 2G or you're in the middle of a football game and multiple devices at the location are switching between 2G and 5G causing glitching on the Wi-Fi. And then if you don't have fast internet and you got DSL which seems to run like crap when streaming emby unsteady copper wires going down the road.  Or if you're trying to get by with cheap internet because of a budget, now you're capped out with Wi-Fi problems because you need to have separate names for your 2G and 5G. And then you're trying to run it on a budget device that may not have a dedicated video card. So now your transcoding on a device that is not strong enough to transcode on top of all these other issues. I'm not saying that this is your scenario, but I'm sitting in an example for everything that can possibly go wrong including everything going wrong at the same time. If you don't diagnose it and start from the beginning, you're going to scratch your head blame it on a buffer from the client and still wonder why YouTube plays fine. The dev team has not implemented an adjustable buffer on the client side since the beginning, and to be quite honest with you I don't see them wasting their time on adding the option to resolve problem or problems that can be resolved by fixing the actual issues. They would have to rewrite the complete streaming code, and I believe that would break a lot of devices and would not be backwards compatible. I do not see them rewriting the streaming code to adjust a client to try to prevent buffering from ongoing issues.

[Luke 42077]

3 hours ago, strichmo said:

That's what I figured - I imagine each platform has its own memory budget and restrictions.

Exactly correct.

[strichmo 21]

6 minutes ago, Luke said:

Exactly correct.

And you can confirm that the buffers you're giving on clients are as big as they can be for the target platform? Because it seems to be generally universally lower than other streaming performed I've used.

[Luke 42077]

1 hour ago, strichmo said:

And you can confirm that the buffers you're giving on clients are as big as they can be for the target platform? Because it seems to be generally universally lower than other streaming performed I've used.

Yes, but most platforms don't provide control over this. For example, the web app uses the browser video player, roku uses the roku video player, smart tv apps use the system video player. They don't expose any buffer size control to developers so you get whatever the system provides.

It is really only on devices where we embed our own player that we could do this, e.g. android, windows and iOS/apple tv (to some extent). For apple devices I say to some extent because although we do embed our own player, we prioritize using the device's native player for any media that it can handle.

[Suliamu 36]

8 hours ago, scott46953 said:

And then your lady friend wife whatever, has her phone and tablet connected at the same time, she decides it's time to go to work, she walks out the front door jumps in the car, her Wi-Fi signal on her phone goes down to -85 or worse which is trickling between losing the connection.. it stutters the hole wi-fi system and now all the devices are all trickling on 1 MB. And then as she pulls away and loses signal it disconnects causing a 3 to 5 second Wi-Fi pause on all the devices. Before completely disconnecting and the Wi-Fi routers then actually able to spit out 20 to 30 MB again.

Sir, if somebody sold to you the idea that WIFI is perfect, then he lied to you. 
It is basically normal radio. The same your parents used to hear their music in their car. 
And there is interference if someone else is sending on the same channel. 
And your WIFI-card in your device works exactly the same as an old radio. 
It is receiving _every traffic_ on this channel you set it to and then only decides later if the packages it received were meant for you. 
Yes, also the traffic from your neighbor on this channel, the traffic of some kids drone that is playing outside, and also passing by cars that have wifi on this channel. 
If you want solid connections try to always use cabled LAN, if possible. 
And if you want somewhat solid WIFI connections, first what you do is choose an empty channel.  

And here is another catch: WIFI channels overlap unfortunately by design. 
That means on 2.4Ghz-Band you effectively can only choose channel 1, 6 and 11.  
And if you have so called "smart devices" all connected through WIFI then create a seperate WIFI-network on different channel just for those smart devices (which is anyway good practice).  

And just to be clear:  
I've got my emby&data at a remote place, not in my LAN, - that means my communication packages go through public communication lines to a city quite far away, and i nonetheless don't have any problems with buffering or stuttering. 

Those "drops" that you are describing are certainly not normative, especially not in a LAN, but i wouldn't even accept them on my WAN (into the public internet). 
You need to fix your internal network. 
And also that you claim that "leaving the WIFI-network" somehow brings your router down, i have never before heard of such a behaviour, and i don't think this is what really is happening. 
 

Edit: 
If you have a quite big area to cover, a big house or something, it would be maybe also a good idea to change to a WIFI-system that has a central controller. 
A system with a central controller can manage the seamless transition from the area of one AP (access point) to another and it also can manage resources "intelligently" by distribute clients. I know that Ubiquity Unifi does this, but i heard that TP-Link also has such a system by now. 
This might make your WIFI-experience better. 

Edited December 12, 2025 by Suliamu

[strichmo 21]

7 hours ago, Luke said:

Yes, but most platforms don't provide control over this. For example, the web app uses the browser video player, roku uses the roku video player, smart tv apps use the system video player. They don't expose any buffer size control to developers so you get whatever the system provides.

It is really only on devices where we embed our own player that we could do this, e.g. android, windows and iOS/apple tv (to some extent). For apple devices I say to some extent because although we do embed our own player, we prioritize using the device's native player for any media that it can handle.

Thanks for the detailed reply - it helps me understand why things are the way they are. It's unfortunate we can't improve this area of the system, but I understand you probably didn't want to use some commercial video player middleware that does provide this control.

[Luke 42077]

8 minutes ago, strichmo said:

but I understand you probably didn't want to use some commercial video player middleware that does provide this control.

There is no such thing in the browser, roku or smart tv platforms.

[strichmo 21]

2 minutes ago, Luke said:

There is no such thing in the browser, roku or smart tv platforms.

You can't use something like Bitmovin?

[Luke 42077]

25 minutes ago, strichmo said:

You can't use something like Bitmovin?

Their web player demo is just a wrapper around the html video element, and the html video element does not have any buffer size control.

[strichmo 21]

6 minutes ago, Luke said:

Their web player demo is just a wrapper around the html video element, and the html video element does not have any buffer size control.

I see.

Well I've nothing more to say then. If this is the best it can be then that's that. 

[Luke 42077]

15 hours ago, strichmo said:

I see.

Well I've nothing more to say then. If this is the best it can be then that's that. 

When I suggest to users to lower the quality setting for smoother playback, typically the response is that they want the higher quality and a larger buffer instead.

And yes that can be true on platforms where it is possible, but it's just not possible universally on every single device.

[strichmo 21]

8 hours ago, Luke said:

When I suggest to users to lower the quality setting for smoother playback, typically the response is that they want the higher quality and a larger buffer instead.

And yes that can be true on platforms where it is possible, but it's just not possible universally on every single device.

Sadly it does sound like you could probably improve the experience on a lot of platforms by increasing the buffer a bit, but that would require you to implement your own video player middleware which I see now would be a massive undertaking. So I guess it just is what it is for now.

[Luke 42077]

50 minutes ago, strichmo said:

Sadly it does sound like you could probably improve the experience on a lot of platforms by increasing the buffer a bit, but that would require you to implement your own video player middleware which I see now would be a massive undertaking. So I guess it just is what it is for now.

Like I said on android, apple and windows yes we can, and we already have the middleware to do that. You can't build your own middleware though for browser based playback. Every library that you see out there is ultimately just based on the html video element.