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

[pwhodges 2012]

2 hours ago, RanmaCanada said:

The technical ignorance on the forums has been getting a little too strong lately with the ignorant touting their ignorance as a strength while telling those of us who are knowledgeable that we're wrong because they said so.

Be kind.  We all started ignorant; and the actions of streaming protocols are perhaps rather esoteric for those not directly concerned with them.

I myself am unclear about the details of modern streaming.  I have been working with computer software since 1970, and even wrote the networking layer of a commercial communications product around 1985; but things change, and it can be hard even for those relatively knowledgeable to keep up with things which are not one's own direct concern.

My concern and sadness is not for people's ignorance, but for their unwillingness to accept expert advice and to learn from those whose job is dealing with the problems they face.  It is necessary to accept (in all parts of life) that the answer is not always what you think it "should" be.

Paul

[RanmaCanada 494]

5 hours ago, pwhodges said:

Be kind.  We all started ignorant; and the actions of streaming protocols are perhaps rather esoteric for those not directly concerned with them.

I myself am unclear about the details of modern streaming.  I have been working with computer software since 1970, and even wrote the networking layer of a commercial communications product around 1985; but things change, and it can be hard even for those relatively knowledgeable to keep up with things which are not one's own direct concern.

My concern and sadness is not for people's ignorance, but for their unwillingness to accept expert advice and to learn from those whose job is dealing with the problems they face.  It is necessary to accept (in all parts of life) that the answer is not always what you think it "should" be.

Paul

I am being kind by not attacking them directly.  I am not going to hold their hand and tell them it's alright to be ignorant and ignore the explanations from experts just becase they believe diffrerently.  Covid has made it so people embrace their stupidity and to attack those who have knowledge.  I won't stand for it as Idiocracy should not be the prophecy it has turned out to be.

[visproduction 315]

Related to Starlink multi source satellite and TCP packets issue, video codec compression types and how that can affect playback with TCP transmission over networks with too many 'out of order' packets.  It seems like the video codec type, the bitrate and audio / video compression, number of I frames, etc., all can create strange effects when networks have jitter and other non-optimal delivery specs.  I think certain codecs with different encoding methods probably are more forgiving for lost and 'out of order' packets.  The right test would be to have the exact same original copy of test video content.  Also, somehow make sure that the first source sends the content with the same video and audio codec, bitrate that Emby does.  Just because you might actually start with the same test video, it won't be necessarily sent with the same codecs to the end user playback.

https://www.ietf.org/slides/slides-iepg-starlink-protocol-performance-00.pdf

Emby, I think often converts to .mp4 to allow the user to playback the content easily in a browser, but that could change, depending on the users' end hardware.  I have not dug into this with Emby transcoding choices.  Here is a paper that shows how .mp4 deals with 'out of order' packets.  Satellites delivery has the design issue of trying to handle 'out of order' packets and it seems like it takes a lot more effort to solve this, than cabled or fiber channel delivery. 

https://www.eecs.qmul.ac.uk/~tysong/files/MMCN09-QoE.pdf

Quote

Their research shows that the video quality remains constant until the PLR reaches certain value and that the higher the average bit rate, the lower the PLR after which the video quality drops. This is due to the constant packet size with which higher bit rates are achieved by more packet units. However, we believe that the bit-rate has no direct link to user experience concerning packet loss because video content is represented by a series of frames. Bit-rate only decides the balance between the frame rate and the quality of each frame.

(PLR is Packet Loss Ratio.)  With 'out of order' packets, the end user TCP controller, has a maximum number of packets it will accept, as being 'out of order' and then reject all the remaining packets since the first 'out of order' packet and re-request the entire group again... you get immediate buffering.  Each OS either in a workstation, mobile or TV has some system of getting an average needed number of 'out of order' packets it will accept before dumping the group.  TCP/IP measurement for this is RWIN.  I think the average was around 25 to 30 packets 1500 MTU of 1460 + 40 bit header, so the RWIN was set at around from 28,000 to 37,500.  That was wayback in the 90's, when the settings was adjustable.  I think all OS now does an average setting and fixes it to a typical Internet traffic needs with some auto adjustment that probably takes a long period of problem connections to slide upwards.  If the RWIN is conservative and lower, then the response time for any user click changes is faster.  I know when I had to fix connection to field offices in Africa, turning up the RWIN to a factor of 40 to 50 times the MTU would allow the main office in Boston to connect to African field offices.

1. Are these TCP settings automatically balanced for an average Internet video exchange and does that mean satellite delivery with higher packet loss issues has more playback issues? It seems this is probably true.
2. How does each user playback hardware automatically adjust upward to compensate for satellite 'out of order' packet issues? 
3. How quick is this auto adjustment for each test hardware? 
4. Does the TCP packet handling in each hardware need a lot of errors to slide up a little? 
5. Does the new RWIN acceptance for 'out of order' packets stay there or does it revert back to the average? 
6. Are newer codecs more forgiving for end user playback on packet problem networks, like satellite delivery? 
7. Is the test video from one source exactly the same data stream delivered by Emby, even if they both start with the same master video? 
8. Can an Emby buffer cache be automatically increased when buffering is experienced? 
9. Would the Emby buffer cache help out of order packets that are being discarded by the TCP settings in the user's hardware? 
10. Isn't that a hardware level that media server software cannot control?  The TCP packet controller would have to auto adjust. 
11. Emby can request to buffer more seconds, but if the TCP handling from the user's hardware just keeps discarding TCP packet groups because the 'out of order' packet limit is reached, say 25 packets where one was missing, so all 25 were dumped and rerequested? If that happens, then Emby buffering won't help, because the buffer will keep never see the discarded TCP packets that were dumped by the user's hardware TCP settings.
12. Don't you have to adjust the auto TCP policy of the hardware to fix this?

I think to get to the bottom of this, some of these questions need to be looked at and not just skipped over, as not important.  To be clear, I have not done anything with Emby's transcoding or video buffering. I just don't use it.  But I think getting to the bottom of these issues, requires first making sure end delivery of a test video that seems to work is exactly the same end copy of the data file in both delivery methods.  Youtube, Netflix and Emby need to be sending the exact same data to the end user and not two different audio / video codecs and compression rates.  Just starting with the exact same test video source is not proof that the end delivery media data from two different sources is the same.

I hope this helps.

Edited March 10, 2024 by visproduction

[PixelWizard 7]

I have same problem, my parents never had problems and issue and from this weekend, only have buffering and buffering... i tried from more locations and always same. What happen ? Client app problem? 

[unisoft 352]

One thing to check when on WAN is embys automatic setting for video playback. It simply has never worked for me on cable broadband connection (1.2gbs down 105mbps up). I have to set Apple TV as 20mbps because that's the Apple specs of Apple TV 4K 2017 for max bit rate for HD video, and for LG tvs something less than the upstream of the server so 80mbps in my case. I usually only have 1 or 2 users streaming and most of my HD video is 11mbps for TV content and up to 35mbps for movies.

If I don't do this, and leave as automatic, I get auto detect doing a stupidly low rate which then transcodes and breaks up rather than direct play which the bandwidth is easily capable of.

Doing it this way for me has worked for several years. Reported to Luke a few times but nothing done to WAN speed detection.

Edited March 12, 2024 by unisoft

[igorbr 7]

Hi all,

I was reading this post and it looks like a joke!

While the OP is asking for more buffer others are saying about every kind of no sense things that is not the solution for the OP question.

I have the same problem as the OP. In my case, both emby server and clients are at the same local network and everything is really fast.

The problem only comes when watching IPTV, so the server uses internet to get the content, as we know, internet is not always perfect and stable, sometimes it has some seconds of lower rates, based on this, the buffer is usually only 10 seconds so the streaming can not survive some instability moments. Of course some jerk could say, get a better internet, your problem is not emby it is your internet and all the kind of no sense opinions.

The true is, if Emby could keep a bigger buffer it would have much more chance to keep the streaming working fluent also when ups and downs happens.

10 seconds of buffer is really a small amount.

I use another IPTV client and I have the option to set how many seconds of buffer I want to keep, it is the way to do it.

@Lukecould you please take a gentle look at this thread?

Thanks

[hjason7812 34]

5 hours ago, igorbr said:

Hi all,

I was reading this post and it looks like a joke!

While the OP is asking for more buffer others are saying about every kind of no sense things that is not the solution for the OP question.

I have the same problem as the OP. In my case, both emby server and clients are at the same local network and everything is really fast.

The problem only comes when watching IPTV, so the server uses internet to get the content, as we know, internet is not always perfect and stable, sometimes it has some seconds of lower rates, based on this, the buffer is usually only 10 seconds so the streaming can not survive some instability moments. Of course some jerk could say, get a better internet, your problem is not emby it is your internet and all the kind of no sense opinions.

The true is, if Emby could keep a bigger buffer it would have much more chance to keep the streaming working fluent also when ups and downs happens.

10 seconds of buffer is really a small amount.

