We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Aristide
3 years agoHelpful | Level 7
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...
Greg-DB
3 years agoDropbox Staff
It sounds like this may be because we recently updated the server back-end for some types of Dropbox links to use "Transfer-Encoding: chunked" (and accordingly not return the "Content-Length" response header) on HTTP/1.1. HTTP clients should automatically handle this, but it's possible yours doesn't.
Are you able to retrieve any specific error message or output from your HTTP client? That would help confirm that.
If that's the issue, you should update your client/code to support "Transfer-Encoding: chunked" and not assume the "Content-Length" response header will be present. Or, switch to HTTP/2, where the "Content-Length" response header should be present.
- Aristide3 years agoHelpful | Level 7
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?
- Aristide3 years agoHelpful | Level 7
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-DB3 years agoDropbox 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.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
5,877 PostsLatest Activity: 12 months agoIf you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!