I have the following problem which drives me crazy:
I play an audio file on a webpage:
<audio ref="audio" preload="metadata" class="AudioPlayer__audio">
<source src="file" type="audio/mp3" codecs="mp3">
<p>Your browser doesn't support HTML5 audio. Here is a link to the audio instead.</p>
</audio>
I have built a custom timeline which needs to know the duration of the file.
Now this works fine except if I deploy it.
On my remote the duration of the audio file is infinity.
Obviously and how I read in other threads this is due to the fact that Safari makes two requests:
The first one just trying to get some bytes. Range: bytes=0-1
This request fails.
After that Safari makes another request trying to get the file without the range stuff, which succeeds, but somehow the audio duration is infinity.
I read stuff about Headers and that the must allow ranges, but I don't really know much about Headers and how to fix this specific issue.
Here you can see the request and the response.
It seems to me that range is allowed because I see:
Accept-Ranges: bytes
What else am I missing, and how would I even make changes to those headers?
The response header probably would need some changes on my netlify settings,
but what about my request headers? And is this even the problem?
I have no real clue where I could go on debugging this issue.
thanks for any pointers.
Cheers
Related
According to : https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopedocuments/list/
The EnvelopeDocument model should have "sizeBytes" property on it.
However, I'm making calls to GET https://demo.docusign.net/restapi/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}/documents
and the payload does not have it.
I also tried hitting HEAD https://demo.docusign.net/restapi/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}/documents/{{documentId}
to see if I could read the headers without the actual content but that I receive a 404 NOT FOUND so it must not be supported.
The only way I can see to accomplish this would be to hit the download file endpoint directly, reading the content-length header, and then cancelling the request before streaming any data from it.
Is there a better way to do this?
The only way to do this would be to make a get envelope call
GET https://demo.docusign.net/restapi/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}/documents
Then in the headers, you will find Content-Length, this is the file size
Reached out to DocuSign and they confirmed there's no way to do this other than to hit the download endpoint and read the content length header.
After some experimentation i found this doesnt really work either because the Content Length header is not always accurate from their api. The only way I can see to do it is to download the entire file into memory and take a count of the bytes, or keep track of the byte count as you stream it to its destination.
I'm playing with the spotify play button and try to make it display an arbitrary set of tracks, that I'm giving as a comma-separated list of IDs.
It works well most of the time, but it can happen that the button is not properly rendered, and displays the Spotify Developer Page instead, like shown here: http://xben.free.fr/spotify/
I feel like it happens when using an important number of tracks (more than 80).
Has one of you experienced the same problem, or know if there is a limitation? I went through the doc and it only mentions a 1000 tracks restriction when using an existing playlist.
Yes, it is known limitation that trackset uris can not be longer than around 80 tracks (depending on your trackset title).
The reasoning for the arbitrary limit goes something like this: It is the longest possible url that you can send to older IE browsers. We want it to work the same across all browsers. If it doesn't work in one, it shouldn't work in the others either.
Two problems however.
The way it is implemented, just setting suhosin.get.max_value_length = 2048 in php conf. If it is too big, suhosin will just drop the parameter, making the request look like https://embed.spotify.com which will redirect to the developer site. Not the best of error messages. We will fix.
The limit should be documented. We will fix. Maybe even raise the limit and tell people to be vary of certain browsers.
(I work at Spotify)
Hopefully someone can help me out with this.
I'm playing around with a node.js server that streams audio to a client, and I want to create an HTML5 player. Right now, I'm streaming the code from node using chunked encoding, and if you go directly to the URL, it works great.
What I'd like to do is embed this using the HTML5 <audio> tag, like so:
<audio src="http://server/stream?file=123">
where /stream is the endpoint for the node server to stream the MP3. The HTML5 player loads fine in Safari and Chrome, but it doesn't allow me to seek, and Safari even says it's a "Live Broadcast". In the headers of /stream, I include the file size and file type, and the response gets ended properly.
Any thoughts on how I could get around this? I certainly could just send the whole file at once, but then the player would wait until the whole thing is downloaded--I'd rather stream it.
Make sure the server accepts Range requests, you can check to see if Accept-Ranges is in the header. In jPlayer this is a common issue in Webkit (particularly Chrome) browsers when it comes to progress and seeking functionality.
You might not be using jPlayer, but the Server Response information on the official website may be of some use.
http://www.jplayer.org/latest/developer-guide/#jPlayer-server-response
but I had the same problem.
Its necessary to set some headers for media file response.
as example:
Accept-Ranges:bytes
Content-Length:7437847
Content-Range:bytes 0-7437846/7437847
Then audio tag will be able to seeking
have a look here http://www.scottandrew.com/pub/html5audioplayer/, I used this and it plays while it is downloading the file. It waits a little bit for the buffer but then plays. Never tried seeking though but I would start by trying to set the "aud.currentTime" in his code if that can be done.
Good luck
Are you sending an Accept-Ranges (RFC 2616, Section 14.5) response header?
From what I understand you want the player to allow the user to jump to parts of the audio/video that haven't buffered yet, something like what Vimeo / YouTube players do.. Tbh I'm not sure if this is possible, as I've looked at some of the examples of html5 medial elements and they just didn't allow me to seek to unbuffered parts :(
If you want to seek through the buffered part - then it's not a problem. In fact - you're creating a problem for yourself here, as far as I understand. You want to stream the file, and what this does is makes the player think you have some kind of live stream out there. If you just sent the file directly - you wouldn't have this issue, because the player will be able to start playing before it loaded the whole file. This works fine with both audio and video elements, and I've confirmed this behaviour in both Chrome and FF :)
Hope this helps!
perhaps this html5 audio player example will explain and demonstrate us the new element and its .load, .play, .currentTime, etc. methods.
i use an array of elements and can set the currentTime position of course.
we can use also eventhandlers (e.g. 'loadeddata') to wait before allow to seek.
ping and have fun with html5 :)
I'm trying to get rid of the error pop-up window that appears in IE saying "page contains both secure and non-secure items". I have made sure all the links are pointing to https:// rather than http://. I have also looked at the fiddler and firebug logs to see that all the requests are being made to https:// links only.
Here's a similar question asked on SO : IE - "This page contains both secure and non-secure items"
The guy whose answer was accepted hit right on target. I wish I knew how he debugged to narrow down to that solution.
Any help is appreciated.
Thanks
You don't need to actually load a resource in order to trigger the warning, a reference is all it takes. The <object> used to load a Flash applet is enough (if you reference the HTTP URI for the Flash Plugin).
The easiest thing to do is to open up the source and search for 'http:' with your editor. If that doesn't turn up anything, do the same with the output of document.getElementsByTagName('html')[[0].innerHTML.
You could either do a top-down or bottom-up approach to try to track down the issue. Top-down is where you'd start commenting out stuff until it goes away while in the bottom-up case you strip out everything and then slowly start adding back in things like Flash, Javascript, and CSS as it may be some include or function that is the culprit.
I'm looking into ways to develop an extension for IE6+ that will allow handling of custom MIME types.
As an example, I need to be able to take a document with a custom MIME type that is returned by the server, perform some processing on it, and then change the MIME type back to something that IE can natively handle, such as text/html or image/jpeg.
I am familiar with the urlmon MIME filters, but they have a huge weakness; they are only invoked for the top level document, and not for any of the additional page content such as images and the like.
The one way that I can think of that will work is to hook the HTTP/S protocol handlers using vtable/iat patches, similar to the way Google Gears works, to be able to intercept the response headers, and modify the headers and response body when a document with the specified MIME type is received.
I'm wondering if anybody else has any good ideas on how this could be accomplished in a less hacky/intrusive way.
Edit:
Just thought I'd follow up on this and mention that I went with the vtable patch into the HTTP/S protocol handlers, and it worked much better than I expected. If anybody else is looking to do something like this, I highly recommend taking a look at the HttpHandlerPatch class in Google Gears for some inspiration.
Several years ago, I wrote such extensions, BHO, IE toolbars, etc., based on a book called Shell Programming in VB6. The book I used is this one: http://oreilly.com/catalog/9781565926707/ This book tells you how to hook and trap messages coming into IE. I wrote a kind of screen scraper (post-render style not like a spider that doesn't execute the javascript first). It was based on IE5 but the extensions still work with IE6. I probably still have the VB6 source somewhere. I am not offering to upgrade it to .Net for you though.
PS. The review on that page by Haroeris Astrum is by me :)