When listened from browser, second tab is not played. about icecast-kh HOT 8 CLOSED

First thing to do is find out what is actually happening in the cases you are referring to. Does icecast see a connection from the second tab, if it does then does it respond by sending data without issue. Icecast does not not any control over what playback is actually done by the receiver but they may react differently depending on if say range requests are sent.

karl.

from icecast-kh.

As I understand, browser doesn't send the second request, but I don't know why.
About the range requests - Chrome makes 2 requests in each tab - first without the range, then aborts it, the second one is with Range:bytes=0-, but I'm not sure it has any connection to the problem.

from icecast-kh.

not sure if you are looking any further into this, from the description, particular combinations are being stopped for playback. Obviously an application taking 2 streams and mixing them is one thing, opening 2 separate connections to the same stream may be determined as silly and not attempted. If icecast is not seeing the request then it is out of our control. I'll leave this open for a few days, let me know if you have something to add.

karl.

from icecast-kh.

It looks like we'll have to live with this behavior and Icecast can do nothing about it. I'll add more info here if I find something. Thanks for your support, Karl!

from icecast-kh.

It's a nice feature of these browsers to prevent unwanted multiple html5 audio playing the same instance of a sound.

You can easy avoid this limit in chrome adding a parameter in the url...

E.g. i can play your streams 2 times in parallel if i open:

http://mp3.nashe.ru/best-128.mp3?foobar=1
http://mp3.nashe.ru/best-128.mp3?channel=2

from icecast-kh.

And one connection seems to remain pending because it implement a queue, if you use it from javascript Audio() it start playing just after you close the tab with the playing connection

from icecast-kh.

Thanks Stefano! I would say it's a misfeature, but now at least I know what to do with it.

from icecast-kh.

yes is a bit strange also me thought at a bug at first time, but now it find it useful because i'm lazy and i used it to implement a mobile webradio using soundmanager2 that uses html5 audio() api, i can call it onpageload and this behaivor prevents my listeners from strange things when they open a new tab (the webradio also has some webpages for djs and they navigate it) anyway i know i can't rely only on this so i implmented also a cookie/localstorage state tracking for the player, but this is a strong layer of protection for me

from icecast-kh.