Multiroom RPi Music Server - Superstructure

Introduction

Previous blogs told the story of the Multiroom Music Server (muse) upto the point where music can be played throughout the house and controlled by various clients.  There is more to be done to make the system "multi-user", by which I mean that others in the house can and will use it.  Without a little bit of useability it will quickly become a relic.

System Startup

The components that need to be running at system startup are:
1 Share(s) to music folders on other systems need to be mounted
2 pulseaudio needs to be started - as user pi
3 ympd is started to allow web access/control on port 6800
4 bluetooth connection is made to the jongo
5 mpc play command is issued to start playlist if there is one.

Bluetooth and mpd services start automatically
Pulseaudio currently has to be started as user pi so some care would be necessary if this was automated.
MPD can access Samba/cifs shares if they have been defined on the host and a mount command has been issued at startup.
MPD can also access music via a web-site URL if it has been setup.  I have made albums available through shares.  Rplay, my internet personal music player, accesses music through the RPIP web-site so Rplay playlists coopied into MPD contain web URLs which MPD can use to obtain music over the network.

Bluetooth Connection

My RPi version 3 (PI3) connects to bluetooth quite reliably using the in-built bluetooth adapter.  However it disconnects from a Jongo after about 10 minutes activity so will not be always available.  Clearly we don't want our users to have to ssh into the server to start bluetooth.
The easiest way to start up bluetooth is to run a CGI script from RPI3 web-site which does a bluetooth connection with the utility bluetoothctl.  Similarly to check the bluetooth status from the webpage we can use the bluetoothctl info command.
Pulseaudio should be running before bluetooth is started so that can see the new bluetooth device as a "sink".

bluetoothctl is a good utility, intended for command line use, which provides the functions you require to manage connections.  As a one-off you need to pair with a device and make it trusted. At any stage you can use the info command to obtain status for a device.  The connect and disconnect are used to link/unlink a device. Tab is very useful on the bluetoothctl command line to complete mac addresses or commands.  Two formats used in scripts to pipe input in are shown below:
echo -e "info $jongoAdr\nquit" | bluetoothctl
and
bluetoothctl << EOF >/dev/null
power on
agent on
default-agent
disconnect 00:15:83:6B:38:93
quit
EOF

URLs

Music Server Web based functions should only be used within the local network so utilise local IP addresses.  To provide easy access we have a public DNS name music.helliwell.org which works anywhere.
The main option provided is access to the ympd program running on PI3.  It may be useful for this to have its own public DNS.
For the sysadmin the most useful option is to to control the application on server PI3.  Shell scripts can obtain information on whether pulseaudio, bluetooth and MPD are running.  I use lighttpd which runs as user www-data.  This is able to switch bluetooth functions but cannot easily start pulseaudio (pi user) or MPD (mpd user).  For the moment the screen allows me to check whether pulseaudio and bluetooth are running and, if pulseaudio is active but bluetooth is not I can start bluetooth.  MPD shows results of status command.  Screen refresh every 5 seconds confirms whether start/stop bluetooth commands are successful.
A third Music Server option is provided allowing you to access MPD port 8000.  This streams music directly to your device as opposed to sending it to bluetooth speakers.
An instruction page has also been included for those keen enough to install client apps on Windows, IoS or Android.  You need to know the music server IP (192.168.0.33) and port address (6600) to be able to do this.  There is also a learning curve to use the clients, eg to find and play albums, to find radio stations amongst the playlists.

Music

Albums are stored on rpip and accessed via a samba share rpipmusic.  Within client apps they can be browsed through artist or file-system lists.  Generally you want to play an entire album.
Some streaming radio stations, notably capital, absolute, BBC 4, absolute 70s and absolute 80s have been setup up as playlists which are accessible with names ending in _radio.

Rplay

Rplay is my music playing app based on streamripper which divides the stream into individual songs and stores them on disk.  Files are labelled with the track name (transmitted in the stream).  My scripts takes these tracks, removes advertisement breaks (which have different names) and creates track name and location lists.  These are then inserted into the Rplay web page and can be controlled by the user.
Rplay was designed to work in a browser on a device, it resides on rpip is accessible externally so can be used on a train, at the gym etc (providing you have wifi or enough data).
I amended Rplay so each playlist has an M3U file containing track information.  This is passed to PI3  (there is a copy each time PI3 is started using playlistupdate.sh) and the playlists are available to select in MPD client playlists.  MPD loads tracks as web URLs like Rplay.