Do not have it handy as it also depends on OeDrive failing with this error:
Failed to copy: resourceModified: The resource has changed since the caller last read it; usually an eTag mismatch
Upon troubleshooting it I saw it a couple of times I did it with -vv flag but unfortunately didn't capture the log entry, but saw the connection closed was with an IPv6 address and therefore started to test if IPv4 fixed it.
I tried --disable-http2 flag as well but that didn't help. I noticed that if I do --bind 0.0.0.0 it will still use IPv6, but if I use --bind "my real ipv4" I do get binded to IPv4 and the eTag mismatch goes away.
I'm trying to recreate the error and will share the logs once I do. But wanted to open the forum post in case other people are having this problem and might try the workaround that is working for me or if somebody might be able to give more information about this.
As I'm sure you are aware Microsoft has the most undocumented/random rate limits around. I have tried ---tpslimit 5 and still get randomly throttled, sometimes it's copying some big files it will close the connection and rate limit for 5 seconds up to 5 minutes.
During my analysis seems they throttle also based on tenant and not just account, as I have multiple accounts and got throttled heavy when multiple accounts were syncing at the same time. We have since adjusted so they run at different times and helped a lot.
Now, just to explain, my problem/question is why --bind 0.0.0.0 is not binding rclone to IPv4 as expected and to let people know that seems the eTag mismatch (which there seems to be a couple of forum posts around this) seems to be related to Microsoft and their IPv6 servers as it doesn't happen to me using IPv4 and only when using IPv6.
Thanks Nick. I guess I will update my scripts to bind to their respective IPv4 address.
I'll continue to monitor and see if I find any more details on the eTag mismatch using IPv6. I will force a couple of the scripts to use IPv6 and see if they get them while IPv4 do not and report back.