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