Forums

Team, I'm working on an audio streaming platform, i have set up a some media files in my static folder in mp3 format. I have also written a js file to add the seek bar navigation to change the audio.currentTime function to fast forward or rewind.

This works fine in firefox but does not work on chrome or safari. I have looked around for this on the web nothing has worked for me yet.

sample js code:

$(document).on('click',"#tracker",function(e){
    audio.addEventListener('canplay', function(){
    var parentOffset = $('#tracker').offset();
    var relX = e.pageX - parentOffset.left;
    var width = $('#tracker').width();
    audio.currentTime= ((relX/width))*audio.duration;
    });
});

I would suggesting going to codementor for these sort of front end questions, as we deal with mostly backend/server side stuff.

Conrad, The issue is that server does not support byte ranges. I was just wondering if PA supports BYTE RANGES. When i serve a file, i do not see status code 206 - partial content.

Most of the solution to this problem is around, server not serving the files in BYTE RANGES format. Can you please confirm?

Thanks

Hi pakumar2,

Just investigated and it looks like supporting uwsgi byte ranges will require an nginx upgrade. We will look into doing that and let you know when the upgrade is done, but we don't have a concrete time for when this will happen yet.

Conrad

Conrad,

Thank you for the response. Is the upgrade going to cost you guys heavily? Because, My whole app depends on streaming and without BYTE RANGES, i will not be able to seek in the audio/video player.

Also, can you let me know a work around, in the meanwhile to get this running. Thanks

The problem is that upgrading nginx and adding the uwsgi_force_ranges directive may cause unforeseen problems (eg: what if we were using another directive that is now deprecated/taken out, or what if a certain protocol is disabled by default in the new version but enabled by default in the old version etc) and so it needs to be tested thoroughly.

We intend to push out a new ipython notebooks beta soon, and so would prefer not to do any significant infrastructure changes before then.

For a temporary workaround, you could investigate what firefox is doing vs chrome and safari? I believe you can still have buffering without byte seeking, and so you could just limit seeking to before the bufferline and all will be well. Alternatively you could look at putting something like cloudfront/cloud flare etc in front of pythonanywhere, and setting up byte range requests there.

Conrad