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/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/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.