Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Listening issue - Windows 7 Web browsers #11

Closed
silverkorn opened this issue Mar 8, 2017 · 8 comments
Closed

Listening issue - Windows 7 Web browsers #11

silverkorn opened this issue Mar 8, 2017 · 8 comments
Labels

Comments

@silverkorn
Copy link

Not sure if it's related with this issue #8 but listening to streams broadcasted by Icecast 2.4.2 is taking way too long before starting natively on any Web browsers on Windows 7. Note that audio players/tools such as FFplay and VLC works properly under this OS.

This issue doesn't seem to happen using an Icecast 2.4.0 (KH branch) server.

Thanks!

@ePirat
Copy link
Contributor

ePirat commented Mar 9, 2017

This is not an issue with Icecast but sounds a lot like configuration specific. Note that you can try to use a bigger burst on connect in the Icecast config (remember to increase the overall buffer too).

@ePirat
Copy link
Contributor

ePirat commented Mar 9, 2017

And no, this is completely unrelated to #8, as that is about sending content to Icecast.

@ePirat ePirat added the invalid label Mar 9, 2017
@ePirat
Copy link
Contributor

ePirat commented Mar 9, 2017

If it turns out that increasing burst will not help, please comment again here, and I'll have another look at it.

@silverkorn
Copy link
Author

This was already tested from 64k to 32k.
Did you have a chance to test on your end?

@ePirat
Copy link
Contributor

ePirat commented Mar 10, 2017

What do you mean by "from 64k to 32k"? That would be making the burst smaller, which is the wrong thing to do in this case, as you want a bigger buffer, so the browsers player buffer fills faster and playback starts faster.

@ePirat
Copy link
Contributor

ePirat commented Mar 10, 2017

And please provide a few more details:

  • Which format are you streaming in?
  • Which Bitrate or Quality?
  • Which web browser(s) did you try this with?
  • If possible, the url for the problematic stream

@silverkorn
Copy link
Author

Hmm... I thought that burst was about a buffering feature that by lowering it, it would start faster on the listener's end.

Unfortunately, the correlation that it worked properly on 2.4.0-kh and not on 2.4.2 with the same configuration file and this only happens on Windows 7 (SP1) OS, on any Web browsers (IE11, Chrome, Firerox).
Windows XP SP3 (Any browsers) and Windows 10 (Tested on Firefox & Chrome) were tested on 2.4.2 and it worked properly...

[Not working] Any server using Icecast 2.4.2 or 2.4.0
http://cyberjamz.com:8000/SV1.MP3 (audio/mpeg - 96kbps - 32000 Hz)
http://audio.telpin.com.ar/energy (audio/mpeg - 24 kbps - 22050 Hz)
http://icecast.omroepvenray.nl/lov.mp3 (audio/mpeg - 128 kbps - 44100 Hz)
http://bogo.audio:8000/asylumrock (audio/aacp - 96 kbps - 44100 Hz)
http://gnusocial.net:8000/tvelbinario.ogg (application/ogg - 80 kbps - 44100 Hz [Has video stream])

[Working] Any server using Icecast 2.4.0-kh#
http://streaming.megatopradio.com/megatopradio_autodj (audio/mpeg - 128 kbps - 44100 Hz)
http://netstream.lifeonline.fm/CJLF/128mp3 (audio/mpeg - 128 kbps - 44100 Hz)
http://icecast.wildghosts.com:8000/Christmas128 (audio/mpeg - 128 kbps - 44100 Hz)
http://filthybass.net/live1 (audio/mpeg - 112 kbps - 44100 Hz)

[Note] Any audio/aacp and audio/aac has the same reaction on 2.4.0-kh# than the 2.4.2/2.4.0 Icecast:
http://199.180.75.26/stream (audio/aacp - 64 kbps - 44100 Hz)
http://streams.olympia-radio.nl/olympia64 (audio/aac - 96 kbps - 32000 Hz)

At first I thought it would be because of the network but I tried on a direct access to the Internet without proxies/firewalls and the same behaviour happened.

As by relating the issue #8, I was guessing that it might be a problem through a HTTP header that Windows 7 SP1 might not operate properly under any browsers.

Hope this helps.
Thanks!

@ePirat
Copy link
Contributor

ePirat commented Mar 19, 2018

Closing this as I am unable to reproduce and so far this is the only report we got about this.
Note that neither MP3 nor AAC are officially supported formats so it could be that it works better in kh.

@ePirat ePirat closed this as completed Mar 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants