After several frustrations with the baroque arrangement of icecast 1.x, icecast 2.x, wget, madplay, obsequium, ices, and daemontools, I decided to replumb things to make them a wee bit simpler. The radio pipeline did a reasonably good job of managing playlists, and reencoding the stream to ogg to preserve bandwidth, but it wasn't playing well with proxies. In the time since I had _last_ done all of this, the good folk at xiph:http://www.icecast.org have released icecast 2.0, 2.0.1, 2.1.0, 2.2.0, and ices 2.0. This was an opportune time to reduce the complexity of the radio pipeline. With a little bit of hacking, I managed to get obs to talking directly to the icecast 2.2.0 server, which eliminated the need for the icecast 1.x server. A bit more script hacking and everything was up and running again. Icecast 2.2.x introduces bursting, which makes me happy. No more waiting for the 64kiB buffer on your player to fill up. Icecast keeps enough data around to fill the players buffer in a burst on connection. This means the music starts instantly instead of after 8s econds. The only outstanding issue is that the pipeline is now almost 5 minutes long. Somewhere, something has got about 5 minutes of music in a buffer. When obs starts feeding another track to the icecast server, it takes about 5 minutes before that track comes out the business end of the icecast server. I am begining to suspect the problem lies in my quick, cheesy, clueless hacks to the obs worker thread. The obs scheduling thread probably has a slightly different idea of how long it takes to stream out the tracks than shoutcast takes to do it. I suspect this will lead to me eventually retiring obs, after 4 years of service, and replacing it with a markov chainer that uses data from audioscrobbler:http://www.audioscrobbler.com, and musicbrains:http://musicbrainz.org . More on that later...