Very Slow Upload to Dropbox Remote

same issue here, seems like Dropbox throttle down Hetzner IPs, on other Providers i could test there was no issue.

I'm getting max of around 30MB/sec per upload. If I set transfers to around 4 I can max out my connection from hetzner, But would be nice if I could get 1 file to max out the connection.

1 Like

Hi, did you Transfer from Mount to Mount or remote to remote?

Would you please show me your configuration?
I have now tested different, mount to mount, remote to remote, mount to remote, remote to mount. And I get very different results and none of them gives me 30 MB/s per file.

Thx in advance

as I tested this 11 days ago I got 49MB/sec
now today I wanted to upload more files and I have this same issue, max is 600 kb/sec with transfer 5
and on 1 test file it is only 150-160kb/sec

rclone copy -P test.img dropbox:xxx/
Transferred:   	   34.902 MiB / 1 GiB, 3%, 183.893 KiB/s, ETA 1h31m47s
Transferred:            0 / 1, 0%
Elapsed time:      4m10.7s
Transferring:
 * test.img:  3% /1Gi, 183.892Ki/s, 1h31m4

geez

drag and drop?
do you have a Desktop Linux at Hetzner?

Hi. Yep. I’m finding the best speeds are drag and drop from Ubuntu folder to mounted crypt Dropbox drive.
Also, Sonarr and Radar give great speeds too.
Edit: I do use a desktop on hetzner server.

Surely drag and drop is essentially the same API command? I tried attaching a random user-agent to the request with no difference in speed =(

I've only just set this up, downloading files and then uploading. Had a few issues with my server and started again. Speeds went down to about 5MB/sec each, Added --disable-http2 and --bind ipaddress in cloudplow and have seemed to go back to normal again.

3 Likes

I got the same problem since friday. --bind ipaddress worked for me :slight_smile:

I guess Hetzner will find a workaround for that as well to block it, or throttle upload speed to Dropbox...

This is really a bit stupid. I mean Dropbox is nothing "evil".
Duplicati is unfortunately also affected by this and my backups are not really running well anymore. I hope these restrictions will be lifted soon.

FYI, Getting good speeds on a Hetzner CAX11 with

rclone move google_media_crypt::Shows/ dropbox_media_crypt:Shows/ --bind <IPv4 Address> --checkers 12 --tpslimit 12 --transfers 12 --fast-list --progress
Transferred:       28.030 GiB / 3.054 TiB, 1%, 119.865 MiB/s, ETA 7h21m20s
Checks:                14 / 26, 54%
Deleted:                7 (files), 0 (dirs)
Renamed:                7
Transferred:            7 / 1826, 0%
Elapsed time:      4m51.7s

I think it might be a IPv6 thing?

3 Likes

After first tests with --bind <IPv4 Address> it seems you are absolutely right.

did you tried --poll-interval 0m1s? that worked on my onedrive mount.
Update: sorry I didn't check the topic. But I just wanted to say that --poll-interval 0m1s switch made my mount to sync instantly.

Poll interval is for checking for changes on the mount and does not influence sync or copy.

Yes and I am using it with rclone mount

Right - Just saying, it has nothing to do with uploading as the post here is talking about.

Poll interval is only for when the mount checks for new updates on the remote that were done outside of rclone. Nothing else.

Just to confirm I also got back to original speeds with --bind

So thanks to whoever it was that said this first

now I have a new issue, with --bind my upload speed with --bwlimit 75M throttled to 120-130kb/sec
if I restart / or remove the bwlimit then it goes for a few minutes with 130-140MB/sec, and then it comes again, 120-130kb/sec

started the same copy from another machine/with another IP, and there it is working
will see how long
maybe Dropbox do not like all the people transferring all the stuff from gdrive to them :slight_smile:

just disable ipv6 that did it for me now it works again perfect