First and foremost, Grant Potter rules! He spent almost a decade keeping ds106radio online without interruption, and in many ways we are simply trying to return the station to its former innovative harmony that Grant managed so graciously for years. So, Potter will always be the station manager as far as I’m concerned, but it also seemed like a good time to distribute the load a bit.
I have been getting requests about various features, which wasn’t necessarily a reason to move ds106radio to a new server. In fact, it’s been rock solid for a decade, which is something I can’t say about too many other technical systems I’ve been part of over the last decade. The real push for me were the “insecure site” errors on the /listen page people were reporting that will ultimately scare anyone new to the radio away. But the bigger reason was that the IceCast2 streaming server we were running was using the Airtime software for managing the internet radio side of things. As already mentioned, it has been remarkably reliable for years, but the open source version of this software has been abandoned for quite a few years now and it’s just a matter of time before the Ubuntu server we are running needs to be upgrade and this software will most likely prove incompatible going forward. So, we moved the management layer of the station to a more vibrant open source alternative called Azuracast that Taylor Jadin sold me on.
And like most open source software these days, Azuracast has a Docker container available that means it’s a perfect candidate to be moved to Reclaim Cloud. That’s two birds with one stone: another server off Linode (down to our last few now) and a fine excuse to push Reclaim Cloud 🙂 So, this was the week I decided to get ds106radio migrated, and I’m happy to report it went fairly smoothly. There was one annoying bit I will document for future reference, but in general I was pleasantly surprised. But before it all becomes ancient history and I forget what I did by Monday, I figured I would try and document the thinking and the process.
So, there was really only two pretty simple goals for the migration:
1) Make it seamless for folks trying to connect to the server to live broadcast their shows throughout the week. This means connecting to the server with the usual credentials the community currently shares
So, the default port for Azuracast needed to be 8010, the Mountpoint /live, and the username source.
2) The second thing was I needed to get the default stream for the station to pick-up WFMU when live DJs go offline.
That was it, if I could get those two things to work no one using the radio presently should be negatively effected by the move. And then we could work on rolling out some documentation to harness some of the features available through Azuracast.
So, to this end, I spun up an Azuracast environment on the cloud using this guide a very attractive gentleman labored endlessly over. This was the third time I’ve spun up Azuracast using Docker (previously reclaimrad.io and listen.strawboss.net), and it’s pretty easy. I do need to push myself and create a one-click installer for Reclaim Cloud, that is next week’s project. But now to the settings I changed to address the connection piece of the migration puzzle.
The AutoDJ for Azuracast is using LiquidSoap which allows me to customize the streamer port to 8010 and where I can customize broadcasting mountpoint to /live. This is accessed Edit Profile –> AutoDJ and you can change the settings.
What’s more, there is a field for buffer time of the stream which could prevent stream drift. I set the stream buffer to 30 seconds, and we’ll see how that holds up.
So, at this point I have the custom mount point and port, now I need the change the default username to source and the password to the one currently shared. Under Streamer/DJ Accounts section of Azuracast you can add user accounts or update the default. To keep the username and password the same as it was I simply updated the default broadcasting credentials:
Click edit and add the username and password combo you want, and you can even define the display name of the streamer:
As you might have deduced, rather than everyone sharing the same credentials, which can be simple, this feature now allows us to provide individualized accounts for any and all ds106radio streamers.
When I originally set up this Azuracast instance it was using the IP address of the server given I did not want to point the Ip address until I was sure I had the basics working. But once I did point an A record for the URL ds106rad.io to the new server IP the domain ds106rad.io could be used as the hostname for connecting. So, that means all the credentials used to connect to the old server now work on the new one. Disco!
Cross-casting the live stream from WFMU was the next task, and for some reason I made this more difficult than it should have been. It is pretty easy, if you go into the AutoDJ area and click on the Playlists button:
From there you can create a new Playlist, I called mine WFMU.
Once I create the playlist I can name it, and now much else to do, I have General Rotation selected, but not sure if it matters.
After saving changes, go to the Source tab and select Remote URL Playlist radio button and add the direct stream URL, for WFMU it is http://wfmu.org/wfmu_mp3.pls. I set the buffer to 15 seconds, though not necessarily for any reason.
Finally, in the Advanced tab I have nothing selected.
This will work as the default playlist when no one is live, but after I had everything setup I did run into issues with the streaming fading in and out. Turns out if you are broadcasting another stream I highly recommend turning off the Disable Crossfading in the station’s AutoDJ settings:
Turns out this feature, when pulling from a remote playlist, will cause the stream to fade in and out intermittently, almost like a pulsating, that was driving me crazy, and took me a few hours to hunt down.
After that, my two primary goals were accomplished, as a special treat I want to get the ds106radio intro bumper back up and running, and with Tim’s help I was able to get it working when stream starts using this guide https://www.azuracast.com/help/docker/#using-a-custom-default-track My recommendation to you, if you try this make sure the mp3 bitrate matches that of the station, for example the file we are using was 196 kbps, and it needed to be 128 kbps. The difference prevented it from playing, and not until we saved it as 128 kbps would this feature work. The following code with whaht I added to a docker-compose.override.yml file in order to update the container with the new link to the file.
version: '2.2'
services:
stations:
volumes:
- /var/azuracast/ds106minibumper.mp3:/usr/local/share/icecast/web/intro.mp3
The other piece is adding <intro>/intro.mp3</intro> to the ds106radio Mountpoint:
That worked!
Finally, folks were going to http://ds106rad.io/listen to find the player, given the way Azuracast works that was not going to be possible, so I setup a webpage with an embedded player and redirect the URL http://ds106rad.io/listen to https://listen.ds106rad.io. Like with adding the intro.mp3 file, I updated the Nginx file to redirect both ds106rad.io/listen and ds106rad.io/listen/ using this handy guide, which also had me overriding the docker compose file to add new lines of code to the nginx config file. The following two lines are what were added:
location ^~ /listen/ {
rewrite ^/listen/(.*) http://listen.ds106rad.io/$1 permanent;
}
location ^~ /listen {
rewrite ^/listen(.*) http://listen.ds106rad.io/$1 permanent;
}
With that ds106rad.io was ready to be pointed to the new server, and apart from the cross-fading issue, everything went as expected. Tim then dug right into getting some of the webhooks working so we could start sharing metadata on the new player and also update when DJs go live through Twitter. Fun stuff, and now that I got this documented I can figure out how Tim got the Twitter piece working and move on to documenting some useful features to help all those old and new radio friends to go live.
