100+ percents of copying on last release

What is the problem you are having with rclone?

Now when I copy files to/from remote (OpenDrive) files are copying over 100%. Please take look to the picture crlone-01|690x491. Now 340 Gb has transferred from 238. 143% total, 364% max of one file. The last release I used 1.49.2 has no this bug.

What is your rclone version (output from rclone version)

1.49.4

Which OS you are using and how many bits (eg Windows 7, 64 bit)

QTS 4.4.1.1081 64bit (Qnap Linux)

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

OpenDrive

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

rclone copy /share/frekenfok opendrive:Backup/FR --progress --filter-from ~/rclone-filter.txt

A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)

I think this happens with retries. If you use -vv you will see rclone doing the retries.

I've seen something similar, usually with very small files, where it can often go to 130-140% for a split-second before finishing. (not exactly the same as OP with his large files which I have not experienced).

I just assumed it was some artifact of the progress-calculation algorithm due to overhead or packet-sizes or something, so I've just been ignoring it since everything seems to be working fine otherwise.

I've fairly certain this phenomenon has not been tied to any spesific version as I remember seeing it several times when testing IOPS performance over several months.

Again, this may not be directly the same issue as the OP experienced, but I figured I'd mention it for being related.

Retries... Last week I did about 2 Tb with no these retries, the same source and remote using 1.49.2 (but with annoying "file already closed" errors).
Now I have 258% total and the process is still on despite all the files are on remote.
I hope it will end some time or other...

As NCW said, if you turn on -vv you should be able to see if this is the case (and what is causing the retries).

Because if you are getting more than 50% retries (to reach 200% or more) then that is not normal in any case and it should be investigated. Feel free to post the debug log here and we will help analyze what the underlying problem is.

To turn on -vv I need to start a new process. I still hope the current transfer will succeed so will be waiting a bit more... until 300% for example.
Also I'm thinking to get back to good old 1.49.2.

It might be worth trying 1.49.5 as people definitely did have problems with 1.49.4. There are very few code changes in 1.49.x as they are a patch release only, however I accidentally compiled 1.49.4 with go1.13.x instead of go1.12.x like the other 1.49.x

Just Ctrl-C'd. Checked all the files transferred. Everything is ok. Have no idea what Rclone did last 12 hours since it uploaded 100% of the last file. It's definitely a bug.
There's no 1.49.5 Qnap package yet so I'll go to 1.94.3. It has no "file already closed" issue and I hope it has no this 100%+ bug. Will test.

Just started a new upload with -vv. With no issues yet. Will let you know if something go the same way.

Ok. Tested a similar upload with 1.49.3. Almost the same issue. Two files: 33 Mb and 42 Gb. I manually stopped transfer on 57 Gb. The last -vv line showed:

2019-10-07 06:48:58 DEBUG : Reserve-2018.7z: Uploading chunk 1439, size=10485760, remain=30984624666

After that I checked the files and they're ok.

Transferred: 0 / 0 Bytes, -, 0 Bytes/s, ETA -
Errors: 0
Checks: 2 / 2, 100%
Transferred: 0 / 0, -
Elapsed time: 1m19.9s

What does it mean?

What is -vv ?
I know single "v" means "verbose", but "vv"?

More verbose than -v

Debug output, or "very verbose" if you prefer to think that way.
It makes rclone spam your output with every little thing it does. Way too much to absorb real-time - but crucial to figure out what is happening under the hood if you suspect problems.

Can I copy files from local to encrypted mount via explorer.exe?

yes. no problem.