Setting --transfers or --checkers does nothing

Suspected Bug
1

Trying to server-side copy on an S3 remote (move one folder into another), but no matter what global flags I set in rclone, the file processing speed is stuck at 2-3 files per second. And this is a server-side copy as well.

Here are my rcloneview global flags: --no-check-certificate;--ftp-no-check-certificate;--s3-directory-markers;--s3-upload-concurrency "32";--s3-upload-cutoff "32M";--transfers "64";--checkers "64";--s3-chunk-size "16M";--delete-empty-src-dirs

When I execute the same operation using CLI -P --transfers 64 --checkers 64 --s3-chunk-size 16M --s3-upload-cutoff 32M --s3-upload-concurrency 32 --exclude-from rclone_exclude.txt --ignore-case --delete-empty-src-dirs, the move speed was 20.7k files processed per minute, 610MiB total, finished in 1minute 26 seconds.

With RcloneView, moving one folder into another on the same S3 remote the file processing speed is 2-3 per second. It doesn’t seem like setting --transfers or --checkers in global rcloneview flags does anything. I also tried using --delete-empty-src-dirs, it also seems to not do anything. Did multiple complete restarts, including rcloneview, rcd, rclone.exe, etc. Still nothing.

Am I doing something wrong? Or is there really no way of setting copy/move flags? Without this, RcloneView’s transfer speed is literally less than 1% of using CLI in the example above, at which point it completely loses its point.

2

Sorry for the late reply, and thank you for providing such a detailed report. We’re currently working on this issue. From your description it seems that some global flags (such as --transfers, --checkers, and others) are not being applied properly when running operations through RcloneView, which explains the much slower performance compared to the CLI.

We’ll investigate how flags are being passed to rclone in RcloneView and make sure they are respected during server-side copy/move operations.

Thank you again for pointing this out—your comparison is very helpful. We’ll follow up once we have a fix available.

3

Hello,

We’ve identified the cause of the problem and have fixed it in the latest build. Please try the following version:

The global flags should now be correctly applied during copy/move operations, including server-side copy on S3 remotes.

Thanks again for reporting this issue and for the detailed comparison—it helped us track down the problem quickly!