RogerBW's Blog

I've been improving the ways people can get access to the local music server during my barbecues and similar events.

I was already running mpd, the Music Player Daemon, which is a server that separates the process of controlling what's played from the actual production of sound. This is controlled by a pleasantly text-like protocol over a TCP port (there are lots of clients available), and it copes well with cataloguing nearly a million audio files with a total play time of over four years, even if it does insist on calling them "songs" when they might be audio books, radio programmes, sound effects, etc.

I've written a command-line client to do things like switching tracks, clearing the queue, and so on, because it's quicker to type "mp stop" than to load up an interactive program and then tell it what to do. (And I can set a command-line program to run at a particular time – for example, "stop whatever else may be playing, then play the alarm noise".)

The first improvement to the mpd setup was that it had been feeding an icecast2 (streaming MP3) server, but it can now generate an MP3 stream directly. So that's an awkward piece of software removed from the chain (it's intended for more complicated jobs than this one), less buffering, and fewer potential security problems.

Some time ago I write a basic web interface to mpd called yokosou, because all the web-based clients I could find at the time needed dodgy server configuration or PHP (which I regard as a special case of dodgy server configuration). It's designed to be extremely lightweight rather than pretty, but since nobody except me has ever taken advantage of that (e.g. by driving the server from an ebook's basic browser), I've now replaced this with Bragi-MPD on a virtual host, which is more functional and much more pretty.

That client had a secondary function of controlling a daemon to keep the music queue filled, and I've now rewritten that daemon from scratch as a stand-alone program; a particular problem was that, if the daemon had filled the queue, people's requests for particular tracks would be delayed until all those songs had been played. That's been fixed; the new daemon keeps track of which songs it has added to the playlist itself (by using their playlist ID, which should be unique as long as mpd doesn't restart), and if any other songs appear after them, it'll delete them and re-add them at the end. (It also tries to choose songs off its internal playlist that are unlike the ones currently in the queue or recently played, based on similarity of filename.)

And lastly… I've set up multiple channels, which means multiple instances of mpd running on different ports. So I can have a set of speakers by my bed (and I do, driven by a Raspberry Pi) that's not playing the same thing as the main channel (which a guest might be listening to in their room). A small periodic job takes care of restarting the various mpd instances when one of them has updated its database, so that they all run off the most recent data without having to update each one separately. (This is is an interesting exercise in designing program flow: check the last update time for each of them, aborting the process if any of them is currently updating; then restart anything with a last update older than the most recent one, except for ones that are currently playing because you don't want to interrupt the audio stream.)

Now all I need to do is to find a use for "stickers" (a way of attaching persistent data to an audio file, accessible to any mpd client). It seems as though it should be a really useful feature, but…

I've cleaned these tools up a bit and uploaded them to github.

Actually all this started because the MP3 player I was using at the time didn't have a command for "keep playing to the end of the current track, but then stop". If I have some music on while I'm working on something, but then I finish the thing, I don't want to cut the music off in mid-stream… which seems kind of obvious to me but apparently it's not a usual thing to want. Then I got the Touchpad, which could only play MP3 and some proprietary formats, so a streaming server seemed like a good idea…