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

[strichmo 12]

Been using Emby across 5 households for over a year now and one of the biggest issues now days is pausing/buffering for some households. I'm still trying to collect definitive data to isolate the problem such as confirming for sure that the Emby server network isn't limited on its end (unlikely).

However some households never have the problem, and at least one of the households that does have the problem has some home network issues I'm aware of. One of the key problems I think some households suffer is inconsistent bandwidth due to their home wifi and/or other users on the network. Whilst this is not Emby's problem, I do think the Emby client is not buffering long enough to allow the client to deal with intermittent network problems.

Emby Apps used in various households:

• AndroidTv 2.0.83g
• Android App
• IOS App

Server: Windows 4.7.11.0

What are the current buffer values on clients and can they be increased?

embyserver-63813484800.txt embyserver-63813571200.txt embyserver-63813312000.txt embyserver-63813398400.txt

Edited March 5, 2023 by strichmo

[Luke 37066]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[strichmo 12]

16 minutes ago, Luke said:

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

Added more info and logs in OP.

[rbjtech 4265]

I don't believe increasing buffers is going to help your issue - it will simply delay the first 'stall'.

You need to either lower the emby bandwidth limits for those users (maybe forcing transcodes on your end) - or increase the bandwidth on their home network.

At this time, emby does not do variable bandwidth streaming, so whatever it starts with, it assumes is available throughout the playback  - so you need to work with lower value unfortunately.

[strichmo 12]

58 minutes ago, rbjtech said:

I don't believe increasing buffers is going to help your issue - it will simply delay the first 'stall'.

That's not how most home networks work. Most home networks will have bandwidth throughput that goes up and down as the home wifi signal changes or users come and go. Increasing the buffer will allow for more time to recover from a temporarily decreased throughput. Right now it feels like Emby buffers very little. Why?

[rbjtech 4265]

3 minutes ago, strichmo said:

That's not how most home networks work. Most home networks will have bandwidth throughput that goes up and down as the home wifi signal changes or users come and go. Increasing the buffer will allow for more time to recover from a temporarily decreased throughput. Right now it feels like Emby buffers very little. Why?

If your wifi signal changes when users come and go - then you have issues with your wifi network ... 

Your logs are also FULL of errors (every other line in some cases) - so I can't really see what's going on.

Do you can an example log of just one user with the issue as response times from these remote users all look to be very good... ?

[strichmo 12]

14 hours ago, rbjtech said:

If your wifi signal changes when users come and go - then you have issues with your wifi network ... 

Most users have issues with their home network or internet connection. That's just the reality of things. Emby currently does a very bad job of dealing with this. I'm pushing to get some developers to take a look, as it's something that could possibly be made better pretty quickly (or maybe not).

 

14 hours ago, rbjtech said:

Do you can an example log of just one user with the issue as response times from these remote users all look to be very good... ?

No I don't unfortunately. Also I really hope you're not looking at latency - That has nothing to do with this issue.

[rbjtech 4265]

4 hours ago, strichmo said:

Most users have issues with their home network or internet connection. That's just the reality of things. Emby currently does a very bad job of dealing with this. I'm pushing to get some developers to take a look, as it's something that could possibly be made better pretty quickly (or maybe not).

If you think adaptive streaming is a quick fix - then best of luck.  I'll leave it with you.

[strichmo 12]

3 hours ago, rbjtech said:

If you think adaptive streaming is a quick fix - then best of luck.  I'll leave it with you.

You seem like someone who cares a lot about Emby, so I need to be honest with you - You're really not being a helpful force in this thread. I never said adaptive streaming was a quick fix nor did I even suggest it as a target. You did. This whole thread is about increasing the download buffers to better mitigate temporary bandwidth problems. I have high confidence this will improve the situation for a very low undertaking.

[ebr 14913]

3 hours ago, strichmo said:

increasing the download buffers

Hi.  That's just not the way streaming works anymore.  Way back in the day, you could pause your item and wait for a bunch of it to buffer and then continue on and I think that's what you are expecting now.  But that isn't how the new streaming protocols work anymore because that was an incredibly inefficient use of bandwidth for the net in total.  Today, streaming media is delivered in more of a "just in time" type fashion and also in a way that, if you skip ahead, say, 30 minutes, that whole 30 minutes doesn't have to be "buffered".

So, the only solutions for what you are experiencing now are to either have adaptive streaming (actually a very difficult task without pre-encoded media) or lower the requested bitrate to a value that will work across whatever variables are in play or discover and correct whatever the bitrate limitations (variations) are.

Does that make sense?

[strichmo 12]

Thanks for the reply @ebr! I fully understand what you're getting at, but I don't think you're entirely correct - "just in time" is perfect for Netflix that have, as you say, developed good adaptive streaming with perfectly encoded files cached across CDNs around the world. That's not something Emby, Plex, or any other home streaming setup has and it seems unlikely to ever develop such a feature. So surely we need at least a small download buffer?

