As for the .m4b the correct content-type should be "audio/mp4", because m4b container format is very similar to m4a.
The larger issue I have is the one I described earlier in the thread, namely that urls obtained with getTemporaryLink can no longer be played with standard iOS AVPlayer component. I wasn't able to identify the root cause for that. The content-type for other media formats like mp3 and m4a is correct, but may be something else has changed in the server response on your end. I was hoping you will be able to identify the changes on the backend that happened in that timeframe.
Ok, thanks. So, as it stands right now, even .m4a and .mp3 files aren't working for you. (I was previously under the impression the first fix was working for those from your earlier responses.)
Anyway, we unfortunately can't provide support for AVPlayer, since that's not made by Dropbox. We have recently updated the implementation of the links returned by get_temporary_link and we'll be happy to see if we can further update it to accommodate this use case, but we'd need some more specific information as to what behavior is needed. Perhaps you can get some support or documentation from Apple to determine what the requirements are to avoid this "This media format is not supported" error?
Correct, none of the media formats can be played right now. Unfortunately, there isn't any description about this error in Apple documentation. Last time it was caused by wrong content-type, but now content-type is correct for mp3, m4a, mp4 so there must be something else. Is it possible to identify what has changed in http response headers in October when requesting the file with get_temporary_link?
I'll see if we can track down what may have changed there, but the Dropbox API spec doesn't document or guarantee these particular aspects of these links, so I can't make any promises unfortunately.
Hi, after numerous experiments I found out iOS AVPlayer does not like "X-Content-Security-Policy" field in the response header. It seems like this field has been deprecated and replaced with "Content-Security-Policy" which you already return in response. Is it something that can be fixed?
Thanks for sharing this. Can you also share any documentation or output showing that's the issue though, for our reference? I ask because we're still looking into this, but we believe we've found a behavior on our side that, in some cases, would affect the content type that the client is using.
I'll follow up with any updates on that, but in the meantime it looks like you can also work around this like this:
let asset = AVURLAsset(url: url, options:["AVURLAssetOutOfBandMIMETypeKey": "audio/mpeg"])
You'd need to come up with a way to dynamically determine the correct MIME type for the file though (e.g., mapping from file extension to MIME type), in place of the "audio/mpeg" here.
I used a sample app with reverse proxy server on the device. When the file is requested from Dropbox server, the response headers can be altered and then passed to AVPlayer. This way I have determined that without ""X-Content-Security-Policy" AVPlayer is able to play the file.
Would source code be helpful?
I see, thanks. I believe in that kind of setup, the reverse proxy would actually obscure the issue we found, since it's making the request on behalf of the client, instead of the client doing it itself. (And according to a sample I saved from October 1, we were already previously sending 'X-Content-Security-Policy' anyway.)
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!