iOS - loadStreamableURLForFile Causes Error 429 (too much traffic)

Brandon M.12

I'm developing an app that allows me to stream the videos I'm storing in Dropbox down to a client application on iOS. I authenticate appropriately, locate the file and call loadStreamableURLForFile to pass to the AVPlayer on iOS to display.

Everything works great, the video plays. But about 1 hour in (it's a two-hour 1.7GB test file on a Free account for testing) the video freezes and I receive an email about my shared links exceeding bandwidth - error 429 - and my ability to play videos is disabled. 

This happens on a single play through of my own content directly. There are no other pieces of content in this dropbox and nothing is shared with anyone. I have never used the test account before and so there is no way I could have run into any bandwidth issues. 

Based on the file size, I should be nowhere near the 20gb limit. Plus, my understanding was that playback of your own files wasn't subject to the bandwidth limit, only shares. 

Am I generating the wrong kind of link from the API to playback? I notice if I view Dropbox.com in safari, I can playback the video.

How can I generate the URL that visiting Dropbox on Safari does within the iOS (objective-c) SDK?

Greg-DB

Hi Brandon, thanks for the report. For reference, any links created on a particular account, including those returned by loadStreamableURLForFile, are subject to the bandwidth restrictions for links.

However, based on the numbers you've detailed, the usage here certainly wouldn't have exceed the limits. 

Can you double check you're looking at the same account though? These link restrictions are per account, and it's easy to mix up which account is which when developing an app like this (e.g., work versus personal). Please check the account information for the account for the access token used to call loadStreamableURLForFile by calling loadAccountInfo. (You can also check the email address in the "to:" field of the email notification.) Then, compare that with wherever you're looking at to confirm there isn't other shared link activity on that account, e.g., the email address for the logged in account on the web site.

As far as alternatives are concerned though, while any links are subject to these restrictions, authenticated API calls are not, so a better solution would be to use loadFile, if possible. (I don't know if it would work well for your app in particular of course, nor do I have experience with AVPlayer.) In any case though, loadFile is a direct, authenticated API call (it uses /files (GET)) and is not subject to the bandwidth limits. 

Finally, in case it would be useful for your app, /files (GET) supports Range Retrieval Requests, which would let you download arbitrary portions of a particular file, still not subject to the bandwidth restrictions. That's not implemented in the iOS Core SDK, but the SDK is open source, so you could modify it if/as necessary.