Note that there are some explanatory texts on larger screens.

plurals
  1. PO<audio>.addEventListener progress fails to fire off if content loads too quickly
    primarykey
    data
    text
    <p>I'd never thought quickly loading content would be an issue before but I'm running into a perculiar issue.</p> <p>I've made a HTML5 music player and the "buffered" bar works fine if the content loads at a normal speed, but if the content loads very quickly, i.e. over LAN, then the listener doesn't respond quickly enough to do anything. The addEventListener is inside the jQuery document ready function. The code I'm using is below:</p> <pre><code>audio.addEventListener('progress', function() { if(audio.duration &amp;&amp; audio.buffered.end(0)) { if(resuming == 1) { resuming = 0; resumeplaypos = ReadCookie('resumeplaypos'); audio.currentTime = resumeplaypos; } loaded = (audio.buffered.end(0) / audio.duration) * 100; $('.player-loaded').width(loaded + '%'); console.log('Loaded: ' + loaded); } }, false); </code></pre> <p>Now what happens usually is (using console.log to check) this only fires off once, generally between 10 and 20%. Consequently my buffer bar is stuck at that value despite the entire track having been loaded. On rare occasions it may manage to fire off twice, outputting:</p> <pre><code>[11:37:42.323] Loaded: 7.525227180155711 @ http://topaz:88/music.js:316 [11:37:42.605] Loaded: 59.57557430800252 @ http://topaz:88/music.js:316 </code></pre> <p>But normally it's just something like this:</p> <pre><code>[11:39:52.773] Loaded: 13.313090306445885 @ http://topaz:88/music.js:316 </code></pre> <p>Is there any way to make the progress listener more reliable or will I have to work around this some other way? (or am I doing something silly).</p> <p>You can ignore the resume code, that's something else I'm working on that resumes the track when someone comes back to the page, it's not used in this situation.</p> <p>The audio element is created immediately when the JS file is loaded via the following line:</p> <pre><code>var audio = document.createElement("audio"); </code></pre> <p>I've moved the code outside of the document ready function and added a console log to the progress outside of the if check, but the behaviour still mimics the logging inside as before:</p> <pre><code>[10:49:24.698] 31.702494 / 276.8 @ http://topaz:88/music.js:302 [10:49:24.728] 31.702494 / 276.8 @ http://topaz:88/music.js:302 </code></pre> <p>When using:</p> <pre><code>console.log(audio.buffered.end(0) + " / " + audio.duration); </code></pre> <p>Although what is odd there is that it reported the same value twice when the second value clearly should have been the "completed" value. Browser is Firefox 11, Apache server (2.2.22). Note that I'm now getting a 50/50 success failure rate (success being when it actually reports having loaded 100% at the end).</p> <p>I've put up example code here - <a href="https://xnode.org/paste/12" rel="nofollow">https://xnode.org/paste/12</a> (I can't figure out how to get jsfiddle to run it properly, plus it would be missing the audio file anyway) - that shows the same behaviour in the minimalist way possible.</p> <p>Only 2 out of the 5 times (via a Ctrl+F5 refresh) did it fire off the 100% completion result. The other 3 times it fired off once between 10 and 40% (randomly). The test audio file was a 6.9MB quality 6 OGG Vorbis encoded track on another machine on the LAN served from an Apache 2.2.22 box.</p> <p>It's worth noting that if you try hosting the audio file on the same machine as the web-page, it will NOT work because it loads too quickly (it immediately fires off the 100% completion). So it seems this only happens if A) the file doesn't load -instantly- and B) it doesn't load slowly enough for the handler to keep firing over and over.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload