You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Incorrect duration of some streamed audio files.
Hello, I have a problem with some audio files. To be able to read them correctly on an audio player (in my case on android) you have to be able to determine the duration. for some files the duratio...
The client in my case is the one integrated in the native android player.
What I can see so far:
- not all files are affected.
- the file is not corrupted because readable with the link:
- curiously, the meta data duration which are contained in the first bytes of the audio file, is not correct when I partially download the file (usually the first 1000 KB) while the other meta datas are ok (title, album, art etc.).
Response headers for a file where the duration is correctly returned:
accept-ranges: bytes
cache-control: max-age=60
content-disposition: attachment; filename="Isaac Delusion - Midnight Sun.mp3"; filename*=UTF-8''Isaac%20Delusion%20-%20Midnight%20Sun.mp3
content-security-policy: sandbox
pragma: public
referrer-policy: no-referrer
vary: Origin, Accept-Encoding
x-content-security-policy: sandbox
x-content-type-options: nosniff
x-robots-tag: noindex, nofollow, noimageindex
x-server-response-time: 46
x-webkit-csp: sandbox
content-type: application/json
accept-encoding: identity,gzip
date: Sat, 12 Feb 2022 11:30:52 GMT
server: envoy
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-robots-tag: noindex, nofollow, noimageindex
content-encoding: gzip
x-dropbox-response-origin: far_remote
x-dropbox-request-id: a76b8827cea24632ad411939dea04550
Response headers for a file where the returned duration is not correct:
accept-ranges: bytes
cache-control: max-age=60
content-disposition: attachment; filename="Pixies - Dig for Fire.mp3"; filename*=UTF-8''Pixies%20-%20Dig%20for%20Fire.mp3
content-security-policy: sandbox
pragma: public
referrer-policy: no-referrer
vary: Origin, Accept-Encoding
x-content-security-policy: sandbox
x-content-type-options: nosniff
x-robots-tag: noindex, nofollow, noimageindex
x-server-response-time: 47
x-webkit-csp: sandbox
content-type: application/json
accept-encoding: identity,gzip
date: Sat, 12 Feb 2022 11:28:20 GMT
server: envoy
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-robots-tag: noindex, nofollow, noimageindex
content-encoding: gzip
x-dropbox-response-origin: far_remote
x-dropbox-request-id: f63eef26b69d49c18ebb96ca9e1d4ffc
In both cases I don't have a "content-length" header?.
I noticed content-type: application/json and not audio/mpeg why?
To get this headers in response I used okhttp client.
In fact, this problem appeared recently.
same result if I force the protocol with HTTP/2 with:
public static OkHttpClient getHttp2Client(){
ConnectionPool connectionPool = new ConnectionPool();
return new OkHttpClient.Builder()
.followRedirects(true)
.protocols(Arrays.asList(Protocol.HTTP_2,Protocol.HTTP_1_1))
.retryOnConnectionFailure(true)
.connectionPool(connectionPool)
.build();
}
"you should update your client/code to support "Transfer-Encoding: chunked"
Does this mean that I have to add "Transfer-Encoding: chunked" as a header to my request?
It seems that this "bug" is reported in these posts:
https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Functionality-changes/td-p/575628
I confirm that files whose duration cannot be determined by android's mediaPlayer are not seekable.
It seems to me that the DropBox android app always downloads files locally before playing them?
- Greg-DB
Dropbox Staff
Thanks for following up. I can't offer any details on the implementation of the Dropbox Android app itself, but I'll follow up with any updates on the reports you linked to.
- Greg-DB
Update: in order to temporarily accommodate clients that don’t properly support automatically handling “Transfer-Encoding: chunked”, we’re temporarily rolling back this change, so that these links will no longer use “Transfer-Encoding: chunked” and will instead return “Content-Length” on HTTP/1.1. We will begin rolling that out starting around 2/17. That will be in place until around 3/1. At that point, we will begin using “Transfer-Encoding: chunked” and no longer returning “Content-Length” on HTTP/1.1 again.
Going forward, please ensure that your clients are able to automatically handle both chunked encoding and non-chunked encoding automatically.Thanks Greg-DB for the follow up.
But there will therefore be a problem with Android because at this stage, I don't see how it is possible to force the client integrated into the mediaPlayer to handle both chunked encoding and non-chunked encoding automatically, it is not accessible, or so by a method that I do not know.
It is possible to partially circumvent the duration problem by calculating with file size and bitrate (for MP3 files with CBR) but not to circumvent the ability to seek .
Is there a way to get feedback from the developers of the DropBox app for android?
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
