An API call to drive.files.get != a full download of the file. You will see in the GSuite audit a log a file 'download' for each 'get' but that does not count against your download as you are only getting a chunk of the file.
I understand that, but it does count against your download. Your assumption is incorrect in my findings, you may only be downloading 128M or 1G out of 50G, but it's still counted as 1 file download. Every XXX has downloaded XXXX file entry in the audit log counts against the filedownloadquota limit. It doesn't matter if it was 128M chunk or a 4G chunk, each entry = 1 download towards the quota.
There's a 10 TB limit, but there is also a drive.files.get call limit as well, and since vfs-read-chunk-size calls drive.files.get multiple times when a file is read, it does cause downloadquotaexceeded. For non plex users, this is a hard limit to reach for the most part. It increasingly becomes more common as your library grows, especially if you have sonarr/radarr doing it's default 12 hour scans with analyse media on. This is because sonarr/radarr call mediainfo on every file every 12 hours unless you change the settings. Additionally, plex calls mediainfo on files it hasn't analyzed in a while and at minimum is 4 api calls for just a mediainfo call. During playback, for a 60gb file (not uncommon in my lib) at 128MB read chunk with unlimited growth, that's (assuming the user plays once and doesn't stop...) about 10 downloads (as google sees it). I see most people have a 2G limit, so that would be a lot more without unlimited growth.
I had plex scanning disabled, until this month I could refresh sonarr/radarr 3 times each in a day and rescan plex a few times each a day and didn't hit the quota ban. Just like you....
Only times I hit the ban is when I had to rescan my entire library in (won't ever need to do that again). When I added jellyfin and emby, I increased the amount of file download entries by at least 16x, simply due to mediainfo calls that emby/jellyfin does every library scan, regardless if it already analyzed the file. (2 programs, each analyse call uses 4 downloads, scans twice a day. 2 x 4 x 2). No wonder people hit the quota easily when running more than just plex....
I eventually found this out and disabled the scheduled tasks. I have since stopped using both at this point and still running into the quota limit exceeded almost a week later.
Regardless of someones use case or settings, 4 download calls for consecutive reads / mediainfo calls, etc, should be addressed. That's the root cause of the quota ban.
It's definitely an issue that vfs-cache-mode=full does more than 1 files.get.call. It should trap additional reads for that file and not make additional calls...
So if simply rclone solves the issue where the same file is being downloaded at the same time, this would be a big win to reduce the number of downloads.
I just tested Google File Stream (I had it disabled on my windows pc for a while now)
It causes something similar, so it's not unique to rclone. Using File Explorer going to a folder with videos causes it to "sync" and rapidly cause a bunch of downloaded file entries. This is because of explorer thumbnails. I confirmed this by letting explorer finish getting the thumbnails, then exiting the folder and going back, no additional downloads. Each file in the folder has 8-15 entries in the audit log from GFS + explorer thumbnails.
I then tested playback using the default windows video player through GFS. Immediately 6 download entries. I then seeked around the file, and that caused 15+ more entries. This is why GFS causes the download quota bans... It would make sense that GFS read chunk would be small, since most people store docs... This proves that rclone is better as long as the read-chunk is higher and has growth.
Since my library is all scanned and I'm using the new radarr/sonarr options, I should have no random disk scans or file reads. So a high vfs-read-chunk-size would be more beneficial in this case, where I'm 'settled' and have my system working based on api notifications only.
vfs-read-chunk-size=1G and see if the download calls in the audit log are reduced.
vfs-cache-mode=full is 4-6 downloads max. You can use the thumbnail / capture feature in a 3-4 hour maintenance window.
vfs-cache-mode=off would be more than that and IMO I do not recommended this unless you are doing an initial scan. I really don't recommend it if you want to use the video thumbnail / chapter extraction features.