Rclone mount random slow speeds

I've been wrestling with the same (or very similar) problem for a few weeks now. Files will play through jellyfin or plex fine most of the time, but occasionally will only transfer the file at around 300k/s like OP which causes them to pause a few seconds into the episode. Stopping and starting the episode once or twice typically resolves the issue (and checking bw monitor indicates it's transferring at a normal rate) but it's frustrating and I'm all out of ideas. I've tried numerous rclone mount settings with no change. Debug logs show nothing helpful.

Exact same thing is happening to me. Experimented with lots of different settings for the mount. Seems to only affect a single file at a time seemingly at random.

My setup is a little different. VPS with rclone mounted with VFS.

I will add that restarting the mount has no effect, the only solution is to try again later and that same file is now suddenly super quick. Or wait out the slow file and the next file my server moves onto is fine.

Yeah, I'm finding that restarting doesn't really do anything as well. Sometimes it works but I guess it's more waiting it out or restarting the file transfer. And it seems to affect one file like you said.

Hopefully there's a solution soon

Also experiencing the same issue, Even happens with "rclone copy" commands. Stopping and restarting the copy process all of a sudden it goes from ~300kb/s to 90mb/s

I understand there was a change with Google API recently that had to be ported into rclone, but ive also tested with version 1.55.1 which as i understand it was prior to this change occurring.. Not sure if we are being limited by Google themselves or if this is an issue with rclone itself?

I've enabled debug logging on the mount point and can't see anything erroring out, just slow

I've seen this too. I think some google endpoints are slow and some are fast and it is luck as to whether you get a slow one.

Wow, this is worrisome. What do you mean by “endpoints”?
Is this something completely out of our control? It started all of a sudden for me too… some weeks ago. Since I could not find any error in the logs I did not even know how to ask help for this.

I tried describing this here: Difference between mounting and serving through WebDAV - #3 by ashlar

Assuming its a endpoint thing, is there anyway to force trying another endpoint that you can think of. If nothing else than to test the theory.

If that does end up being the problem I wonder if it would be possible to detect that somehow and trigger a endpoint change.

if i remember correctly,
there have been posts about changing dns servers and how that can affect gdrive performance.

I've updated my server's nameservers to google's 8.8.8.8, 8.8.4.4 and am monitoring. Will report back

Sadly setting google's DNS servers don't appear to change anything for me :frowning:
I also tried mapping the google drive windows client to my server and while it was more performant when it worked than rclone, I would still get randomly capped at 300ishk/s for no clear reason. Has anyone contacted google support over this?

Not wrong, still occuring for me too.

Interesting that it still happens with GoogleDrive app, at least that rules out Rclone

Well technically rclone was still in the mix because I'm using a crypt remote - just pointing at a different location, but that seems exceedingly unlikely to be causing the issue.

This "endpoint" choice happens for every single request made by rclone? Because I saw it happen in the middle of watching a movie, streamed from Drive.

Rclone makes a request for a host.

The local OS decides where that goes by issuing a DNS name lookup.

Depending on the OS and how it's setup, it make get a new IP, same IP or use a cached value it already has or depending on what router / DNS you are set to, that can also return different things.

It's an OS/local setup flow and nothing directly related to rclone per se.

In my setup, I got one IP for the drive API:

felix@gemini:~$ host api.google.com
api.google.com is an alias for api.l.google.com.
api.l.google.com has address 142.250.176.196

Dropbox gives me one too.

felix@gemini:~$ host api.dropbox.com
api.dropbox.com is an alias for api-env.dropbox-dns.com.
api-env.dropbox-dns.com has address 162.125.4.19
api-env.dropbox-dns.com has IPv6 address 2620:100:6019:19::a27d:413

Using different DNS servers, you get different results "generally".

felix@gemini:~$ nslookup
> api.google.com
Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
api.google.com	canonical name = api.l.google.com.
Name:	api.l.google.com
Address: 142.250.72.100
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> api.google.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
api.google.com	canonical name = api.l.google.com.
Name:	api.l.google.com
Address: 142.251.41.4
> server 1.1.1.1
Default server: 1.1.1.1
Address: 1.1.1.1#53
> api.google.com
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
api.google.com	canonical name = api.l.google.com.
Name:	api.l.google.com
Address: 142.251.35.164
>

Depending on your provider, you may or may not have good or bad peering to that IP and depending on load, it could also get worse. For bad peering, there isn't much to do other than trying to find an IP that works best for you.

But here is there a way to "lock" to a good peering? Because, as I stated previously, it happened to me randomly during a movie. So rclone was already active and downloading stuff from Drive. And all of a sudden it got capped to 18Mbps. Then after a bit of stopping, skpping ahead, skipping backward... it started back using my full bandwidth.

Not really as it's all dependent on your ISP and the route.

Sometimes, you can't fix it at all unfortunately as you can only determine the path so much. Some folks use VPNs to get better peering.

Check out:

What Is ISP Peering? Why Your High-Speed Internet Is Slow (makeuseof.com)

That seems to give a decent description.

1 Like

I've been dealing with this for at least three months now. So far, I've only blamed my ISP's terrible peering to my remote server, but lately I'm not so sure anymore. I'm assuming most of you guys host Plex at home, so for you it could be either bad peering to Google's servers, or it could be something with Plex itself. I can't rule out the latter after reading more and more reports of Plex users having issues with buffering. And these are guys with local media/servers.

I have yet to setup a local Plex server to see if I get better results. Up until a year ago, I watched everything through MPC-HC on a local HTPC (with an Rclone mount), and I never had a single issue. When I switched to a SHIELD and Plex (remote), I also had zero buffering with even the largest files. Wasn't until about three months ago that my troubles started, and since then I haven't been able to watch any UHD REMUX without constant buffering.

That's my case. Rclone mount on HTPC, watching through Kodi. Plex does not enter the picture at all, for me.

1 Like

You're ashlar42 on doom9, I take it? :slight_smile:

I used to be very active in the madVR community until about a year ago when, like I said, I switched from PC to SHIELD.

Yes, that's me. I am going to check what DNS I have in use on the HTPC and see whether I can at least minimize the random instances.

Yesterday two 4K HDR episodes played back flawlessly... The seemingly total randomness of this makes it a nightmare to debug.