I wish I could do some more testing as well, but I've had too many crashes and interruptions (aka complaints from users 
). Interesting, though, that @thestigma has been testing the same version without any issues. Perhaps the problem occurs mostly with Plex scans after all. I'll start using the latest Rclone beta again once a new version has been released.
Thanks for the log 
Yes rar is fine.
I couldn't find any stream errors in your log. What seems to be happening now is this (there are a few of these in your log)
2019/10/14 03:01:36 DEBUG : Google drive root 'Crypt1': Checking for changes on remote
2019/10/14 03:01:40 DEBUG : pacer: low level retry 1/10 (error googleapi: got HTTP response code 500 with body: {
"error": {
"code": 500,
"message": null
}
}
)
2019/10/14 03:01:40 DEBUG : pacer: Rate limited, increasing sleep to 1.108197628s
2019/10/14 03:01:43 DEBUG : pacer: Reducing sleep to 0s
This is where the stream error would have happened but we got a 500 error instead and rclone retried successfully.
There are no other errors in your log which is good!
So tentatively I'm going to say there was a problem at Google drive with HTTP2 which is now fixed at the Google end.
More testing would be appreciated! the latest beta is in a pretty good shape to become v1.50 so now would be a great time!
Would you prefer I switch to that for the rest of the time I dedicate to stability-testing?
(currently using rclone v1.49.5-180-gea304f41-fix-http2-retry-beta )
Kind of might as well right? ..
That would be good I think.
I merged the stream id fix (which didn't seem to do anything but it is harmless), so this beta would be the one to test.
https://beta.rclone.org/v1.49.5-221-gf9f9d502-beta/ (uploaded in 15-30 mins)
Just started a fresh mount with build 223. Primed and Plex scan running. Fingers crossed.
No good 
Ran OK for about 2.5 hours, then Plex scan stalled with Rclone.exe at about 40% CPU when I first noticed it. Five minutes later CPU usage is steady at about 15%. Plex crashed. No errors in Rclone mount window.
I really need a log with -vv of when this happens. Any chance you could send me one? Email it to nick@craig-wood.com with a link to this forum post if you can!
A bit later today I'll produce another version which disables http2 by default for google drive - hopefully that will fix the problem but still enable us to use go1.13.
I have made a new version which is the latest beta (so nearly v1.50) with http/2 disabled by default for the google drive backend but compiled with go1.13
I'm really hoping this fixes the problems - if not then I'll have to revert back to go1.12 for v1.50 which I was hoping not to!
Testing appreciated
1 Like
i start using https://beta.rclone.org/v1.49.5-221-gf9f9d502-beta/ yesterday, and for now is working ok. I did some scan with emby and no errors.
1 Like
Never got a stall on 180. Switched to 221 and that's been running overnight - nothing on that either yet.
What does disabling the http2 really entail anyway? There is some sort of downside to this I assume?
HTTP2 is a newer protocol and offers some speed advantages.
1 Like
http2 is really about latency. I don't think it changes the throughput particularly.
So http2 could decrease the seek times on video files which would be useful but the effect is relatively small in my tests about 20mS out of 280mS average seek time.
The effect might be bigger if you were doing lots of things at once with drive.
Well, I hope we don't have to go to that step then. Latency is pretty important.
I haven't actually seen any stalls since before i started testing on 180, without Plex mind you. That version was not checked. It was just the latest beta from a handful ours before the post - so it may or may not have been 180, or a version slightly older. As many hours as it has run stable now since verified 180 though, it looks pretty stable to me.
Possible to make it a flag toggle rather than removing it wholesale - if it turns out to only make problems in spesific circumstances?
@ncw Sorry, I keep forgetting to enable any kind of log for my testing. Before I start using build 226*, is running the mount with -vv enough? I assume I'd also have to use --log-level and --log-file. What's best for you, considering I'm using Windows?
EDIT: *it's actually build 228
hello,
this is what is i use
--log-level=DEBUG --log-file=rclone.log
Thanks. If I don't specify a folder to save the log in, will it just use the one that I launch rclone.exe from?
- --log-level=DEBUG is the same as -vv, so either will produce the same output.
- the log file will be created in the current working folder.
EDIT: yes, the log file will be created in the folder that you launched rclone.exe from.
1 Like
Yes I added a flag --drive-disable-http2 which defaults to true but can be changed to false if desired.
I hope by 1.51 we'll have worked out what is going on and can change the default!
Excellent! Then I can continue testing in day-to-day use without having to swap between so many versions.