Making gmediarender start on boot

Posted in Posted on 2013-01-02 20:13

Now gmediarender is compiled and gstreamer works on the Raspberry Pi we need to get it all to start on boot.

Fairly standard stuff here (copied from Malte's post in Chris' blog). Create a file /etc/init.d/gmediarenderer with the following contents:


# Provides: gmediarender
# Required-Start: $remote\_fs $syslog
# Required-Stop: $remote\_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start GMediaRender at boot time
# Description: Start GMediaRender at boot time.

export USER HOME
case "$1" in
echo "Starting GMediaRender"
start-stop-daemon -x /usr/local/bin/gmediarender -c pi:audio -S -- -f
'Raspberry' -d
echo "Stopping GMediaRender"
start-stop-daemon -x /usr/local/bin/gmediarender -K
echo "Usage: /etc/init.d/gmediarender {start\|stop}"
exit 1
exit 0

Then do:

$ sudo chmod 755 /etc/init.d/gmediarenderer
$ sudo update-rc.d gmediarenderer defaults

to make the script executable and add in all the symbolic links from the /etc/rc.x directories.

You can then do sudo service gmediarenderer start to run gmediarenderer as a daemon there and then or reboot and it will start automatically. Interestingly, I tried it without the -c pi:audio so that the daemon ran as root and the sound quality went bad again. Fine running as the "pi" user though.

In summary, we now have:

  1. minidlna running on the media server (a nettop linux box behind the sofa);
  2. gmedia-resurrected running on the Raspberry Pi to play the music through the mini Hi-Fi;
  3. bubbleupnp on multiple Android phones to control the music choice.

This is a pretty good solution but has some problems caused by the playlist being held on the controller (one of the phones). So if one of us sets an album playing and then goes out, the Pi doesn't receive the instruction to play the next song. If you look at a second controller then you cannot see what is playing (it may think something else is), but on the plus side, the volume controls work on all controllers and the play/pause does as well.

These problems are known of course, and the BubbleUPnP author has another piece of software called BubbleUPnPServer which is an OpenHome renderer. As the site says:

An OpenHome Renderer has the following advantages over a regular UPnP AV renderer:

  • each OpenHome renderer has its own playlist
  • no need to leave the Control Point running for playlist track advance to happen
  • several OpenHome Control Points (BubbleUPnP, Linn Kinsky) can be connected to the same renderer simultaneously, showing the same playlist and playback state
  • create a playing playlist on a device and pick it up later on another device

It looks as though the BubbleUPnPServer basically adds another, persistent and stateful, layer to the system so that an OpenHome controller (such as BubbleUPnP) tells BubbleUPnPServer what to play and it then tells the existing (plain) UPnP renderer what to do. Hopefully I can get this working on the same linux box as minidlna is running on.


Comments powered by Disqus