I'm not suggesting >30 mins of buffered video - I'm sure some of your TV clients don't even have access to enough memory to do that - but right now it feels too low. I'd genuinely be curious to know what it is set at right now?

Edited March 6, 2023 by strichmo

[rbjtech 4265]

59 minutes ago, strichmo said:

Thanks for the reply @ebr! I fully understand what you're getting at, but I don't think you're entirely correct - "just in time" is perfect for Netflix that have, as you say, developed good adaptive streaming with perfectly encoded files cached across CDNs around the world. That's not something Emby, Plex, or any other home streaming setup has and it seems unlikely to ever develop such a feature. So surely we need at least a small download buffer?

I'm not suggesting >30 mins of buffered video - I'm sure some of your TV clients don't even have access to enough memory to do that - but right now it feels too low. I'd genuinely be curious to know what it is set at right now?

So now you are questioning the authors of the application ? wow .. unfollowed - you just can't help some people.

Edited March 6, 2023 by rbjtech

[frankw 8]

I actually agree with @strichmoand think there is room for improvement here in terms of buffering. Not sure why certain people are throwing their toys out of the pram when we are simply discussing suggestions for improvements, but hey. 
 

My emby server is connected to a 1Gbps fibre connection and one family member accessing via Starlink using Android TV client (NVIDIA Shield) has continuous buffering issues. Media on all other services play without issue (Netflix, Prime, Apollo TV, YouTube). Other users on the server don’t have issues.

Speed testing the Starlink connection gives results consistently in the 100Mbps+ upstream, and real-time video calls are made relatively uninterrupted on Zoom/Facetime. The problems are consistently with Emby being able to maintain a reliable stream at 15Mbps (max bitrate on the client) on a connection with speeds in excess of that figure, which would suggest a buffer which is simply too small for some connections or there are some other streaming parameters which need to be tweaked.

Perhaps there could be two “modes” - one with HLS parameters as they are now, and one with a set of parameters tweaked for slower startup/seeking and with higher buffer?

https://www.speedtest.net/result/i/6017479900

https://www.speedtest.net/result/i/6017496455

Edited March 9 by frankw

[visproduction 122]

Frank, perhaps it is good to consider that the online services you mention have all preencoded content.  There is no transcoding required by any of these online services.  The stored content might have multi versions of resolution, but the files are all available to stream immediately, nothing is being transcoded.  OK, so with Emby, most all the time content is being transcoded to meet the needs of the end users hardware and connection.  If you want to compare apples with apples, then create a collection with all content at 1080P, video H.264, mp4, audio two channel AAC, an optimium bitrate of around 2400 kbps, no alternate audio and no subtitles and see if multiple people accessing this library at the same time has any issue.  If you are asking the Emby server to transcode multiple master content at high bitrates, mkv, AC3 audio, and bring the bitrate down to match the needs of various users, then you are taxing the server with transcoding at the same time you are running your speed buffer test.  I think you are comparing apples to oranges, so to speak.  It's not a correct speed comparison test.

Edited March 9 by visproduction

[frankw 8]

@visproductionI hear what you’re saying. Unfortunately the problem I am describing is not a problem of overloading a server by transcoding multiple streams, it happens with a single user on a 16-core server. There is no “taxing the server with transcoding” - I have eliminated that as a constraint.

[Gilgamesh_48 943]

FWIW: I have never seen any buffering on my Rokus, my Fire TVs or my Shield TVs except when I as having network or server problems. 

I understand that some high bitrate files can cause buffering and buffering can also be caused by network issues but i do not think increasing the buffer size will make much difference. 

The last buffering issue I saw was over a year ago and that was caused by my router malfunctioning and reducing network through put to less than 1 meg.

I would check all the other possibilities before even considering changing the programing on the clients.

[frankw 8]

@Gilgamesh_48I agree with you, but I don’t think it is purely a network problem, as the network does work for other streaming services, and for things like FaceTime. I have tested the network speed and packet loss, and it is minimal but there is some intermittent loss.

I’ll be the first to admit Starlink is not the most reliable, but I do think it’s a combination of emby and Starlink together, which is why I suggested there being room to maybe improve emby streaming settings for certain situations where bigger buffers would be useful.

Ultimately, other services seem better equipped to deal with minimal network instability, which is why I agree with the OP.

 

Edited March 9 by frankw

[bakes82 90]

You should learn about routing. Because is probably 99% the issue.  Not everyone goes across the same path and exchanges and thus degradation.  If you don’t want them the buffer have them download the files before hand.

[strichmo 12]

