I have made a music player by JS. However I have noticed that in Chrome it does not load some songs, basically any song except the one that loaded with the page.
Using inspect tool, I noticed the http request stays in "pending" status and never load the track. even tho the song is in the right folder.
if the song playes if i put its full address in the browser: www.site.com/music/song.mp3
but it does not load it in the music player.
I tried to stream songs from other websites and the player in Chrome works perfectly, such as this: https://media.rdjavan.com/media/mp3/Masih-Arash-AP-Be-Hame-Begoo.mp3.
The above address works fine n the player, so somehow it is streamable.
In safari it works fine, basically it is slow since it has to download the song but then it works. But in Chrome it stays in the status and never loads.
I was wondering is it related to MIMEs? or does my code have to do something with servers? I have tried it on an actually server and also on Xammp and both have same result. I have not fixed htaccess but it seems unrelated to my issue.
UPDATE:
I have noticed that Chrome is even slow in loading the directories. for example it takes ages of chrome to open localhost/AudioPlayer/audio/. So i believe it is a similar problem to why my music player does not load tracks.
Any idea?
jPlayer songs not loading correctly using MVC method
Look at the answer I gave in this thread above. This may or may not be your problem.
I had problems with chrome and my music player, you have to allow content-range requests.
These are enabled default in other browsers. Reason why it works in .mp3 url's is because it's using default <audio> </audio> tags which support content-range requests I think
Related
I'm creating some custom video controls for an html5 element. I've bound a click event handler to a play/pause button which calls .play() on the corresponding video.
From my research, Safari will block calls to .play() unless you are in a click handler, however it is blocking my calls to .play() despite the fact that I am triggering it from within a click handler, like so:
$('.video-container .play-pause').click(function(event){
var $video = $(event.currentTarget).parent().find('video');
if($video[0].paused)
$video[0].play();
else
$video[0].pause();
});
And the error:
Unhandled Promise Rejection: NotSupportedError (DOM Exception 9): The operation is not supported.
which is originating from $video[0].play();.
Safari Version 11.0.1 (13604.3.5)
OSX High Sierra 10.13.1 (17B48)
Any ideas?
Eugh. The solution was to use an absolute path for the video source, not a relative one.
This is wrong: <video src="assets/vid.mp4"></video>
This is correct: <video src="http://example.com/assets/vid.mp4"></video>
It's worth noting that this error occurs whenever you call .play() on a video that Safari has failed to load.
Something else interesting is that Safari requires the web server to support the byte-range requests to correctly load video files. See note here: https://stackoverflow.com/a/36299252
I recently had an issue with serving files from the php command line process instead of a dedicated web server like Apache or nginx and couldn't work out why videos were playing on the live site, but not in my development environment.
A quick way to determine this is to load the video directly from the address bar. If it fails to load, your server likely doesn't support byte-range requests.
Figured out, that Safari on Mac needs server sending content-type of video/mp4
When I tried to use direct link from document manager, which gave content-type application/mp4, this didn't work (only) in Safari.
I had same problem. The video didn't play in Safari. But apparently, when I put different mp4 file in same place, the video played successfully. I used ffmpeg tool with different settings to generate the video.
This question didn't help me but gave me the idea: FFMPEG video conversion to MP4 works everywhere except in iOS Safari/Chrome.
In short, make sure you tried some video file other than you are trying now.
I am building an HTML5 web game, a spin on the classic asteroids game to be precise. The problem I'm running into is that Safari, unlike Chrome or Firefox, will NOT automatically cache and use .wav sound files. This is causing substantial lag if there are an abundance of sounds occurring. On each instance of needing a "shooting" sound, the browser will perform a new GET request to obtain the audio file, as seen below:
you will see that the 151013__bubaproducer__laser-classic-shot-2.wav is the shooting sound that is being requested through the network over and over again and is not being cached. In an attempt to force Safari to cache this file, I've created an Asteroids.manifest file for the appcache to utilize:
Yes, that is the correct directory location relative to both the index.html as well as the Asteroids.manifest. And the manifest file does appear to be consumed, as it is visible in Safari's debugger storage:
Please let me know if you have any suggestions, as I've tried a variety of different setups of the .manifest file, including naming it .appcache, ensuring that it is served up with a MIME type of text/cache-manifest, and removing the NETWORK/CACHE/FALLBACK fields
Edit note: the window.applicationCache.status() is 1 (Idle)
I think that Safari doesn't cache audio files even if listed in the manifest file. Have you tried encoding the audio as BASE64 string and decode/convert back to audio at startup? Have a look at the WepApi, it can probably help you with that process.
If you mean mobile, then there are some posts here: HTML5 offline video caching in mobile safari
In summary, there is an ~5mb limit for the cache in mobile Safari. There may be something similar on the desktop. Another poster said that audio & video are not cached by the iPhone since they are played by external applications. It seems the only workaround is to store them as base64 in the local database (or local storage perhaps also? - Just keep in mind that "in private" browsing disables it).
If not, perhaps something to consider if you do plan to target the mobile version.
The problem is intermittent, but video.js is failing to load and play mp4's that have been cached in Chrome for OS X. Here's what I know so far:
Disable cache (while DevTools is open) allows the video to play 100% of the time on reload
If caching is not disabled, and cache is manually cleared the problem still happens
Closing and restarting Chrome will resolve the problem until the next page refresh
Appending a ?nocache=20131028-084318 to the source url does not resolve the problem.
Watching HTTP request using Charles Proxy, I see that on successful runs an HTTP request goes out to Brightcove (my video host). On failed refreshes, the request never happens.
On successful runs the sequence of VideoJS events:
loadstart
durationchange
loadedmetadata
loadeddata
On fails:
loadstart
I've tried a variety of ways of setting up the video element, including one noted here, Video.js Stalling during file load on iOS
and even the most basic setup noted here, https://github.com/videojs/video.js/blob/master/docs/setup.md The latter seems to work better; however, once the browser gets into a bad state clearing the cache and restarting the browser is required.
I'm having the same issue but in Chrome for Windows. I first noticed that it would only load when dev tools is open then I saw your question and realized the dev tools was bypassing caching.
If a user visits the page (on some browsers ie: Safari 6.1, etc...) the video will play the first time. If the user reloads the page by clicking in the address bar and hitting the 'ENTER' key, the video will not fire off it's LOADED/READY (or any other) events on the page 'reload'. This behavior does not happen if the user refreshes the page with the REFRESH button or REFRESH key combo (generally).
I bypassed my Brightcove player issues by dynamically loading the player on the page so it CANNOT be cached.
I also cache busted the Brightcove JS file for good measure.
Load player dynamically with this code:
http://support.brightcove.com/en/video-cloud/docs/dynamically-loading-player-using-javascript
Just some opinionated advice. Stay away form Brightcove whenever possible. My peers and I run into LOTS of bugs in their player as well as radically poor documentation.
I am not sure if this is specific to video.js. I am able to reproduce this problem by setting up a vanilla html5 video tag. It definitely looks to be related to some caching issue.
Currently, I am able to circumvent the problem by attaching a guid as a query parameter to the video url to ensure Chrome thinks this is a new video request. I do think there is a Chrome bug out there that needs to be addressed.
I Just found a ticket that matches what I can reproduce:
https://code.google.com/p/chromium/issues/detail?id=234779
I faced this problem and I solved it by disabling the cache to the javaScript file that contains the videojs instance options.
Add this line to your main page at the head
<script>document.write('<script src="vid.js?dev=' + Math.floor(Math.random() * 100) + '"\><\/script>');</script>
Note: vid.js is the file that I put the settings in..
Another solution that I didn't try, but I think it might work, is by adding the JavaScript of the settings in jQuery (ready function).
I'm trying to implement audio recording in a website. Basically the user should be able to press a button and speak something into the microphone. The recorded audio should then be sent to the server for further processing. I realise that you can do this with Flash, but for now I'm trying to avoid that.
I found several resources on the internet about it (i.e. link) but as it seems, this functionality is not widly supported yet. I experienced differences betweet the used browser and between the used operating system. For instance, the Chrome Browser doesn't seem to access any microphone on Linux correctly. So i was wondering if anyone knows a good resource to dive into this. Or maybe someone tried to set up something like this himself, and can help with some suggestions about where the limitations of HTML5 and the JavaScript Web Audio API are right now.
Thanks!
As of Chrome Version 27.0.1453.56 beta Mac, audio recording works with this demo application https://github.com/mattdiamond/Recorderjs
This app returns back a WAV file for the user which can be uploaded to the server.
If you want a truly robust solution that works on most desktop web browsers, you may need to resort to Flash.
This article covers up pretty well the current state of audio video capture possibilites using HTML5:
http://hdfvr.com/html5-video-recording
Also for just audio capture, here's a gitHub project that records audio to mp3 directly from the browser:
https://github.com/nusofthq/Recordmp3js
I have project that relies heavily on video and leverages html5 video when available. This was working across all browsers up until the IE9 RC was released about a week ago! This is very frustrating!
The confusing thing is I am able to play videos when they are sourced from a different location than my domain but not when they are sourced from my domain. It is as if the path to the video is being distorted.
WORKING:
<video src="http://www.jplayer.org/video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v" controls="controls">
</video>
NOT WORKING
<video src="http://www.mysite.com/video/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v" controls="controls">
</video>
Please bear in mind that this is working in all HTML5 browsers (even IE9 Beta) but not the very latest 'IE9 RC' release. And that all read/write permission have been set correctly.
To test this for yourself visit this link:
http://thebeer.co/labs/video.html
You should find in IE9 RC that the first two videos don't load but the last does. And even more strangely is you visit the direct URLS of the videos in IE9 RC they will play. All three videos work in Chrome (for the time being as the haven't dropped the H.264 format yet).
Please help me out guys...
A Broken Man.
Can you check your web server configuration? It seems that wrong MIME type is being sent. If you go to IE9 Developer tools, click the Network tab, press Stop capturing and reload the page, you will see that the first two videos are sent as text/plain, which means that no content-type is specified for them, and the last two are sent as video/mp4. Chrome seems to handle it somehow, but it really doesn't have to.
You can see the same using Firebug HTTP headers sniffer. Yet, Firefox doesn't play any of the videos, probably due to h.264 codec.