Plex suddenly buffering

What is the problem you are having with rclone?

I've been running a plex/rclone setup succesfully for about a few years now. In the last week I suddenly started getting an odd issue. About 1 minute into watching anything, Plex would stop, and start buffering. If I wait, stop and start again, I can get another 10-20seconds out, but it stops again.

More context at the bottom of the post.

Run the command 'rclone version' and share the full output of the command.

rclone v1.57.0
  - os/version: ubuntu 16.04 (64 bit)
  - os/kernel: 4.4.0-210-generic (x86_64)
  - os/type: linux
  - os/arch: amd64
  - go/version: go1.17.2
  - go/linking: static
  - go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

/usr/bin/rclone mount media-enc--crypt: /mnt/media \
   --allow-other \
   --dir-cache-time 5000h \
   --log-file /var/log/rclone.log \
   --log-level DEBUG \
   --poll-interval 10s \
   --umask 002 \
   --rc \
   --rc-addr :5572 \
   --rc-no-auth \
   --cache-dir /data/rclone-enc_upload \
   --drive-pacer-min-sleep 10ms \
   --drive-pacer-burst 200 \
   --vfs-cache-mode full \
   --vfs-cache-max-size 100G \
   --vfs-cache-max-age 5000h \
   --vfs-cache-poll-interval 5m \
   --vfs-read-ahead 2G \
   --bwlimit-file 32M

The rclone config contents with secrets removed.

type = drive
client_id = <redacted>
client_secret = <redacted>
scope = drive
root_folder_id =
service_account_file =
token = <redacted>

type = crypt
remote = gdrive:media-enc
filename_encryption = standard
directory_name_encryption = true
password = <redacted>
password2 = <redacted>

A log from the command with the -vv flag

I saw rate limiting in my first log, so I added google API credentials. This is the log after I added those google API credentials:

Adding the google API credentials to my config didn't seem to get rid of the rate limiting problems so I've included both logs.

They show the mount starting, me starting to play something on Plex. After about a minute, the buffering starts. In the first log I hold off for slightly longer before stopping the stream, which is why I've also included it here. I then stop the stream, and exit the mount.

I've seen another post (How to diagnose buffering on Plex) where they also had rate limiting and similar problems. It's unclear if rate limiting was the problem or not. What's odd is, my google API console doesn't seem to indicate I am over my limits from what I can understand, so not entirely sure what causes that.

For context, both my device and server are on 500mbps+ connections so I'm going to guess it isn't internet troubles. I have no problem streaming content from other websites.

Playback is almost instant, which made me consider rclone in the first place. It's as if, if it's in the cache already, it's quick for Plex to play, otherwise it's stalled by gdrive streaming.

It's possible this is a Plex problem, but given how long it's been working well for, I'm guessing it may actually be something to do with Google Drive. Saying that, I don't know what specifically since it's not clear if rate limiting is the limiting factor here (it generally recovers quite quickly).

Any help is much appreciated!

For those few rate limit errors, you can

Increase those numbers or just try for a bit with defaults. It depends on what your quotas are in the API console and how many mounts/other things are using the same API creds (if any). I basically did the mat for my 100 second quota max and divided that out to get those numbers.

Is it Direct Playing or Transcoding?

Your logs look pretty normal and when playback happens, it's all from cache.

It looks like a large bitrate movie so is your server remote? Bad peering / buffering isn't something you can tune around unfortunately.

What player are you using?

This! #1 issue with remote servers, in my experience.

@rbhalla Ping it and let us know how high it is, and if you see a lot of spikes. A trace route might reveal issues as well.

Hey both, thanks for your help here.

It was a direct stream here.

So if I understand there's two things to chase.

1) Rate limiting
According to my console, I never crossed 20 requests in 100seconds and my quota is 20,000 which makes me think this is something else. I will try playing with the pacer settings to see if I can eliminate this entirely. Is there anyway I diagnose whether I'm at all bottlenecked by gdrive->server? I'm afraid I can't really understand the log well enough to confirm either way.

2) Peering
This isn't one I considered actually so thanks for the suggestion. Because it has happened so suddenly (and nothing has changed on device or server) I disregarded that.

My server is remote, and I'm playing from Plex's web client currently (chrome on a Macbook).

I ran ping against my server for a little while and got some fairly good results. Here is a shorter run that is representative:

ping <>
PING <> (<myip>): 56 data bytes
64 bytes from <myip>: icmp_seq=0 ttl=52 time=7.882 ms
64 bytes from <myip>: icmp_seq=1 ttl=52 time=14.409 ms
64 bytes from <myip>: icmp_seq=2 ttl=52 time=7.927 ms
64 bytes from <myip>: icmp_seq=3 ttl=52 time=7.931 ms
64 bytes from <myip>: icmp_seq=4 ttl=52 time=10.172 ms
64 bytes from <myip>: icmp_seq=5 ttl=52 time=8.173 ms
64 bytes from <myip>: icmp_seq=6 ttl=52 time=7.922 ms
64 bytes from <myip>: icmp_seq=7 ttl=52 time=14.405 ms
64 bytes from <myip>: icmp_seq=8 ttl=52 time=14.084 ms
64 bytes from <myip>: icmp_seq=9 ttl=52 time=8.776 ms
64 bytes from <myip>: icmp_seq=10 ttl=52 time=8.476 ms
64 bytes from <myip>: icmp_seq=11 ttl=52 time=7.837 ms
64 bytes from <myip>: icmp_seq=12 ttl=52 time=14.033 ms
64 bytes from <myip>: icmp_seq=13 ttl=52 time=8.196 ms
64 bytes from <myip>: icmp_seq=14 ttl=52 time=8.399 ms
64 bytes from <myip>: icmp_seq=15 ttl=52 time=8.630 ms
64 bytes from <myip>: icmp_seq=16 ttl=52 time=7.877 ms
64 bytes from <myip>: icmp_seq=17 ttl=52 time=8.161 ms
64 bytes from <myip>: icmp_seq=18 ttl=52 time=14.240 ms
64 bytes from <myip>: icmp_seq=19 ttl=52 time=10.278 ms
64 bytes from <myip>: icmp_seq=20 ttl=52 time=14.176 ms
64 bytes from <myip>: icmp_seq=21 ttl=52 time=7.884 ms
64 bytes from <myip>: icmp_seq=22 ttl=52 time=14.141 ms
64 bytes from <myip>: icmp_seq=23 ttl=52 time=8.415 ms
64 bytes from <myip>: icmp_seq=24 ttl=52 time=8.062 ms
64 bytes from <myip>: icmp_seq=25 ttl=52 time=8.556 ms
64 bytes from <myip>: icmp_seq=26 ttl=52 time=14.566 ms
64 bytes from <myip>: icmp_seq=27 ttl=52 time=7.985 ms
64 bytes from <myip>: icmp_seq=28 ttl=52 time=14.540 ms
64 bytes from <myip>: icmp_seq=29 ttl=52 time=14.385 ms
64 bytes from <myip>: icmp_seq=30 ttl=52 time=14.420 ms
--- <> ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.837/10.482/14.566/2.891 ms

It also seems like I sustain about 10-20MB/s when downloading single files.

This is the results from the speedtest-cli on my remote server:

Testing download speed........................................
Download: 493.36 Mbit/s
Testing upload speed..................................................
Upload: 439.69 Mbit/s

My device stats are similar

I'm not sure if there are better ways to assess peering between a remote server and a local device, so if you recommend any tools to confirm, please do let me know.

Otherwise, it seems like peering is otherwise good?

So from that, I can only assume that rate limiting may be the thing. Does this make sense logically? Or am I missing something?

Bad peering is tough to pin down.

You have all the symptoms of it though.

RClone is playing the file from cache from your logs so that's a local drive.

Plex isn't transcoding the video and I'd imagine based on the that screenshot, the server itself isn't CPU bound so that leaves the connection from client to player.

Either the server->client doesn't have enough bandwidth (seems like it does based on your feedback) or the connection gets some packet loss at times or it can't handle the 'bursts' of traffic.

Most of plex clients suck as you can't setup any real 'buffer' on them.

I'd try to the actual plex client on the mac as that's a bit more robust. Builtin TV clients are the worst generally. Infuse on the Apple ecosystem isn't bad either as that has some decent buffering built in as well.

You could also try lower quality things and see if that works as well and see if you have a breaking point of traffic that doesn't work.

That's actually very good latency, considering it's a remote server. Must be fairly close to you, I'm guessing.

This I don't really understand. Plex server is remote, so why not use a client other than Plex Web (the worst out of all of them)? One that can direct play everything.

Local as in a drive on the remote server, as I understand it, which, of course, is subject to potentially bad peering.

Agreed, and make sure everything is wired, if you can. TV clients would be so much better, if only manufacturers started putting gig ports in their devices.

hi, imho, point-in-time tests, such as speedtest and tracert, are not very useful to diagnose peering and other such issues.

see this post:

for a longer term view.
---windows, winmtr + pathping
--- on linux, mtr


Plus, peering can change, as I witness all the time with Frontier out here. Can be problem-free for months, and then one day the buffering starts. Sometimes, albeit rarely, I am unable to watch anything at all.

EDIT: A good example - I just did a tracert from local to remote, and this time it went straight from my CA ISP to a hop in New Jersey. Never seen that before. Normally, it goes L.A. -> San Jose -> Chicago, Beauharnois.

do you mean frontier here is the US, or that other country?

i had a tech contract for approx. eight years, as a part-time voip tech.
i can commiserate, frontier was the worst of the worst in residential NJ.

Frontier FIOS here in CA, yeah.

I guess my point is that the backbone peering changes all the time.

I've had FIOS here since 2007, and it's been flawless. Rarely an outage in all those years. Speeds always consistent. Really no difference when it went from Verizon to Frontier. Can't complain. Well, except for the occasional peering issues, but even those happen rarely, and it's usually not the ISP's fault.

ok, different frontier companies.

about verizon fios, 1Gbps here in nj, fantastic.
At my house, i am very lucky to have a choice between optimum cable and verizon fios.
in the past, was only optimum, and the day fios was offered, i never looked back.

same at my office, i have both of them, dual wan failover.
fios is a huge leap over optimum.

and here IT goes again, temporarily borrowing the OP topic for off topic banter.

1 Like

This may sound silly, but I hadn't really considered using another client on a computer before. The web has always worked relatively well for me.

I installed the mac app and everything worked perfectly immediately. Instant start, no buffering.

This definitely seems like a Plex (web) issue, so I'm going to maybe reach out to their support instead. Given how sudden it all was with no changes on my side, it's possible there was a web client change that may be affecting something. I noticed the dashboard view was sometimes showing the stream had buffered appropriately, but the player was stuck buffering. Like in the screenshot below:

Massively appreciate everyone's effort in helping me troubleshoot, especially since it didn't turn out to be rclone related. I learnt a few things I never knew before. Thank you!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.