Tag: RPi

My Raspberry Pi-based streaming radio player generally worked fine, except sometimes the keypad / volume control knob would stop responding after switching streams. This being an erratic thing, the error had to be a timing problem in otherwise correct code and, after spending Quality Time with the Python subprocess and select doc, I decided I was abusing mplayer’s stdin and stdout pipes.

This iteration registers mplayer’s stdout pipe as Yet Another select.poll() Polling Object, so that the main loop can respond whenever a complete line arrives. Starting mplayer in quiet mode reduces the tonnage of stdout text, at the cost of losing the streaming status that I really couldn’t do anything with, and eliminates the occasional stalls when mplayer (apparently) dies in the middle of a line.

The code kills and restarts mplayer whenever it detects an EOF or stream cutoff. That works most of the time, but a persistent server or network failure can still send the code into a sulk. Manually selecting a different stream (after we eventually notice the silence) generally sets things right, mainly by whacking mplayer upside the head; it’s good enough.

It seems I inadvertently invented streaming ad suppression by muting (most of) the tracks that produced weird audio effects. Given that the “radio stations” still get paid for sending ads to me, I’m not actually cheating anybody out of their revenue: I’ve just automated our trips to the volume control knob. The audio goes silent for a few seconds (or, sheesh, a few minutes) , blatting a second or two of ad noise around the gap to remind us of what we’re missing; given the prevalence of National Forest Service PSAs, the audio ad market must be a horrific wasteland.

The Python source code as a GitHub Gist:

The latest version of my simpleminded streaming radio player includes:

• More durable parsing for track titles with embedded quotes and semicolons
• Muting during empty / non-music Radionomy tracks
• The Dutchess County E911 service

Audionomy’s empty / non-music tracks include a remarkable number of mis-encoded MP3 sections triggering decoding problems; those problems don’t occur during music tracks. Some tracks come through as advertisements, which would be mostly OK apart from the garbled / high-volume gibberish, but on the whole they’re un-listenable:

ICY Info: StreamTitle='';
A:1271.0 (21:10.9) of 0.0 (00.0)  4.0% 44%
[mp3float @ 0x7623e080]overread, skip -7 enddists: -5 -5
[mp3float @ 0x7623e080]overread, skip -9 enddists: -6 -6
A:1271.2 (21:11.2) of 0.0 (00.0)  4.0% 45%
[mp3float @ 0x7623e080]overread, skip -7 enddists: -5 -5
A:1309.1 (21:49.1) of 0.0 (00.0)  4.0% 42%
ICY Info: StreamTitle='Targetspot - TargetSpot';
A:1316.4 (21:56.4) of 0.0 (00.0)  4.0% 40%
[mp3float @ 0x7623e080]overread, skip -5 enddists: -4 -4
[mp3float @ 0x7623e080]overread, skip -5 enddists: -2 -2

Muting happens in the mixer, because that seems easier than messing with mplayer in mid-flight. Rather than attempt to control the muted state with specific timeouts, I just un-mute after a new track title arrives; that has no effect if it’s already un-muted. The delays depend on the buffer fill level and avoid the worst of the gibberish.

The player still falls over dead / jams solid on occasion, generally because the incoming data has stopped streaming or delivered severe encoding problems. Other than that, it runs pretty much all day, every day, on at least one of the Raspberry Pi streamers.

Still no track display. Mostly, we still don’t miss it.

The Python source code as a GitHub Gist:

With three identical Raspberry Pi streaming players tootling around the house, it finally dawned on me that they should fetch their Python program directly from The Definitive Source, rather than a local copy.

Tweak the auto-startup in /etc/rc.local:

mount -o ro mollusk:/mnt/bulkdata/Project\ Files/Streaming\ Media\ Player/Firmware/ /mnt/part
sudo -u pi python /mnt/part/Streamer.py &

There’s probably a way to redirect all of the stdout and stderr results to a file for debugging, but the obvious method doesn’t work:

sudo -u pi sh -c "python /mnt/part/Streamer.py 2>&1 > /tmp/st.log" &

That redirects stdout from the subprocess call to set up the mixer, but doesn’t catch Python’s print output.

Using the Python logging library would get most of the way to the goal, although stdout from things like the mixer would still vanish.

Continuing with the network theme, one could netboot the RPi players, but that requires more sysadmin hackery than I’m willing to do, what with the good being the enemy of the best.