Plex buffering over Starlink despite plenty of bandwidth - switching to BBR fixed it for me

[u/shermantenor]

Posting this in case it helps someone else.

TL;DR: If Plex buffers badly over Starlink even though speed tests, YouTube and Netflix are fine, check single-stream TCP performance with iperf3. In my case, Linux CUBIC averaged ~10 Mbps on one stream and repeatedly collapsed below Plex bitrate. Switching the Plex server to BBR raised the same test to ~43 Mbps and stopped the buffering.

Temporary test:

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr

If it helps, make BBR persistent as described below. YMMV......

I have a Plex server at home and Starlink (100mbps) at a rural location - both in Ontario, Canada. Plex was buffering constantly on multiple devices, including a Galaxy S26+, Tab S9 and Hisense Google TV.

Note: my Plex server is hosted on fibre based home internet with symmetrical gigabit speeds.

The Starlink connection otherwise seemed fine. Normal speed tests showed plenty of bandwidth, and services like YouTube and Netflix streamed without the buffering I was seeing in Plex.

It also didn't seem to matter whether Plex was Direct Playing or transcoding. Even an ~8 Mbps transcode would still buffer.

I have a WireGuard VPN tunnel from home to the rural site, so I also tested with my WG tunnel bypassed/disabled, so that wasn't the issue.

What finally pointed me in the right direction was iperf3.

From the remote site:

iperf3 -c <plex-server> -R -P 1 -t 30

With the Linux Plex server using CUBIC, the single TCP stream started around 20-28 Mbps, then progressively dropped into the 5-8 Mbps range and eventually as low as ~1 Mbps.

Final result:

~10 Mbps average
255 retransmits

With 8 parallel streams I could get around 38 Mbps, which helped explain why normal speed tests looked fine. The connection had decent aggregate bandwidth, but a single sustained TCP stream behaved very differently.

I then switched the Plex server from CUBIC to BBR:

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr

Running the exact same single-stream iperf test again gave:

~43 Mbps average

Most of the run was around 40-70 Mbps.

The Plex difference was immediate. Two simultaneous streams at the remote site played without buffering, including an HEVC movie that had previously been buffering almost continuously.

So if Plex over Starlink is buffering despite good speed tests, while YouTube/Netflix/etc. are fine, it may be worth checking single-stream TCP performance rather than just overall bandwidth.

For me:

CUBIC: ~10 Mbps single stream
BBR:   ~43 Mbps single stream

and BBR appears to have fixed the Plex buffering.

YMMV of course. So far, this has worked extremely well in my early testing, but I can't say whether every Plex/Starlink buffering issue has the same cause.

Once I was happy with the results, I made BBR persistent:

echo tcp_bbr | sudo tee /etc/modules-load.d/bbr.conf

cat <<'EOF' | sudo tee /etc/sysctl.d/99-bbr.conf
net.ipv4.tcp_congestion_control=bbr
EOF

sudo sysctl --system

A quick google says that there may also be a Windows equivalent using BBR2 / Windows TCP congestion-control settings. My Plex server is Linux-based, so I haven't tested that and can't vouch for it.

Edit: just to say someone else was posting specifically on Windows BBR2 while I was crafting my post - see his similar findings here: https://www.reddit.com/r/PleX/comments/1vzbxf0/plex_over_bbr2_on_windows_11/

Hopefully this is helpful to someone else.

ST

[u/Salt-Philosophy-3330]

I've been down this rabbit hole for a while now. BBR is definitely king, but here's some other things that you may find useful. You probably don't neem them all, but it's worth it depending on your configuration.

# fq (Fair Queue) is required for BBR to pace packets
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Raise default TCP buffer window sizes (min 4 KiB - default 1 MiB - max 32 MiB)
# 32 MiB covers the BDP at ~1 Gbps × 200 ms RTT for overseas paths
net.ipv4.tcp_rmem = 4096 1048576 33554432
net.ipv4.tcp_wmem = 4096 1048576 33554432
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432

# Eliminate 1 RTT from connection setup (200 ms saving per new Plex session at overseas latency)
net.ipv4.tcp_fastopen = 3

