G Suite "Download Quota" API Ban

It will be automatic after installing 6.4.8. No settings to adjust.

In a short test I have the same effect in the logs of gsuite a 30min series is “downloaded” within about 3 minutes over 50 times.

This is expected, as this is how Google tracks access. The only way around this would be to download the file in full prior to playback, which isn’t feasible in most cases.

What has changed in this update is a reduction in the amount of unnecessary calls which can have an impact on bans.

Thanks for the clarification. I’ll see if it has any effect over the next few days.

1 Like

Hi @james. Here are my findings after the first round of tests using 6.4.8:

  • Navigating on the Movies interface for less than 5 minutes without actually opening none of them generated 286 download entries in the GSuite logs - total download file size registered: 2186.96 GB
  • 13 minutes of movie playback generated 87 download entries in the GSuite logs - total download file size registered: 774.71 GB (the movie itself is small: 8.89 GB)
  • Total download size registered during the test: 2961.67 GB

Here is the spreadsheet with the data for your appreciation:

1 Like

Do we know the max download cap for google drive? wasnt it around 10TB/day? Based on your test results you would have already reached ~30% of your quota in 5 minutes time. yikes…

1 Like

Could we set up a clone of your database with aliases pointing to the real files? For browsing infuse uses the alias name but doesn’t follow the link, then for watching gets the original file. Then the pointers wouldn’t take up space?

1 Like

Google doesn’t make info about their abuse thresholds public so it’s hard to say which metrics they look at when it comes to bans.

If you were seeing bans during real-world use in versions prior to 6.4.7 I would encourage you to continue using the app as normal to see if these bans continue or if they are reduced.

6.4.7 and 6.4.8 both add changes which can make a big difference in many cases, but at the end of the day it’s clear Google didn’t design their service with streaming in mind so the options we have are somewhat limited.

Also, utilizing the library view (instead of browsing Google Drive folders directly) will eliminate nearly all API calls until it comes time to actually play something.

That was my expectation before I tested this exact use case with 6.4.8. However, accordingly to my last comment, infuse still makes a lot of API calls on the library view:

Please review this and let me know what I am doing wrong.

when i see 2x uhd movies with about 60gb and these are loaded over 100 times i am not “always” banned, although the 10TB limit is reached

One thing to keep in mind is that Infuse does not pre-fetch specs for videos stored on Google Drive, and will load them if/when the detail page for a video is opened.

Caching of these specs (even in Library view) will use some API calls. However, once specs have been cached for a particular video they will sync to iCloud (if you are using Infuse Pro) and will not need to be fetched again.

Edit: If you are using Google Drive, then of course you are using Infuse Pro. :crazy_face:

Hi @james - well, I had that in mind during the test and opened some details pages - I will run this again.

One question/suggestion: is there a way to change this so instead of using API calls to download meta data from content directly from the movies files you would just use their filenames (or directory names) as key to fetch the movie information from the movie info service? That way I believe you would bring the number of API calls for navigation/movie info to zero.

I believe this would be impossible since people have video files in different resolutions 720p, 1080p 4K etc, audio levels such as 2.0, 5.1, 7.1, ATMOS, etc. and also HDR or DV along with directors cuts or other special releases with different running times.

Infuse needs to touch the file it’s going to play to see what options were used during ripping.

For fetching metadata, Infuse will use file names which we can get in bulk and doesn’t require a lot of API calls. This is what occurs during the normal library scanning process.

From the info we have, it seems most bans come from accessing a large number of videos within a short period of time (EG reading file specs for all videos in a library, as Infuse needs to download a portion of the video in order to read the file info). As a result, we disabled this awhile back (well over a year ago).

Additionally, in 6.4.7 we added a lightweight cache which reduces the API calls even further for indexing/browsing.

6.4.8 adds some optimizations for streaming.

As I mentioned before, to determine if the changes are helpful for your use case it would be best to use Infuse normally and see if any bans occur. The usage info you see in Google’s console will always appear high and scary. :wink:

1 Like

Well, it all depends on how much you would compromise in order to fit in the GDrive API context. For example, when you are just navigating through the videos without looking at their details, all that movie meta data do not make any difference - maybe that info would only when you click on move to see the details page.

Even stuff like number of audio channels, video resolution, HDR etc can be read from filename if naming conventions are put in place. If I am not wrong, that is how Kodi works.

The compromise? Well, ppl not doing a good job at following naming conventions for filenames/folder names won’t have accurate media flags on their details page.

The advantage: zero file download API calls for movie navigation. In my tests, browsing through the movies collection for 5 minutes translates in more API calls than playing a movie for the same amount of time. That does not make a lot of sense to me.

I think that should be at least an option so that the user can choose one media detail scrap method or the other. If most of the ppl using GDrive as source(who know very well their own content) the media details are not important as the movie/tv show info.

I tested this again:

  • Only browsing the movies, without clicking on any of them for about 3 minutes and got 142 downloads registered in GDrive logs. A total of 968.82 GB in size. It should have been zero in this case, shouldn’t it?

  • Browsing and opening the details page for about 4 minutes and got 29 downloads registered in GDrive logs. A total of 396.03 GB in size. I’ve noticed there are more than one download registered in the log for each file associated with a single movie - in one case there are 5 of them.

  • Movie playback for 40 minutes: got 116 downloads registered in GDrive logs. A total of 1968.19 GB in size. The movie size is 16.97 GB

Here is the log details Firecore-inFuse-Log-20200813 - Google Sheets

Please review the data and test cases. I believe you will find good opportunities for improvements and fixes

Thanks for the info.

If you an re-run these tests, and then also submit a report from Infuse (post the 5 digit code here) we can try and match up the calls to the activity in Infuse.

Although I can confirm with 100% of certainty that the last API calls I reported were all created by Infuse I’ll repeat the tests let you know

1 Like

Hi @james - I ran the tests again, 2 times now:
Test 1

  • 5 minutes of navigation through the movies: 178 download records, 1863.62 GB in total download size
  • 5 minutes of navigation through the movies detail page: 238 download records, 2600.98 GB in total download size
  • 5 minutes of movie playback: 113 download records, 1282.97 GB in total download size. The movie total size is 11.35 GB GB
  • Total download data during the tests: 5747.57 GB
  • Logs: Firecore-inFuse-Log-1-20200814 - Google Sheets
  • Report 5 digit code: 8KCQ4

Test 2

  • 5 minutes of navigation through the movies: 6 download records, 48 GB in total download size
  • 5 minutes of navigation through the movies detail page: 18 download records, 36.78 GB in total download size
  • 5 minutes of movie playback: 9 download records, 100.47 GB in total download size. The movie total size is 12.56 GB
  • Total download data during the tests: 185.38 GB GB
  • Logs: Firecore-inFuse-Log-2-20200814 - Google Sheets
  • Report 5 digit code: BB859

I’ve noticed that Test 2 showed better results than Test 1. Both of the tests were on APTV 4K using the latest inFuse PRO version.

1 Like

Curious…does the Library “Scan for Changes” feature also use up a ton of API calls, thereby using a good amount of “downloads”?