application/binary type returned for media files

[abiluck]

Hi, I am using gettemporarylink API to obtain url to the file that can be later played. That url when requested itself, returns wrong Content-Type header for media files. For example audio file with m4a extension now has Content-Type response header set to “application/binary” instead of “audio/mp4” or “audio/mpeg”. Such behaviour has started in the last 24 hours and breaks our entire workflow. No changes were made on our side and it used to work before. Could you please look into this?

[Greg-DB]

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

[Greg-DB · Accepted solution]

We've reverted to the previous behavior for newly returned links. I can't guarantee what the exact behavior will be long-term, but I'll follow up once I have an update on that.

[abiluck]

Awesome! Thank you for prompt response and resolution.

[abiluck]

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.

[Greg-DB]

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.

[abiluck]

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. 

[abiluck]

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.

[Greg-DB]

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.

[Greg-DB]

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?