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:
#!/bin/sh ### BEGIN INIT INFO # 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. ### END INIT INFO USER=root HOME=/root export USER HOME case "$1" in start) echo "Starting GMediaRender" start-stop-daemon -x /usr/local/bin/gmediarender -c pi:audio -S -- -f 'Raspberry' -d ;; stop) echo "Stopping GMediaRender" start-stop-daemon -x /usr/local/bin/gmediarender -K ;; \*) echo "Usage: /etc/init.d/gmediarender {start\|stop}" exit 1 ;; esac 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:
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:
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
Comments powered by Disqus