I use another IPTV client and I have the option to set how many seconds of buffer I want to keep, it is the way to do it.

@Lukecould you please take a gentle look at this thread?

Thanks

You problem.can be solved by doing this. 

Setup the server for dvr recording. That way you could record all of what you want to watch and not have to deal with internet issues. Unless you want to watch live TV then you still have the issue where I can't help you with that other than suggesting you oirchase a better router to handle the bandwidth coming through to your server. Sometimes this helps with these types of situations.. good luck hope this helps you

[RanmaCanada 494]

@igorbrI'll be that jerk. Even the IPTV client software like implayer, MOL2 and MOL3, etc only give you a 10 second buffer MAX. If you're provider is such a low tier provider that it can't handle that, then you seriously need to get a new one. Buffering during IPTV is generally a provider being oversold issue and has nothing to do with Emby. A bigger buffer won't address your iptv problem, in fact it will just make it worse.

[Scobra 10]

I have the same problem. Emby simply uploads roughly the same speed as video bitrate meaning as soon as upload speed drops for whatever reason, it starts buffering. I guess the best sort of solution I had in mind was something like YouTube's "Buffer Health". Rather than just having a second or two buffer, something like 20 would be nice. 

I should also mention, since the upload speed is limited to the video bitrate, it is also impossible to play a video at more than 1x speed without buffering. 

Edited March 5, 2025 by Scobra

[Q-Droid 989]

6 hours ago, Scobra said:

I have the same problem. Emby simply uploads roughly the same speed as video bitrate meaning as soon as upload speed drops for whatever reason, it starts buffering. I guess the best sort of solution I had in mind was something like YouTube's "Buffer Health". Rather than just having a second or two buffer, something like 20 would be nice. 

I should also mention, since the upload speed is limited to the video bitrate, it is also impossible to play a video at more than 1x speed without buffering. 

Emby does not restrict or manage the "upload" speed. It uses the full bandwidth available to stream the video and the limits are only for the bitrate of the stream itself, not the transfer rate. If you're seeing a transfer rate that is the same as the bitrate that is a limitation of the network itself at the server, the client or somewhere in between. It also means the stream bitrate should be reduced because a hiccup in the transfer will cause playback problems.

 

[Scobra 10]

On 3/5/2025 at 4:11 AM, Q-Droid said:

Emby does not restrict or manage the "upload" speed. It uses the full bandwidth available to stream the video and the limits are only for the bitrate of the stream itself, not the transfer rate. If you're seeing a transfer rate that is the same as the bitrate that is a limitation of the network itself at the server, the client or somewhere in between. It also means the stream bitrate should be reduced because a hiccup in the transfer will cause playback problems.

 

Seems like it was a one off matter. Works fine now. 

[aquiveal 3]

This post has strayed significantly from the original topic. The initial question concerned client-side buffering in Emby to mitigate network jitter and hiccups.  I experience buffering issues due to my poor ISP connection, while my friends, with better ISPs, stream smoothly.  Even though I host my Emby server on a Google Cloud Platform virtual machine with a 10 Gbps connection and have a 100 Mbps home internet connection, I still encounter buffering problems with my 1080p direct-play streams (no transcoding).  Regarding those suggesting transcoding, why couldn't Emby transcode an extra 10 seconds and send it to the client as a buffer? I own the media, so there's no piracy concern with retaining a larger transcoded buffer.

Jellyfin, a fork of Emby, supports large buffers, resulting in smooth playback even on my unreliable internet connection. However, Jellyfin didn't undergo a complete backend rewrite or utilize fundamentally different streaming technology, so I believe Emby should be capable of similar functionality.

[scott46953 30]

I agree, something needs to be done about the buffering issues.. it seems to be getting worse or more irritating.  I can not get good antenna signals down in the valley where I live, so I send it with emby from my mom's house on the other side of town.  I factory reset the Nvidia stream box, thinking something got stuck .. blew the dust out of the fans... Speed tests checks fine.  Ping test checks fine.  But randomly runs out of buffer.  Then I found a secondary emby at the Play store. I was on version and the newer version 3 app that I just installed seems to buffer a lot less.  At least I can watch TV now.. however, it does still buffer once in awhile.. so I check a speed test, ping test, remotely login to the server do the same thing, even check CPU usage and hard drive usages, there's nothing that should be causing the issue.. so maybe it's a timing issue, it's not sending data to the client. Maybe it's receiving an error and it's not correcting itself fast enough, I'm not sure. But I can definitely confirm that there's an issue. 

As far as star link and some of the other  internet connections that I have heard of, including mobile cell phone data / mobile data, on those I would definitely use pia / private internet access or if somebody can find one that does work VPN that supports port forwarding.. however I can't confirm that pia does work

[Green_with_Emby 2]

On 12/03/2025 at 04:55, aquiveal said:

This post has strayed significantly from the original topic. The initial question concerned client-side buffering in Emby to mitigate network jitter and hiccups.  I experience buffering issues due to my poor ISP connection, while my friends, with better ISPs, stream smoothly.  Even though I host my Emby server on a Google Cloud Platform virtual machine with a 10 Gbps connection and have a 100 Mbps home internet connection, I still encounter buffering problems with my 1080p direct-play streams (no transcoding).  Regarding those suggesting transcoding, why couldn't Emby transcode an extra 10 seconds and send it to the client as a buffer? I own the media, so there's no piracy concern with retaining a larger transcoded buffer.

Jellyfin, a fork of Emby, supports large buffers, resulting in smooth playback even on my unreliable internet connection. However, Jellyfin didn't undergo a complete backend rewrite or utilize fundamentally different streaming technology, so I believe Emby should be capable of similar functionality.

A client side, configurable buffer would be a very useful tool for how I have Emby set up. Some consideration for this would be appreciated, and thank you for listening. 
 

all the best,

[kikinjo 281]

On 3/5/2025 at 1:11 PM, Q-Droid said:

Emby does not restrict or manage the "upload" speed. It uses the full bandwidth available to stream the video 

It does not uses full bandwidth at all, this is not true. To confirm switch your client to AUTO and than you will see you are wrong.

Ops question is legit, emby clients have different buffer issues / settings, depends on platform.

Edited December 10, 2025 by kikinjo

[scott46953 30]

Actually it does use full bandwidth, but it uses it in increments.  Client request more data or video during a stream the server then sends the next batch of data video stream till the max was sent.  I am not sure if the max is time of video or length of data or size of the increment.  However it does not measure the speed of what is sent. It uses the max till this increment is done for each client watching a stream. The more streams the more increments you will see on a measuring graph till a point of your max internet bandwidth will cap then it will continuously cap until all video is sent for the increments.  If you need to set a max bandwidth for the server you can do it in the operating system of the server.  Emby has enough tasks to do, the emby team does not need to speed any time on bandwidth or data caps.

However if you want to increase your clients buffer size then in the server settings there is an advanced settings window.  There is an adjustable buffer the server sends to the client.  I do not believe the amount the client receives is stopped at the client end unless an error has happened and the server has sent too much to the client.  Not sure what that max is or if it even happens. Probably the max would be software set or till memory of client is full.  The type of stream emby uses is different then other apps like YouTube.. of you need more buffer then try the advanced setting on the server.  However how about fixing the actual problem instead of asking for more client buffer? More buffer issues are transcoding and not enough GPU ( graphics card speed) recommend Nvidia 1500 GPU and higher. My opinion. Other buffer issues from not enough internet speed.  Because of Wi-Fi 2G, the Wi-Fi 5G is preferred for wireless. crowded radio signals, or junk router, or just need to upgrade internet speeds. 10mb Ethernet not good. 100mb Ethernet min, 1000mb+, recommended.  Also it is good to make separate names on your Wi-Fi router for 2G and 5G.  Make sure phones and mobile items uses the 2G only and the TV and streaming devices all use the 5G.  This will fix a lot of headaches.

[Guest]

34 minutes ago, kikinjo said:

It does not uses full bandwidth at all, this is not true. To confirm switch your client to AUTO and than you will see you are wrong.

Ops question is legit, emby clients have different buffer issues / settings, depends on platform.

To be fair auto doesn't really work on any streaming service ever. 

Netflix will happily send you a 720p video without anyone realizing it. 
Plex will transcode every single file you throw at it if you set to auto.  
YouTube will never send me a 4K video unless I specially request it. 

No one should be using emby on auto.  

 

There is def a difference in clients ability to play correctly or not.  The androidTV app plays things perfectly and instantly.  The standard android app stutters like crazy.  On the same network, on the same device.   I realize this isn't the android forum but just pointing out I agree there is some difference client to client.  I don't know if it's buffer related though.  

[Q-Droid 989]

1 hour ago, kikinjo said:

It does not uses full bandwidth at all, this is not true. To confirm switch your client to AUTO and than you will see you are wrong.

Ops question is legit, emby clients have different buffer issues / settings, depends on platform.

 

Don't confuse two different and unrelated things. Emby controls and changes the BITRATE, not the transfer rate.

Yes - The bandwidth AUTO detection feature in Emby has always been broken. It's SUPPOSED to detect the available bandwidth between the server and client to set the BITRATE limit for a better streaming experience. But it doesn't work and falls back to a hardcoded value that more often than not is too low and causes unneeded transcoding and server overhead.

Bandwidth and transfer rate - This is infrastructure and the Emby client and server are just nodes on the network. The Emby server does not manage or control or even care about this when it sends data to a client. Regardless of the media streaming bitrate value the Emby server sends segments/packets to the client as fast as the network allows. A 10mbps and a 40mbps stream get sent to a client at network speed, not at the bitrate, and as many segments/packets as the client wants are sent as fast as they can go. On a fast network the client playback buffer stays topped off. But on a slow or unstable network with changing bandwidth and if stream bitrate is close or above what's available you can end up with an empty buffer (underruns). Pauses and hiccups. The better solution for these cases is to lower the BITRATE or increase the bandwidth.

As I understand it some client platforms don't allow control of the playback buffer, but I don't know which do or don't.
 

 

Edited December 10, 2025 by Q-Droid

[kikinjo 281]

I Agree with your comment in general, but AUTO settings on clients is not - not related, it cant be. Especially when all clients defaults and come installed on AUTO settings.

Image only how many less forum post would be if AUTO settings is working as it should be .-)

 

[scott46953 30]

I generally set my clients to 30mb picture quality.. however I'd have not had any issues with Auto.. but if anybody complains about picture quality I have them change their settings to 30mb. I don't believe I have any streams that are more than that right now. You're doing this allows my server to send the max to the client. So basically whatever IPTV signal I receive I spit back out or whatever video or movie The client selects my server spits back out the exact same file.  I'm running on a 1000mb fiber line. Now when I had spectrum I had nothing but problems. The normal service provided 10mb that sucks to deal with. Lots of transcoding, crappy picture quality. And buffering.. dump spectrum and moved my whole server to another city. Much better internet company 1000 up and down. The issues that you're describing does not exist on my system anymore. I'm also using 5G Wi-Fi on a dedicated separate router using a manually adjusted channel I think mine's set for channel 100. So there's no interference from any neighboring Wi-Fi signals. Most Wi-Fi signals are between 36 and 56 or 148 and 165. Using a router that you can program with custom firmware always has helped me get to channels that benefit me greatly. Yes my server runs on 5G Wi-Fi with no problems. Yes my other locations also run on 5G Wi-Fi using similar channels between 100 and 140  I can stream 20 + streams without any issues and I've never ran into any issues since. My server is very busy, it even removes the commercials after the recordings are done, that uses most of the CPU cores and I save my dedicated Nvidia 3060 for transcoding on emby server. The Nvidia has never failed me and it can transcode so many streams I've never ran into any issues with buffering from that either. I would say if you got buffer problems you need to find out why it's buffering and fix that problem instead of trying to mask it unless you're trying for a temporary fix because masking the problem does not solve or fix it.

Edited December 10, 2025 by scott46953

[PixelWizard 7]

same problem here with recent updates, 4.8 no have any issue... with betas and stable 4.9.80 and 90 always buffering in many of my clients. (+30 diferent clients)

[strichmo 21]

1 hour ago, scott46953 said:

However if you want to increase your clients buffer size then in the server settings there is an advanced settings window.  There is an adjustable buffer the server sends to the client. 

Where exactly and what is the name of the property?

[Suliamu 36]

For those people with unsteady primary internet-connections OpenMPTCProuter (GPL 3.0, https://www.openmptcprouter.com) might be a solution.  
If i had to live on a boat for example i would use this to aggregate one Starlink-WAN with one or more 5G cellular-links. 
You have on the other side a vserver who "receives" the communication data from all your WAN in parallel with inbuilt failsafe when packages are not transported.  
I've seen people who use this also to aggregate multiple Starlink-Links into one steady, beefy connection. 
I know that this is not an "emby-solution", but when you have problems with your internet-connection it would be best to try to fix this first before messing with the clients. 

[scott46953 30]

6 hours ago, strichmo said:

Where exactly and what is the name of the property?

It's under diagnostic options in the Emby server. You might be able to get to it other ways but on the left side you click diagnostic options and then you look for throttle buffer length override

[strichmo 21]

2 hours ago, scott46953 said:

It's under diagnostic options in the Emby server. You might be able to get to it other ways but on the left side you click diagnostic options and then you look for throttle buffer length override

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?