The Dead Coder Society had its first meeting with our newest members. This meeting’s content was provided solely by the new members.
Peter Sandin was up first with his Debian Packaging presentation. He overviewed the process of packaging software in Debian and the various ways it can be done.
Tim Heckman followed Pete with two presentations. He discussed using Twilio, Python’s Flask web framework, and Python’s Paramiko library to interact with his network remotely from his cell phone. He also went over his IRC-related project to use Twilio to inform him of chat lines that interest him from irssi.
Nick Pegg continued the presentations by going over NickFM, a community-driven web radio project he has been working on. He combined Icecast, MPD, and custom Python code in order to create a digital station that allows for multiple remote DJs. Dead Coder Society member Brian O’Keefe posted a series on using Icecast for projects in the past as well: http://www.deadcodersociety.org/blog/building-a-streaming-radio-station-part-1-icecast-mpd-and-python/
Trevor Parker presented his idea of a pastebin-based system for decentralized, encrypted, and persistent message storing.
Les Aker brought the talks to a close with a presentation on Python’s sh module, which allows for system commands to be run in a pythonic fashion. The sh module integrates nicely with his soon-to-be finished automatic deployment system, Archer.
Cheers to the Dead Coder Society!
stk.fm in action
This is the final segment of my blog post about building a streaming radio station. Part 1 can be found here, and part 2 can be found here.
The station was just about ready to launch. Just one part was missing – analytics. It’s difficult to keep track of analytics for streaming audio simply due to the nature of the content. I couldn’t find an existing solution that fit my needs, so I built my own.
I was only majorly concerned with a few different metrics – namely, how many people were listening, what they listened to, and how long they listened. I added a new table to the MySQL database that the rest of the site had been running on to keep track of these metrics. In the player’s check-in process, I added an include for a script which would register analytics. This script would add or update a row for that particular session (identified by PHP session ID) which stored:
- Timestamps for the first and most recent check-ins
- The first and most recently listened to songs
- The number of seconds of music that were streamed
It wasn’t possible to derive the length of time the user was actually listening from the start and end times, as the player wouldn’t check in if the stream was paused. However, I of course knew that the player checked in every five seconds, so I could use this to get a fairly close approximation of how much audio was actually streamed.
Between now and the time that I started writing this series of blog posts, I unfortunately had to take stkbuzz down entirely. However, I do intend on making the previously mentioned Python script open source soon – I’d hate to see it go to waste!
This is a continuation of my blog post about building a streaming radio station – the first part can be found here. The first post was related to the server side aspects of the project. In this post, I’ll talk about the client-side player I built for stkbuzz.com.
Client Side – iframe hacks and jPlayer
With the Python script complete, the Icecast station was streaming and maintaining its own playlist – it could be streamed by pasting a link into your media player of choice. However, I wanted the station to be as accessible as possible. Ideally, there would be a persistent player embedded into the bottom of the website. Of course, the best way of accomplishing this is by building the website with this idea in mind, using AJAX to load new content without ever navigating away from the player. It was a little late for that, however.
Building the player itself was easy. I used jPlayer, a jQuery library that implements cross-browser audio streaming. It’ll attempt to use HTML5 to stream media if it is available; if it’s not, it can fall back to Flash. Fortunately, it works without a hitch with Icecast – just set Icecast’s MP3 mount point as the source media file.
Once the user hits the play button to start streaming audio, I had the player check in with the Icecast server every five seconds to grab the artist and title of the currently playing song (I used jCycle to build a ticker to display various information). Icecast doesn’t make it particularly easy to get the currently playing song’s metadata, but I wrote a few tiny PHP scripts that output the desired information by calling MPC. Part of the five second check-ins involved curling these scripts.
In the third and final post of this series, I’ll talk about how I implemented analytics for the station. Stay tuned!
I run an anonymous message board for Stockton College – stkbuzz.com. It’s fairly active, and due to the nature of the site, it gets some pretty amazing posts. I had the idea of recording dramatic readings of some select posts, but the problem was that I didn’t have a good way of delivering audio content to my audience. After bouncing some ideas off of my co-workers, I decided that the best way of doing so would be via an online streaming radio station, accessible from a player embedded into the bottom of the website – enter stk.fm, the Buzz.
Icecast and MPD
I researched my options for streaming audio in a radio-like fashion, and it seemed like Shoutcast and Icecast were the two most popular. After previously having a less-than-stellar experience with Shoutcast, I decided to give Icecast a shot. I’m happy to report that so far, it’s working great – I haven’t had a single problem with it yet.
I planned the “structure” of the content that would be played fairly early on. The structure looked something like this:
- An intro segment (sometimes known as a radio bump)
- A talk segment (such as a dramatic reading)
- Another bump
- Either one or two songs
This would obviously require a rather fine-grained level of control. The nice thing about Icecast is that it can use MPD as an audio source. MPD (Music Player Daemon) is, as the name might suggest, simply a daemon that plays music from a library. It doesn’t play music directly, however; it acts as a server which requires a client. In this case, Icecast is our client (this was incredibly easy to configure). Icecast streams whatever the source gives it, and since we can control MPD directly, we can essentially control Icecast directly.
The next step was to automate adding tracks to the MPD playlist. I wrote a Python script that acts as a DJ, playing tracks in the structure I originally settled on. The script does the following:
- First, it looks at a set of directories that I’ve specified and generates a “segment” for each MP3 it finds – a segment simply being an ordered list of MP3s that will be added to the MPD playlist. Typically, a segment will consist of a randomly chosen bump, followed by the content. However, I built in a simple regex check that looks at the filename of the content and can prepend or append specific bumps (for example, any filename that begins with the string “read_” is a dramatic reading, and should therefore always be prepended by the bump that says “and now, a dramatic reading…”).
- After the segments are generated, they are dumped into a pool with segments of their own type (talk or music) to be later pulled out and copied into the MPD playlist when MPD is playing the last song in the list (from within Python, I used MPC to interact with MPD). At that point, the segment is put into a queue and will be placed back into the pool of playable content after a certain number of other segments have been played (this allows for the content to be continuously shuffled).
Part 2 of this blog post will cover the client side player as well as streaming analytics. For now, you can check out stk.fm on stkbuzz.com!