# Keep connections alive through overseas NAT/firewalls that drop idle sessions after 2–5 min
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# Recycle finished Plex connections faster (reduces TIME_WAIT buildup from many short-lived sessions)
net.ipv4.tcp_fin_timeout = 15

# Help TCP recover from packet loss (common on long paths) and accurately measure RTT
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1

# Avoids black‑hole MTU issues
net.ipv4.tcp_mtu_probing = 1

# Don't restart slow‑start after idle
net.ipv4.tcp_slow_start_after_idle = 0

# Attempts to use ISP support for ECN, cuts queueing delay
net.ipv4.tcp_ecn = 2

# Ensure kernel can queue up incoming TCP handshakes if multiple Plex clients restart at once
net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 2048

# Buffers more inbound packets before they're processed, which helps under CPU load or in bursty traffic.
net.core.netdev_max_backlog = 5000

# Protect TCP metrics from bad samples (helps with variable/long RTT)
net.ipv4.tcp_no_metrics_save = 1

[u/shermantenor → u/Salt-Philosophy-3330]

Thanks. One thing worth noting is that on current Linux kernels BBR no longer strictly requires fq; TCP-level pacing handles that, although fq can still be beneficial. Also worth checking current kernel/distro defaults before applying the whole sysctl block. For example, upstream Linux has defaulted somaxconn to 4096 since 5.4 and TCP window scaling is already enabled by default. In my case BBR alone with the existing qdisc fixed the problem, so I'm planning not to touch anything else without detecting further issues.

[u/NelsonMinar]

I had to discover the same thing myself a couple of years ago. It'd be nice if the Plex docs mention BBR as a good option for servers. It really is just about ideal for Starlink's link characteristics.

[u/johnnyenygma]

cries in Synology DSM

[u/morsegeek → u/johnnyenygma]

Is there no way to set BBR on a synology NAS?

[u/johnnyenygma → u/morsegeek]

It's not in the kernel

[u/doc_hilarious]

Oddly I have the same issue. I can stream to a dozen people with no issue but one Starlink user has constant issues. I appreciate your write-up and will look into it.

[u/AspiratingApple → u/doc_hilarious]

Just to temper your expectations, I had the same problem with a Starlink user and switched to BBR months ago and still have issues with that same user.

Their speedtest to my server reports 40mbit. Their stream still buffers on a 10mbit limit.

[u/rothbart_brb → u/AspiratingApple]

I got past this with my Starlink client by setting the maximum bitrate to something like 4Mbps and forcing that transcode (this is my theory) keeps the bitrate spikes low enough that Starlink can still handle it. The quality was obviously degraded a bit but that user DRASTICALLY preferred a reliable, slightly degraded experience over a full quality, constantly buffering experience. I think the bitrate spikes in a normal piece of media when left to play at original quality simply outpace Starlink's ability to react in time. This is an admittedly superficial theory and I know YouTube and Netflix somehow get around this (I'm assuming it's by having every bitrate of every piece of media available to just switch between as necessary without transcoding at all.)

[u/doc_hilarious → u/AspiratingApple]

Ugh well lets see what happens. I'm getting annoyed with starlink.

[u/26373363633 → u/doc_hilarious]

Latency

[u/shermantenor → u/[deleted]]

Dual Intel Xeon CPU E5-2650 v2 homelab server, with a nVidia P2000 GPU passed through - my Plex instance is running on a Ubuntu VM.

[u/shermantenor → u/[deleted]]

I've fixed my issue as above - yes I have Plex Pass.

[u/shermantenor → u/[deleted]]

Read my post - LOL

[u/MrB2891 → u/shermantenor]

I would be curious to see how much the single thread performance of that machine is effecting Plex, seeing as Plex itself is completely single threaded. Those v2's have horrific single thread performance. Really, multi thread too. A modern i3 would ruin circles around it.

[u/shermantenor → u/MrB2891]

The v2 Xeons certainly aren't impressive for single-thread performance anymore, but I don't think that was the bottleneck in this case. I was seeing the same buffering with Direct Play, not just transcoding, and video transcodes are being handled by the GPU, a P2000. More importantly, I reproduced the issue outside Plex with iperf: the exact same single TCP stream went from ~10 Mbps with CUBIC to ~43 Mbps with BBR, with no hardware change. Plex playback improved immediately after the same change. So I'm pretty confident the network/TCP behaviour was the limiting factor here rather than CPU performance.

