Icecast stream via default port

[gammaw]

We have an issue that some users cannot listen to our radio from behind wrongly-configured firewalls. It seems that those firewalls block traffic via custom ports e.g. domain.com:8000. In the nowplaying API the listener URL uses port 8000 e.g. domain.com:8000/radio.mp3. On the admin page I see that the stream is also available via domain.com/radio/8000/radio.mp3. Why does the nowplaying API contain this URL? What's wrong with it? Wouldn't it help avoiding firewall issues with non-default ports?

[gammaw]

Just found that the "Use Web Proxy for Radio" option would do exactly this. What could be the reason to go with the default option where a station broadcast on its own port (domain.com:8000)? You say "If you're using a service like CloudFlare or accessing your radio station by SSL". Why would SSL disable the default way (domain.com:8000)? We had HTTPS sites and it worked fine. Thanks for any explanation!

[BusterNeece]

To answer your questions: connecting directly to the broadcasting server listening on its own dedicated port will always be slightly faster, easier on your server, and able to scale more easily than going through our nginx port 80/443 proxy. That's why we tend to try to use that as a default. We've been able to optimize the nginx proxy to have a minimal impact on the server, but it's still nonzero, and Icecast/SHOUTcast specifically recommend avoiding using proxies like that.

As for the SSL issue, it's only a fairly new thing that we implemented SSL support in Icecast using the same certificate that the web server was using. SHOUTcast doesn't have this option at all, so if you're using SSL and want to be able to flop back and forth between frontends more easily, the more reliable option is to just enable the proxy.

[gammaw]

@SlvrEagle23 thanks! I understand the performance issue. But I still don't fully understand the SSL one. What feature exactly did you implement recently? Ever since we launched the radio in late 2018 we use a HTTPS connection to Icecast, something like this: https://www.domain.com:8000/radio.mp3. So no proxying. This is the URL we embed in our frontend, which is another HTTPS site. We need HTTPS on the Icecast side so that we don't have a cross-origin issue. What changed now? The reason we're thinking of changing the URL (to a proxied one) because some users have firewall issues and we would hope that it solves them.

[BusterNeece]

@gammaw Sorry, "recent" to me means within 2018. This project's really old to me. Don't take me too literally when I say these things.

Hopefully that answers your question as to why it's set up the way it is, though. I don't know if there's any other information I can provide.

[machetedj]

Ok you proxied the urls but now that cause some issue with external player and the metadata(not show song title and image), you should give an option to change the way you want display urls in admin panel,

[BusterNeece]

@machetedj That is exactly what that "Use Web Proxy" option is. The proxy and direct port connections are both always available regardless of that setting; that setting controls whether your URLs on AzuraCast pages and players use that proxy or not.

[machetedj]

ok i have disabled Use Web Proxy for Radio and still not working the metadata on external players

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[joysarkar786]

Someone please give it to me azuracast now-playing.php

[joysarkar786]

Someone tell me, please How will I use it azuracast now playing api. plz also send full project.