application/binary type returned for media files

Thanks for the report. We'll look into it.

Awesome! Thank you for prompt response and resolution.

Hi, looks like the problem is back although it is a bit different now.

1. When accessing .m4b file with temp link I am getting content-type = "application/octet-stream"

2. Files > 100Mb cannot be played using the temp url. Error: Maximum response size reached

The problem started around Oct 14-15. Please have a look.

1. Thanks, we'll check on this.

2. The "Maximum response size reached" error doesn't appear to be coming from Dropbox itself. I also just tried and I was able to successfully access a file larger than 100 MB via a temporary link retrieved by get_temporary_link, so it looks like this is a client-side issue. You'll need to troubleshoot whatever client you're using to attempt to play that.

Thank you for looking into this. You are right about #2, it was an error from Postman, sorry about that. 

I discovered #1 while investigating the bigger issue, that we are currently experiencing. We use default AVPlayer iOS component to play media in the iOS app. It was working fine for years until recently. Now it refuses to play any media from Dropbox, returns an error "

This media format is not supported". This error is quite generic and usually happens when AVPlayer can't play the file for whatever reason. In order to isolate the problem, I tried very basic sample app with AVPlayer, hardcoded url and play button and it refuses to play the file from Dropbox provided the temp url. I can provide a link to the GitHub sample project if that would be of any help.

It was working fine after you reverted the changes to content-type in the generated link. This time the content-type is correct but the AVPlayer still refuses to play any audio file. This started on Oct 14-15. 

Hi, is there any update to this problem? It's been impacting many users and I am trying to determine the reason as there were no changes on the client side and it suddenly stopped working. If you need any additional information, please let me know.

I don't have an update on this yet. I'll check in with the team and follow up here once I have any news.

We're looking into this, and for reference, we are still now returning a "Content-Type" of "audio/mp4" for .m4a files, and I can confirm we are currently returning "application/octet-stream" for .m4b files. From what we can tell though, we did not previously return a more specific "Content-Type" like "audio/mp4" for .m4b.

Can you confirm if you are currently seeing an issue only for .m4b files, or for .m4a files as well?

Either way, can you more specifically identify what behavior you would need to get this working for your use case?

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.