Buffering/Starlink

[EmbyOak 23]

I've noticed since using Emby sometimes I have buffering and sometimes things work perfectly.  I finally did some tests this evening.  I did a UDP speed test, limiting to 15mb/s and I was getting every 5 or so seconds anywhere between 5 to 60 packets lost.  This link is an L2TP/IPSec tunnel (Mikrotik to Mikrotik). The main side is on a gigabit fibre connection and as mentioned the end is using Starlink (hardwired, not wifi)

When I remove the VPN, things seem to work better.  A friend has a similar issue, but has 0 packet loss using a UDP speed test over the VPN.  I think his issue is his wireless (we are still troubleshooting).  

In either case, the links should be good enough to sustain a stream.  I still think the buffer needs to be increased to compensate for any hiccups. Considering my friend has a 50mb/s and the stream is only 5mbps and my speed test of 15mbps ran over top of the stream without any hiccups and I'm getting over 100mb/s with my Starlink, the system should be able to download faster (I have my friend limited to 8mbps and for the attached log I was set to auto).  So auto is not even figuring out the available bandwidth and definitely not buffering enough.

Any way to increase the buffer size manually?

 

 

 

ffmpeg-directstream-8b2a606c-efbe-4403-b811-66e3103041cb_1.txt

[Luke 42077]

Hi there, I would suggest lowering the in-app quality setting and seeing if that helps.

[EmbyOak 23]

Some times it does, some times it doesn't.  In either case. "auto" or 8mb/s when you have 50-100mb/s of capability shouldn't matter.  

[Luke 42077]

39 minutes ago, EmbyOak said:

8mb/s when you have 50-100mb/s of capability shouldn't matter.  

Unless there is ISP throttling occurring on either side of the connection.

[EmbyOak 23]

There is no ISP throttling.  I am pushing traffic over a VPN on top of the stream. I can watch a 5mbps video stream and then push 15mb/s of traffic on top of it without any issues. 

I'm not disputing there are a few UDP packets dropped every 5s or so (UDP being highly susceptible to any network issue), but a bit of buffering would over come this, especially when using TCP for transport.  Even if there was a bit of random throttling (I have yet to see any), buffering would over come this because it would burst to the bandwidth that is available at the time.  For perfect networks (fibre), buffering isn't really an issue.  But as I am trying to show you, less than perfect networks (but are still very good for voice and video calls that I do all day without any issues) requires a bit more buffering.

[Luke 42077]

3 hours ago, EmbyOak said:

There is no ISP throttling.

How can you be sure?

[EmbyOak 23]

This is 5 minutes of doing a mikrotik to mikrotik one way UDP bandwidth test over Starlink using an L2TP/IPSec tunnel.  The worst is 27.7mb/s.  Peak was 254.9mb/s.  Even at the worst there is more than enough bandwidth to buffer content.  At an average of 156.9mb/s (let's round down to 100mb/s), there is more than enough bandwidth to push an 8mb/s stream to buffer.

In my prime (decades ago), I was a CCIE candidate (decided to let the younger kids do the work instead of finishing off the CCIE).  I failed a moch lab exam by 2% and aced all the theory exams but I wanted to focus on people and business problems as oppose to programming routers all day.  I currently over see teams that build large rural wireless networks as well as fibre communities.  So, yes, I am sure.

I'm fine with any questions or troubleshooting ideas you may have.  But for now, I've exhausted my ideas and it currently points to not enough buffering, or buffering not taking advantage of bandwidth that currently exists.

[Luke 42077]

@EmbyOak was that bandwidth test using the same port that Emby Server runs on? That's important otherwise the result might not be the same. Thanks.

[EmbyOak 23]

As mentioned, the bandwidth test runs over the VPN and Emby runs over the VPN. To an ISP it is indistinguishable.  

[Luke 42077]

But without it being on the same port it's not really an equivalent test, right?

[EmbyOak 23]

The port number is irrelevant as it is going over an L2TP tunnel and so, if you are still dwelling on the point that the ISP is throttling, the answer is yes, it is equivalent as the ISP can only see traffic on port 1721 (UDP specifically).  It doesn't matter if I do a Mikrotik to Mikrotik test over the VPN on any port, do a speed test to fast.com or speedtest.net over the VPN, use Plex or Emby, the ISP only sees traffic going over port 1721 as all other traffic is encapsulated inside the VPN packets.  The ISP is blind to the traffic inside the VPN tunnel.

If there is a speedtest/bandswidth tester that is built in to Emby that you would like me to try out, tell me how to access it and then I will test that way.  Because, to the point you are trying to make, to make it a real test, I need to test from the Emby client to the Emby server, that is a true test.  But, still irrelevant.  An option to increase the buffer capacity or modifying the buffer to be larger would be greatly beneficial for those that do not have a printing fibre optic network connecting the client to the server over the Internet.  

I have DSL (bonded to get 100/10) at home and have similar issues (just not quite as frequent).  I have to force my client to be on 8mb/s for it to work 99% of the time without buffering.  And as I have proven to you previously with logs that I have posted, "auto" doesn't work well, it seems to pick the lowest speed as oppose to using the available bandwidth.

[EmbyOak 23]

And please do not get me wrong, I really like Emby.  I'm not ready to migrate my family over from Plex yet, but I'm using it mostly exclusively now.

[Luke 42077]

Hi, are you still having an issue with this?

[EmbyOak 23]

I have not been watching much TV, but the little I have watched, I have not had a pause.  I'll keep you posted. 

[Luke 42077]

Thanks for the feedback.

[EmbyOak 23]

OK, back to watching some TV.  I can report that I have watched some content on Starlink without issues as well as Bell's rural internet without issues.  So, the buffering is much better.

I think part of the Starlink issue is that I was using L2TP and starlink would "drop" its connection for a half a second which causes L2TP to "hang". I've switched to using a certificate based VPN (IKEv2) for "instant" authentication to resolve the "drops" on the Starlink.  There is no VPN with the Bell connection, so I am confident in saying buffering has been resolved.

Sorry for the late response.  I do not watch a lot of TV during the summer.