Hi all,

So I feel I'm missing something quite obvious with this. I have a rudimentary stream in Centova Cast v3.2.12 set up with 6 MP3 files (songs) in the AutoDJ standard rotation, and one MP3 file in the station identification rotation. All other rotations/playlists are disabled for now. (The goal here is to get a bare bones stream going so that we can start connecting to it and running some tests... no public consumption of the stream for now.) I have shell access to the server, so I've been doing a "sudo /usr/local/centovacast/centovacast restart" after every change.

When I perform a start of the stream, the first icon confirms that my streaming server is online and operational. Second icon confirms that autoDJ is likewise online & operational. Third icon is where I fail: "Your server is currently online but there is no active source connection so no audio is being broadcast." Looking at the output of $CENTOVA_HOME (my stream home)/var/log/source.log, I see the following:

2020/07/13 01:06:35 [output_autodj:3] Connecting mount autodj for source@[IP redacted]...
2020/07/13 01:06:35 [output_autodj:2] Connection failed: 401, Authentication Required (HTTP/1.0)
2020/07/13 01:06:35 [output_autodj:3] Will try again in 3.00 sec.

...and so on. Source password under Settings->Stream matches what is in the source-password for the Icecast XML file, and so does administrator password. There are a few other things I am about to check (as I just thought of one possibility), but while I'm doing that, anyone have any ideas?

Looking at another thread (https://centova.com/forums/index.php?topic=6008.msg16356), and reflecting on what an HTTP 401 error actually means, I wonder if I need to configure Icecast for SSL? The Centova Cast client itself already is configured for SSL, as I needed to do that in order to make it compatible with my website backend.

I'll give that a try (when I'm not doing my day job  ) and report back the results.

Looking at another thread (https://centova.com/forums/index.php?topic=6008.msg16356), and reflecting on what an HTTP 401 error actually means, I wonder if I need to configure Icecast for SSL? The Centova Cast client itself already is configured for SSL, as I needed to do that in order to make it compatible with my website backend.

Progress, I guess? Now seeing the following:

2020/07/13 21:26:26 [output_autodj:3] Connecting mount autodj for source@[IP redacted]...
2020/07/13 21:26:26 [output_autodj:2] Connection failed: could not connect to host: Connection refused in connect()
2020/07/13 21:26:26 [output_autodj:3] Will try again in 3.00 sec.

I'm on the right track, it seems. Just need to figure out why Icecast is refusing the connection.

Looking at another thread (https://centova.com/forums/index.php?topic=6008.msg16356), and reflecting on what an HTTP 401 error actually means, I wonder if I need to configure Icecast for SSL? The Centova Cast client itself already is configured for SSL, as I needed to do that in order to make it compatible with my website backend.

Progress, I guess? Now seeing the following:

2020/07/13 21:26:26 [output_autodj:3] Connecting mount autodj for source@[IP redacted]...
2020/07/13 21:26:26 [output_autodj:2] Connection failed: could not connect to host: Connection refused in connect()
2020/07/13 21:26:26 [output_autodj:3] Will try again in 3.00 sec.

I'm on the right track, it seems. Just need to figure out why Icecast is refusing the connection.

I think I'm going about this completely backwards. Given the difficulty of configuring SSL for Icecast, I decided to scrap it altogether. I uninstalled Centova Cast and Icecast2, and am keeping my SSL cert (from Let's Encrypt). After a quick sanity check to reinstall Centova Cast with SSL already in place, I'm reinstalling once again, but this time with both Icecast2 and ices-cc. This way, not only am I forging onward with configuring Icecast with SSL working right out of the box, but I also have ices-cc as a backup option. Plus, I can test out ices-cc as well, which I kinda wanted to do anyway before my station launches.

Sorry this means I can't share any tricks for getting SSL working after installation, but maybe having it in place beforehand was the answer all along.

Last post I'll make on the topic, honest! 

So I did some research on this matter, and found that yes, indeed, Icecast does not ship with SSL support for Debian. I didn't want to believe that to be true, as I couldn't understand why Debian would continue to make available a package that, in my opinion anyway, is broken without SSL support. But honestly, it's not Debian's fault, they're just complying as best they can with what they understand the GNU Public License to permit and prohibit. This article goes into detail on why Debian cannot distribute a GPLv2 non-exempt binary (such as Icecast) with support for OpenSSL: https://people.gnome.org/~markmc/openssl-and-the-gpl

And yes, I realize there are workarounds, but I am of the opinion that HTTPS requests should be secured all the way to the backend, as mixed http/https warnings are a major turnoff for some people. (Especially if, as planned, I wind up selling merch on my site...) So off I go to compile Icecast from source, and I won't bother you fine people on this topic any longer.