Thanks for providing another perspective @frankw. Unfortunately the Emby devs for whatever reason don't value or recognize this as an issue enough to expose the buffer time property to us. There should be no debate over the validity of the problem - Large amounts of latency alongside some occasional bandwidth spikes ruin the buffer time they've set. It's obvious and clear.

[RanmaCanada 345]

More people who don't seem to understand how things work, and then questioning the devs when they are told they are wrong.  I wonder how much longer it will be before Luke and the team start refusing to answer queeries from users as they get more and more ignorant in their demands for things they just don't want to understand.  

[Abobader 2945]

21 minutes ago, RanmaCanada said:

More people who don't seem to understand how things work, and then questioning the devs when they are told they are wrong.  I wonder how much longer it will be before Luke and the team start refusing to answer queeries from users as they get more and more ignorant in their demands for things they just don't want to understand.  

True, that the reason that I actually stop posting in the forum for some years now (regarding support).

[Gilgamesh_48 943]

1 hour ago, strichmo said:

Thanks for providing another perspective @frankw. Unfortunately the Emby devs for whatever reason don't value or recognize this as an issue enough to expose the buffer time property to us. There should be no debate over the validity of the problem - Large amounts of latency alongside some occasional bandwidth spikes ruin the buffer time they've set. It's obvious and clear.

In several clients, like all the Rokus,  the playback and the buffer are controlled by the client itself. That is Emby provides properly formatted streams and some basic info and then the client plays it. Emby, in many cases, has no control over playback after setting things up except to provide.

I also think that the "problem" is real but directly related to the client device or to the route the data takes to get to your client from your server.

Utilities like any of the speed test apps do not always use the same route to make their tests that the server/client uses. 

I once, many years ago, had a bad buffering problem on one of my clients and all the others worked fine. What I finally found was that a different device was throwing noise, due apparently to a defective cable, and the noise was clogging my network so bad that some clients connected to my router could not recover from all the lost packets. It turned out that the wireless side of my network was not effected so instead of replacing the cable I made that misbehaving client's connect wireless and, thankfully it was really the cable and everything performed great after the switch.

Normally I recommend connecting most everything wired but, in this case, going wireless was the moved that fixed the problems. 
BTW: The noise might not have actually been the cables fault. It could have been the Ethernet port generating the noise. I have never had a reason to go back to wired for that client so the actual source of the noise has not been determined. Heck, it could have been just some dirt in the connection.

It does not really matter now as everything is working and I am a firm believer in: "If it ain't broke don't fix it" and, right now my network and the clients and other devices connected to it "ain't broke."

[strichmo 12]

54 minutes ago, Gilgamesh_48 said:

In several clients, like all the Rokus,  the playback and the buffer are controlled by the client itself. That is Emby provides properly formatted streams and some basic info and then the client plays it. Emby, in many cases, has no control over playback after setting things up except to provide.

I assume you mean the Emby server here. The Emby client should have full control over the amount of the stream it requests and buffers locally.

I can think of no reason why this cannot be configurable and no Emby developer has actually explained why it is not possible OR why they don't want to do it.

[RanmaCanada 345]

2 hours ago, strichmo said:

I assume you mean the Emby server here. The Emby client should have full control over the amount of the stream it requests and buffers locally.

I can think of no reason why this cannot be configurable and no Emby developer has actually explained why it is not possible OR why they don't want to do it.

You've already been told the reasons, but you don't want to accept it because it doesn't make sense to you.  It's like explaining the fact the Earth is round to flat Earthers, who then do their own experiments to prove the Earth is flat, only to have those experiments prove the Earth is round, and then question the results of their experiments because they didn't get the results they wanted.  You have it set in your mind that there is some conspiracy afoot, and you won't accept anything but the answers you want.

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 knowlegeable that we're wrong because they said so.

[RanmaCanada 345]

8 hours ago, frankw said:

@Gilgamesh_48I agree with you, but I don’t think it is purely a network problem, as the network does work for other streaming services, and for things like FaceTime. I have tested the network speed and packet loss, and it is minimal but there is some intermittent loss.

I’ll be the first to admit Starlink is not the most reliable, but I do think it’s a combination of emby and Starlink together, which is why I suggested there being room to maybe improve emby streaming settings for certain situations where bigger buffers would be useful.

Ultimately, other services seem better equipped to deal with minimal network instability, which is why I agree with the OP.

 

There are whole posts dedicated to Starlink.  They use CGNAT and Emby is absolutely not setup to handle the way Starlink mangles (yes mangles, not manages) your data as that would be far too much overhead and cost way too much.  Starlink is a YOU problem, period.  You need to setup everything on your end for it to function properly, or move to Plex who has everything go through their servers before it gets to your friend's system.  The one thing users like about Emby is the devs don't spy on you..so unless you want them to start routing traffic through their servers to inspect everything and monetize as much data as they can about you and your users, setup everything on your end for Starlink to work properly.