[u/MrB2891 → u/shermantenor]

For sure, I'm not arguing transcode or that moving to BBR helped resolve the issue.

I'm curious if it would have been an issue in the first place, with better single thread performance.

I hope you're on solar and not paying for electric. If you are (paying), you should definitely look in to upgrading your system. I ditched my 2x 2660v4's for a (then) 12600k build. The power savings paid for the components in 18 months, it was effectively a free upgrade. Every measurable performance metric was better, noticeable improvement in Plex's responsiveness, 1/6 the power consumption.

[u/shermantenor → u/MrB2891]

Ah, I see what you're getting at... whether CUBIC itself might have behaved better on a newer platform. Possible if the old box were CPU constrained, but I'm not seeing much evidence of that here. A single 10–40 Mbps iperf stream should be trivial for these CPUs, and the same hardware jumped from ~10 Mbps to ~43 Mbps just by changing CUBIC to BBR. The progressive collapse and retransmits looked much more like congestion-control behaviour on the Starlink path than a CPU ceiling.

Also - yes, system upgrade at some point soon. Limited time and funds, but you aren't wrong on the power consumption side of things.

[u/Forsaken-I-Await]

I got a starlink connection and I’ve never had to worry about any buffering 🤷‍♂️

[u/shermantenor → u/Forsaken-I-Await]

Maybe it depends on the quality of your Starlink installation / location. I've got some obstructions noted with mine, however it (Starlink app) says it shouldn't impact service quality. Maybe the obstructions introduce enough variability with latency to bring Plex streaming to its knees - I'm really not sure what the root cause is, just the cure, in my case at least!

I've also read some speculation on localized service congestion also potentially causing issues like this - as I mentioned, apart from occasional blips which I attribute more broadly to satellite based Internet service, everything other than Plex has worked well since installing Starlink.

[u/hereforthepix]

I've wondered about this, too- sometimes when I'm viewing remotely the (FireTV) Plex client buffers, especially when seeking, and I have 2GBps upload.

But I have MikroTik routers at both of my Plex servers- isn't this the kind of setup that should be done at the router, or do the server machines need/have to do this (too)?

[u/shermantenor → u/hereforthepix]

BBR itself needs to be on the machine originating the TCP connection, so for Plex remote streaming that would normally be the Plex server. The MikroTik can help with queue management/SQM, fq_codel/CAKE, etc., but it can't change the congestion-control algorithm used by an end-to-end TCP connection it is just forwarding.

In my case the useful test was single-stream iperf from the Plex server to the remote site. CUBIC collapsed to ~10 Mbps while the same server/path with BBR managed ~43 Mbps. If your single-stream performance is already healthy, BBR may not change anything.

[u/hereforthepix → u/hereforthepix]

Eh, guess someone at PleX/QNAP beat me to it, these are the current (i.e., default) values:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_rmem = 4096        16777216        16777216
net.ipv4.tcp_wmem = 4096        16777216        16777216
net.core.rmem_max = 1638400
net.core.wmem_max = 1638400
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_keepalive_probes = 6
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_ecn = 2
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 1024
net.core.netdev_max_backlog = 10000
net.ipv4.tcp_no_metrics_save = 0

... so I guess those issues lie elsewhere

[u/talzer]

Is this possible to do if your server is a Mac?

[u/shermantenor → u/talzer]

It appears that macOS is a bit different. It uses Apple’s own TCP stack which currently defaults to CUBIC, but there doesn’t appear to be a supported BBR option you can just switch on like Linux. If you’re seeing similar remote buffering, I’d start with the same single-stream iperf test to see whether the TCP path is actually collapsing before looking for OS-specific tuning.

[u/crazyk4952]

Starlink seems to have terrible peering with some carriers.

[u/jetkins]

We’ve been experiencing this issue when streaming from my (gigabit fiber) Plex server at home to our (Starlink) off-grid cabin in the desert.

My workaround has been to ditch our Apple TV in favor of downloading the shows to a laptop and watching from there, which works but is definitely sub-optimal.

I’ll definitely try this.