Monday 24 December 2018

Christmas lights

Christmas lights are perfect partners for a Raspberry Pi at this time of year.  For those who are interested lightshowpi.org have developed an exceptional application to synchronise lights with (festive) music from a Raspberry Pi.  Software analyses music and depending on predominant frequencies (eg low, mid and high frequencies) and sends associated signals to GPIO pins so that lights can be turned on and off in time with the music.
Many people use Lightshowpi for outside lights, I don't have the facilities for outdoor music so I prefer to synchronise lights to music in my home.  Previously I haven't had much luck in getting a result I am happy with, but this year everything has fitted together nicely.

To start with I play music using MPD (Music Player Daemon) on my RPI 3B.  It deals with playlists, internet radio streams and music from NAS so that I can listen to what I want.  I use bluetooth speakers  so I dont need RPI next to the speakers and I don't need a cable from the RPI jack plug.

I configure MPD so that it creates a stream output on port 8000 and listen to that port in lightshowpi.  The software then does its magic and analyses the music.

For indoor use 5050 LED strips are perfect as a lighting display.  They have 3 wires controlling red, green and blue LEDs and work off 12V.
I tell lightshowpi that I am using 3 GPIO pins for output and connect the 3 pins to MOSFETs which raise the voltage to 12V output to drive RGB wires.
My bluetooth speakers have about a 2.7 second delay which I can program in to lightshowpi and I find that when I play music it is beautifully synchronised.

Monday 17 September 2018

Floureon Pan Tilt IP Camera

Why?

A floureon Pan Tilt wifi ipcam only costs £20 on eBay.  I was intrigued whether it would be any good and whether I could control it from RPi based software.  It echoes my first linux project challenge from 2002 when I had a logitech webcam controlled by an Eagle Pan Tilt mechanism and used it at work to see whether my program to turn a  home light on and off was working.
I am not sure what I would use this for - I think I will just experiment with it and see what I can make it do.

Installation

A short but helpful pamphlet tells you how to set up the webcam.  You download the CamHi app to an iPad or Android device first.  You then add a camera.  The install procedure can find the webcam through wifi and you then put your phone next to the camera and it has an audio hand-shaking procedure to link the app with the phone - it sounds somewhat like old modems talking to eachother.
The app shows you a webcam feed and you can swipe up / down / left / right to move it - however it is very ungainly.

Documentation on the floureon website is rather sparse but contains useful info on features.
Motion tracking, IR and two-way sound all should be investigated.  It says that the movement controls have no lag but that was not my experience.  
It says that the windows client is CMS software.  I downloaded what seemed the appropriate software from the website but I couldn't get either utility, DeviceViewer or SriCam, to see the web cam.

There is an option to check for firmware upgrades, so I upgraded firmware.

Extra Software

I looked briefly at ISpyConnect to see if that would work on windows.  It has some good documentation and I managed to get the URL rtsp://hostname:554/11 to view the video feed.  It seemed a bit cumbersome to use so I installed a nice utility anycam instead.  I could also see the video feed using vlc with this url.

Other URLs which work are rtsp://hostname:554/1/h264major (in VLC) and http://hostname/tmpfs/auto.jpg in Chrome.  The directory tmpfd/* is visible in chrome but doesn't have much of interest in it.  However it does confirm that the webcam contains an embedded linux server.

In fact I found that http://hostname/ gives access to an inbuilt webserver and also allows pan / tilt control.  The buttons remain pressed whilst you click down on them.  Unfortunately there is a 2 second lag on the picture update so it isn't practical to adjust the camera this way.  However there are 8 presets which can be used to set positions and you then "call" them.  In practice this should be enough.

Using Chrome Developer tools you can look at the programs used on the webserver.  I managed to copy all the files I could find down to a Windows folder to see whether they would work locally.    The server uses flash to show video in the browser and I couldn't (easily) get flash to work locally on my Windows PC running video from the IPCAM.  However I did see that the site is written in html/css/javascript.
In particular the commands to control the webcam work through cgi.  Thus I can move the camera left a bit using http://hostname/cgi-bin/hi3510/ptzctrl.cgi?-step=1&-act=left.  This would allow me to set up webcam control very easily.  Googling hi3510 gave me a list of commands that can be used.

Verdict

The camera gives a very nice picture but the lag is quite irritating when you are in the same room.  It would be simple to setup a web page to control the camera and keep the image in a separate session in vlc or anycam.
It would also be easy to setup periodic room scans.
It is also an amazing package a pan-tilt camera accessed via in built webserver for £20.


Tuesday 11 September 2018

NODEMCU ESP8266 plus OLED

Introduction

I was looking to buy some more ESP8266 boards and my attention was attracted by an ESP8266 ESP-12F NODEMCU Wemos Development Board CP2102 + 0.96” OLED for £5.50. This looked to be an ESP8266 with a small OLED display.  I have noticed NODEMCU and Lua before and thought I would try it out.  There is a great attraction in having a display on your MCU rather than arsing around with LEDs all the time.
A quick investigation told me that NODEMCU is firmware written to allow eLua programs to be loaded onto ESP8266 boards.  Lua is a language developed in Brazil as a small, fast, simple interpreter which is suitable for embedded systems.  It is written in ANSI C and has a C API, programs are compiled into bytecode then run on a processor.
In fact the nodemcu firmware is compatible with the Arduino IDE so you can write Arduino ESP8266 sketches and run them on a the board.
The other nice feature of the development board is that I don’t have to press reset / flash buttons to load programs.  This saves a huge amount of irritation.

Installation

The board plugs directly into my PC and is visible to the Arduino IDE.  It is a standard ESP-12F so you use GPIO2 for the blink program.  I found a suitable OLED library on github and only needed to change SDA(D1) and SCL(D2) to run the demo program.

The verdict is that this is amazing, a wifi enabled arduino with a screen for less than £6.

HTTPS

Now that Google puts "not secure" against http:// web-sites there is an incentive to move to https.  I thought it might require significant technical work or money but it turned out to be quite simple and free.
Firstly you need a web server.  In my case this was an RPI running lighttpd and accessible on t'internet via port forwarding.
Secondly you need a certificate.  These can cost money by letsencrypt provides free certificates which are suitable.
You need certain application software on RPI, I am using Raspbian Stretch which has all the necessary pre-requisites so I just needed to install certbot.
Now you just need to retrieve the certificate from letsencrypt.com using certbot and configure lighttpd and your firewall to use port 443.
https URLs now work which means you no longer have to look at "not secure" messages.
Altogether a very pleasant experience :)

Saturday 14 July 2018

MuSe usability improvements

Introduction

Although MuSe was in a useable state there were may aspects which were inconvenient to use or counter-intuitive.  Updates were made, mainly to html/css/javascript, to provide a solution that is better and easier to use than other clients.  Problem/objectives and solutions are outlined below, roughly in the order of implementation.

1 Group related functions together

Choice of radio station, ambient background, pre-defined playlist and NoAd radio are broadly similar and were grouped together, initially in a <div> with a border.  Similarly buttons (e.g. play, pause, next) and presets (e.g. Passenger Playlist, start Absolute radio) were grouped.
Album selection was contained in its own group and, at the bottom of the page all the useful options / information for development/diagnosis was kept sepater.
At the top of the page the current status of whether MuSe was connected and playing are shown followed by the current track artist and title.

2 Update bluetooth status information

In the status section "connected" or "NOT connected" show whether bluetooth has been started.  It takes a few seconds for start or stop bluetooth to complete.  After the start / stop command was issued setTimeOut() function was used to wait 5 seconds and refresh the screen so that the status remained upto date.
A refresh button is also available for the user so that the screen can be refreshed at will.  For example if the MuSe browser tab was hidden and is then displayed a screen update needs to be completed.

3 Time Conversion

Initially elapsed time was shown in seconds JS functions were used to convert to minutes and seconds.  Time is only available for album tracks, it was left blank for playlists and streaming radio.

4 Album choice

The initial display of albums provided no .

5 Move groups into tabs

The screen layout for smartphone use was small, cluttered and hard to use.  Javascript tabs were implemented so that the bottom half of the screen could show:
a) current play queue
b) radio station, ambient background or playlists
c) NoAd radio playlists
d) Album selection
e) Diagnosis section

6 Change select boxes

MPD.js initially populated the selection boxes for play queue and playlist selection with select multiple statements.  These looked fine on Chrome(PC) with the size= parameter showing say 5 itmes in the list.  However for mobile devices the select statement comes out as a single line which provides a dropdown box when you click on it.  Initially I looked for a solution which makes apps appear similar on different devices, then I investigated jquery apps which might do a better job.  There didn't seem to be anything sensible, which I found a bit surprising.  Eventually I replaced the selection boxes with div statements in a box.  I could choose a box of any size quite easily.
The <div> box had an onclick command for each option and it was difficult to work out how to request a specific playlist or track to load.  I used the console.log to narrow down the solution.  In fact I had to slightly modify playSong and loadPlaylist to make them work and make the correct requests from the MPD backend.

7 fit to phone screen

There is no real benefit to using the expanse of a PC large screen as the MuSe webpage will be mostly used to control the system from a phone / tablet.  Consequently I limited the page size to 360hx560w so that it fits nicely on my Samsung S5.  This looks ok on both iPad and PC chrome screen.

8 show source at top

It can be difficult to know exactly what is playing, a track could be on the radio,  in a playlist or on an album.  MPC doesn't provide a command to tell you whether you are streaming, on an http playlist or loading locally.
I provided a simple JS function which uses the websocketd interface to run a script called source.sh which creates a file on PI3.  The function provides a parameter describing what is running which is written to the file.  When the source is changed the function is invoked.  When the screen is refreshed the file is read using w3.js includeHTML() function to read the contents of the file.

9 Make buttons like keypad

Initially the spacing of buttons was left fluid so that browsers could have as many on each line as would fit.  This began to look a bit untidy so it made more sense to put buttons and presets in a fixed layout.  Ideally we would have four buttons per row, like the keypad, but there is only really room for 3 so we had the numerics followed by * 0 # followed by A, B, C.


Saturday 9 June 2018

MuSe - Simple as a button

To become part of everyday life the Multi-room Music Server (MuSe) needs to be easy and friendly.
We have been working towards this at each stage of the project and by now we can do everything we want  to control music using one tool or another.  Ipad / android apps allow albums or streams to be played, a web interface is available for those who prefer it and a customised web app allows radio stations to be loaded easily.  Server status and startup can be done through a web interface.
All these tools require an app or browser running on a phone, tablet or PC.  A lot of the time this is exactly what is required and is not inconvenient.  However sometimes we want something more akin to a remote control.  It will have limited simple functions to do things like skip the current track or pause playback.

Button logical design

We envisage a button or buttons , operated by battery, which can be used in any room for specific pre-defined functions.
A screen / LCD should not be required as functionality will be simple and phone / tablet can be used for more complex actions.
Wifi connectivity should be used to allow the flexibility of using the button anywhere in the house.

To communicate with the RPI mpd server we could program C sockets, use http/cgi or utilise the websocket capability previously implemented for server control.  The type of information sent across would be mpc commands or perhaps bluetooth start / stop.  It would be nice to get a response back to the button to confirm success/failure.

Physical design

Two wifi enabled processors spring to mind, a Raspberry Pi Zero or an Arduino ESP8266.  As we only require simple functions the ESP8266 is the preferred way forward.
An Arduino websocket library is available which works with the ESP8266 so it should be possible for 2-way communication from an ESP8266 button to the websocket port.  Scripts on the RPI server can then process a button command and carry out the function on RPi.
We may find a number of buttons useful, we can easily have as many as there are free GPIO pins (about 8) on an ESP8266.  We use an ESP8266 "vertical" breakout board which mounts the ESP8266 on a small board with pins for all the available GPIO pins.
Pull up resisters are used so that when a button is pressed the GPIO pin goes from HI to LOW.
For programming, implementation and testing it is helpful to have Reset (RST) and Flash (GPIO0) buttons and FTDI connections.
Battery power can be provided by 2 or 3 AA cells plus a switch.

Our ESP8266 design is simple, we connect up to an FTDI232  on a breadboard and provide RST, FLSH buttons.  This basic setup allows us to download and run programs on the ESP.  ESP GPIO2 can be used to flash an LED, indispensible for testing.  We add a button on GPIO16; a pull-up 10K resistor keeps the pin high and the button grounds it when pressed.
The ESP8266 raw pin is used connected to +4.5V battery so that the ESP button can be used without FTDI connected.

Programming

I chose websocket library from links2004 which seems to work very well. We only need a websocket client as the server has been previously setup using websocketd.  A specific ESP8266 example is provided so we just need to enter wifi and URL/port details.  After flashing to the ESP8266 the program successfully communicates with websocketd on RPi.
It is now straightforward to program a button so that it causes websocket.sendTXT to send a command "mpc next" to websocketd which then handles it in a script called mpc.sh and sends mpc next to mpd and changes track.
Care is needed to ensure the command isn't sent repeatedly.  I used an LED indicator to show when the command has been sent so the button can be released appropriately.

Keypad

As an upgrade to buttons a keypad provides extra functionality / flexibility.  Buttons are adequate for basic connection, play/pause, skip but it is also useful to have various presets, e.g. to choose a specific channel or playlist.
A 4x4 touch keypad only costs about £2 and an arduino keypad library is available so that it can be easily programmed.  The keypad just has 4 row pins and 4 column pins so you just connect 8 GPIO pins, configure a basic keypad sketch and you can then use it.  Initially I tested with a Uno using a simple hackster tutorial and then moved on to the ESP8266.
The options are also made available on the web app where they can be tested first.  Keys 1,2,3 should be the same as the 3 buttons so that both solutions can be implemented - we may want a button control or keypad in each room.

Wednesday 9 May 2018

Multiroom RPi Music Server Added Functionality

Introduction

The two previous posts have tallked about design/installation and configuration for the Multiroom Server (MRS).  All the main pieces are in place for a working system but it isn't easy to start the system up or use it exactly as you want.  This post tries goes through steps to take it from a working prototype to a solution for daily use.
It also includes extra features which can be used to expand MRS functionality.

Controlling MRS environment through the web

websocketd

A previous post described ympd which allows you to view and update music being played via the web.  A page was setup to monitor bluetooth, pulseaudio and mpd tasks running on RPi server.  Using the lighttpd application it was possible to start bluetooth but not easy to manage pulseaudio or MPD.  A lovely general purpose linux app called websocketd from Joe Walnes provides a web-socket interface for any linux application (e.g. python, C, bash).
It runs as a single executable which opens a linux port and passes data to and from an associated linux program.  For my purposes I setup port 8080  communicating with a bash script webmrs.sh.  In a JavaScript webpage a user opens a web socket ws://PI3:8080.  Links within the webpage cause data to be sent to the socket.  This data is passed via websocketd to webmrs.sh which looks at it to determine which script to call.  Any output from the script is sent back to the web page for display or processing.
For testing we can run scripts locally as user pi.  We can then associate a script with the daemon starting websocketd as user pi.  There is a high likelihood that the script will work in the same way which is different from lighttpd cgi scripts that run as user www-data.  User pi also has the sudoers capability so sudo can be inserted in scripts to use system functions.  Finally the daemon can be added to startup to run as user pi (which is required for pulseaudio control).




Web programming interface

Demo program

MPD clients are available to control our music from phone, ipad, Windows and web browsers.  If we want our own tailored interface we need tools so that we can write programs which communicate over the LAN with RPi.  MPD.js provides exactly that functionality.  You build a webpage using JavaScript, html, css as normal and MPD.js provides you with functions interrogate MPD about its setup and status and control MPD in the same way as other clients.
On the server MPD doesn't provide a capability to communicate via web sockets and a python program call websockify runs on PI3 listen on port 8800 and pass any information to /from the MPD port 6600.  It is a beautifully elegant solution, which can work for other applications as well.
A test program is provided by bobboau to show how MPD.js works.  As suggested I started a simple web server on PI3 port 8001 as user pi with python -m SimpleHTTPServer 8001 and put the demo application folder plus mpd.js in /home/pi/html.  Accessing port 8001 from a browser provided me with a /home/pi directory and I was able to run demo/index.html to view / control MPD.

Debugging

Initially playlist functionality didn't work on the demo app so I needed to dig into the code a bit.  The application is written in html, javascript and jquery.  Two js include files (websock and util) provide the interface to websockify. The main processing script mpd.js contains code to obtain information from mpd or send commands to mpd via websockify. It keep track of the playlist queue, current track, time, volume, available playlists etc available in js objects.  UI.js provides a number of jquery functions to format this information in html.  A html webpage can then be constructed calling UI classes and methods to view information and send mpd commands.
Due to my very rusty js knowledge I initially had problems writing my own js functions to communicate with mpd using mpd.js.  However as soon as I realised that I needed to use the function on('StateChanged',xxx) and obtain the mpd state within that function all was straightforward.
Using the developer console (F12) in chrome or edge with console.log statements makes it quite easy to follow code.  One area that tripped me up is that, particularly with chrome, javascript code needs to be manually refreshed in the browser to update it.
A small error was found in UI.js which referred to an element playlists.playlist.playlist which should have been playlists.playlist.  Presumably this was caused by a change to mpd.  I updated websockify include files to make sure we have the latest software but mpd.js is 3 years old so some incompatibilities may have crept in.

Implementation

We chose which MPD.js functions to use in the web app.

Information Display

  • Artist, title
  • song duration, time elapsed
  • play state (play, pause, stop)
  • track current playlist

Control

  • Choose radio station to stream
  • Choose recorded radio playlists (without adverts)
In addition, when looking for the best way to play an album I found that there was already feature to browse the music directory structure and add tracks.  I was able to modify this to add entire albums instead.


Friday 4 May 2018

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.

Tuesday 24 April 2018

Multiroom RPi Music Server Configuration

Introduction

My previous post described the steps to set-up an RPi to use a bluetooth speaker and initial setup of an MPD music server to play music from the RPi through the bluetooth speaker.
This post deals with configuration to make the setup more useable.

Multi-room capability

Pure Jongos have a capability called caskeid which allows a set of them to play the same music.  The Pure Connect app, which runs on IoS or Android allows you in settings to specify which Jongo devices will use caskeid to work together.  They use wifi to pass music to each other so they need to be on the same wifi network.  When you attach to one Jongo using bluetooth the sound is streamed to the others using wifi and they play in sync.  Pure connect is also used to set the relative volume of each device.  In my setup JON is the Jongo near the RPi and distributes music to the other devices.

Bluetooth Connection

A bluetooth connection from PI3 to a Jongo device is key to making the system work.  Unfortunately in the past bluetooth has been a real pain on RPi.  I used the PI3 which has integral bluetooth and made sure that software and drivers were up to date.  As noted in the previous blog I used the RPi GUI for initial testing.  I have tried to list the key points for a happy bluetooth experience.

Initial device connection

Make sure the device you are using is paired and trusted - this only needs to be done once.
You can check device status with info <device addr>.
Other bluetooth tech can steal/hog a device so make sure that phones/ipads/headphones have wifi switched off when near the jongo to be setup.
The jongo should be showing solid orange meaning it is ready to connect.
Make sure that pulseaudio is started before connecting.
bluetoothctl connect command should now work and after flashing green the jongo should show a solid green light.
You can use mpg123 or mpd/mpc to play some music.  If no sound comes out the jongo connect a speaker to RPi audio jack and see if the sounds are coming out there instead.  If so it is a pulseaudio problem, use pactl commands to check whether pulseaudio can see the bluetooth sink.
If mpd appears not to be working, use mpc playlist command to see whether anything is waiting to play.

Device Reconnection

After a few minutes without playing bluetooth automatically disconnects and the jongo light reverts to orange.  Running the bluetooth connect command again should reinstate the connection.  If playing a readio-station the bluetooth connection can stay active for many hours.

MultiRoom sound

Other jongos don't always sync as you would hope.  Sometimes they are bit slow so it is worth waiting a couple of minutes before investigating.
Make sure that they show an amber or green-flashing light before running the connection command.  If the device is showing solid green it is connected to something else.
If the device is showing red it has an error.  In either of these two cases power off / on the jongo.

RPi Startup

When RPi is started up bluetooth, pulseaudio and mpd should all be working.
You need to mount the rpip share with /home/pi/scripts/rpipmount
You need to start the ympd web server with /home/pi/scripts/ympd.sh

MPD Clients

MPC is very useful for checking what is happening on the server and is the best trouble-shooting tool but it is not convenient for managing playlists.  I want to control the server from a variety of devices so all of the clients below are useful. MPD communicates with clients on port 6600 so it is only necessary to configure a client for IP:port to establish communication.

ncmpcpp (linux command)

This is an ncurses program which does a good job of using text screens to control mpd.  It is much more convenient for browsing folders and controlling playlists.

Auremo (Windows)

A very nice, easy to use client which allows streams to be setup.

MPDluxe (iPad)

The app costs £2.99 and is the only MPD client for the iPad since the demise of mPod.
It works well and includes the ability to switch repeat/consume etc on/off

M.A.L.P and MPDroid (Android)

M.A.L.P. only allows selection of songs or albums so is a bit limited.
MPDroid is better and allows playlists or streams to be selected.

ympd (Chrome on Windows, iPad, Android)

ympd is a very nice little python application which runs on the RPi with a small webserver on port 6800 (my choice) and its own connection to MPD on port 6600.  It shows what is playing and allows MPD to be controlled well.
Clearly it helps avoid the need to install other apps.

Streaming

mpd can also stream music directly to a device although it doesn't really fit in with the multi-room sound.  MPD allows you to send output to multiple devices so you can enable streaming on port 8000 in /etc/mpd.conf.  You can then go to a browser and enter //PI3:8000 which will play the music for you.  Note that it is not synchronised with bluetooth outputs so it cannot be played at the same time as others.

Music

NAS (samba/cifs)

As mentioned in the previous post most music is stored on my home NAS, usually known as RPIP.  In general music is stored as //rpip/rpipmusic/<artist>/<album>/<song>.mp3 or //rpip/rpipmusic/<artist+album>/<song>.mp3.
The NAS has a mount point /var/lib/mpd/music/rpipmusic so all albums are easily found with the mpd structure.

Web (http)

MPD accepts urls as valid filenames so anything which is stored on a webserver can be played.  For example rpip webserver is at /var/www/html/music/<artist>..... and music can be played as http://rpip.helliwell.org:8024/music/<artist>......

Playlists

MPD only allows playlists with suffix .m3u but it isn't very choosy what goes in them. Terminology is somewhat confusing.  The playlist is the list of songs that mpc is currently playing or waiting to play. A set of songs can be saved in a playlist file which can then be loaded and played together.  It is easy to use Auremo or MPDluxe to put an the tracks in an album on the playlist and then save them as a playlist file with the album name.  The names of tracks can be local files, remote NAS files or web urls.

Radio

Most radio stations are now available for internet streaming.  A url for a radio stream can be downloaded to Windows from radiofeeds.co.uk.  This can then be stored as a single entry in a playlist file and played by mpd.  For example capital_radio.m3u contains the line 
http://media-sov.musicradio.com:80/CapitalMP3
When this playlist is loaded or run from a client the station starts playing.  In most cases clients are able to display what track is playing and update it as the song changes.

Rplay

rpip hosts my Rplay application which saves music streams and cuts out the adverts.
As files are stored in //rpip/var/www/html/music/Radiostream they are available to MPD.
However I will change this.




Sunday 22 April 2018

Multiroom RPi Music server using Pure Jongos

Requirement

There are only a million RPi music server projects so I am sure there is room for 1,000,001.  I already have speakers in a number of rooms for the radio, hifi and sound bar and they work well so I don't want to duplicate or replace them.  Current systems are all a few years old so don't have built in bluetooth connectivity. However I would like to be able to use bluetooth and listen to the same music throughout the house and to have the entire music collection in one place.
Sonos is the current vogue for multi-room music.  Music is stored on a NAS or PC and each device stores an index of available tracks and their location.  It is controlled via a phone app which does not need to be active unless you want to change something.  It is not suitable for my requirement due to the need to buy lots of hardware but the music server approach seems good.
I am very fond of the Pure Jongo A2 bluetooth hifi adapter.  It attaches to any music device with phono inputs and allows you to play music from your phone or tablet using bluetooth.  It can also route music from NAS or internet radio channels to a sound system.  It also has a wonderful feature called "caskeid" which shares music between Jongo devices so that you can listen to the same sounds in multiple rooms.  There are Jongo speakers which can add sounds in extra rooms or outside.  These features make Jongo an excellent basis for a multi-room system but there are a couple of catches.  Firstly, your phone/tablet needs to stream the music to Jongo.  You can't move it to a different room or turn it off.  Secondly Pure appear to have lost the multi-room battle to Sonos and are discontinuing their Jongo range.  In fact this means prices for that  A2s (£20) and speakers (£50-£150) are reasonable on Amazon or Ebay so it makes for an affordable system.

Design

Hardware

I currently have a RPi which is used as a NAS so it makes sense to use it as a music server as well.  The current device is B+ so I need to plug in a USB bluetooth adapter which will communicate with one of the Jongos.
I already have three Jongo A2 attached to my study HiFi, TV sound bar and kitchen mini-system so these will form the core of the playback system.  I will add a Jongo speaker and another A2 to allow two more rooms to be linked in.  I may buy another outdoor specification Jongo for use in a bathroom.  All devices will be setp via the Pure Connect app with caskeid so that they synchronise playback.

Software

RPi software setup will comprise the bulk of the project.  The obvious music server to use is MPD which is a long-term component of linux.  It plays music from multiple sources, namely local disks or network URLs which may represent web music (http), NAS (smb) or streams (pls).  Files can be added into playlists (m3u).  Mopidy was investigated as a popular alternative to MPD but doesn't seem to have important extra features.
An advantage of using MPD is that it is a standard product so there are many clients available to control it (play/pause, create/load playlists, etc).  MPDroid or M.A.L.P can be used on Android, MPDluxe (£2.99) on IoS and Auremo was chosen for the Windows as I have previously found it useful.  In addition to these platform specific apps there is a small package called ympd which runs as a small RPi python web server to allow MPD to be controlled from a browser window.  There are other web-based clients but they have more complex/specific requiremetns for web-server, database etc.  As a backstop the standard linux music client MPC can be used via an ssh session (mobaxterm/putty on Windows, reflection on iPad) or at the RPi console / GUI.
The RPi will continue to be used "headless" so generally the GUI will not be present, although it is useful during testing.
I have found bluetooth and audio routing problematical on RPi previously.  Bluetoothctl and pulseaudio for sound routing are pretty standard so I will need to make them reliable.

Media

Existing music collection stored on large USB stick will be available, I would also like to setup a number of radio streams and access playlists in my Rplay no-advert radio system.

Installation

This is intended to be a reasonably high-level description of the installation in April 2018 on PI3, a RPi B+ running Raspbian Stretch.

Step 1 Software installation

Bluetooth software on RPi has changed a lot of the past two or three years with new versions of raspbian so it is best not to use old tutorials, this one seems quite recent.

Update linux: # apt-get update;apt-get upgrade; apt-get dist-upgrade; rpi-update
Install bluetooth/pulse audio: # apt-get install blueman pulseaudio pulseaudio-module-bluetooth
Install music software: # apt-get install mpd mpc mpg123

Step 2 Sound testing

I don't have speakers connected to PI3 by default so initially I connected some and made sure that playing an mp3 file using the command line player mpg123 resulted in sounds.  Note that not all mp3 players support .mp3 files and many don't recognize pulseaudio, so mpg123 is a good choice.
I also used the GUI initially.  There are bluetooth icons on the menu bar on the top right of the screen.
I made sure that my Jongo A2 was visible by running bluetooth setup from the icon and ensuring it was paired and trusted but not connected.  Then, right-clicking on the speaker icon and selecting the bluetooth speaker caused the bluetooth speaker to burst into life.  There was some trial and error involved, in particular pulseaudio didn't always seem to be running which prevented bluetooth being used with mpg123.  Once this step is complete we know that we can play music on PI3 through a bluetooth speaker using the GUI.

Step 3 MPD Music Server

MPD (Music Player Daemon) is a venerable but widely used music server for Linux.  It contains a database of song titles and plays to a music device.  MPC (Music Player Client) is the corresponding  linux command line client software which allows music to be started, stopped, re-indexed and playlists to be managed. As installed MPD doesn't support pulseaudio properly because pulseaudio is running as pi and cant communicate with the mpd user.  The wiki explains how to setup MPD so it streams to localhost (127.0.0.1) which pulseaudio can read and send to bluetooth.
Once mpd is setup music can be stored in /var/lib/mpd/music. CIFS/SMB shares on other devices can be accessed by specifying mount points in /var/lib/mpd/music.  For example I setup a mount point for my RPi NAS at /var/lib/mpd/music/rpipmusic/ with:
 sudo mount -t cifs /<nas ip>/<nas share>/ /var/lib/mpd/music/rpipmusic / -o user=x, pass=x
In addition MPD accepts urls as file locations.  These may be http://server/folder/song.mp3 or streaming radio URLs.

Step 4 Play music with MPC

Once some music has been placed in /var/lib/mpd/music use the command mpc update to index it and make the music available. It is fiddly to do this entirely using mpc but it is still the fastest way of getting started. mpc ls will show you what folders and playlists are available.  You should see your music there.    mpc listall <foldername> will show you what is available in the folder (e.g. an album).  mpc add <foldername>  will add files in <foldername> and any sub-directories to your playlist which you can then show with mpc playlist.  Finally mpc play tells mpd to start playing the music and mpc pause or mpc toggle stops it.

Conclusion

At this stage we have a music server playing through a bluetooth speaker so we have met our key technical requirements.  There is a lot more we can do to improve the system which I will summarise in the next posting.










Monday 26 February 2018

Kodi Investigation

A number of web articles and people have said how good Kodi is so I thought I would investigate.

Kodi runs on RPI, android phones, linux, Windows, firestick as well as dedicated platforms.  Initially I have tried it out on RPI in two flavours: (1) installed as a package on Raspbian and (2) as part of a dedicated Libreelec installation.

When you start up either option the Kodi screen is displayed on the RPI console (ie attached HDMI screen).  Kodi can play local music or films.  There is also a youtube addon which comes as part of the existing kodi repository.  I tried all of these but they are not as convenient as the same functions under windows so not of much interest.

If you connect a TV to the RPI HDMI connection you see the Kodi screen as expected.  Thanks to a feature called HDMI-CEC you can use your remote control to navigate the Kodi menus: up, down, left, right, select, return, exit etc.  The TV sends signals back down the HDMI cable to Kodi on RPI  which responds accordingly.  The kodi interface is most suitable for a remote control rather than mouse and keyboard so this makes using kodi much more convenient - although a keyboard is much easier if you are typing URLs etc.

I did try a number of add-ons...

Covenant
A well-known add-on for watching movies and TV shows.  It is now available from http://archive.org/download/repository.xvbmc. It looks like most recent movies are available and the links for a few popular ones appear to work.  Links for TV programs didn't work for me, they are either out of date or there are too few sources.  You generally wait for a couple of minutes before you find out whether a movie is available or not.  In practice torrent downloads would be more convenient.  I found the "most popular" listings interesting to decide on something to watch - although I might watch from a different source.

PureVPN
I chose PureVPN as a commonly-used well-priced VPN service with lots of locations and with good, specific installation instructions for Libreelec/Krypton/RPI.  It also works on lots of other platforms including Windows and it has a plug-in for chrome. For Kodi you simply download a zip file, copy it to the RPI and install the zip file.  You can then choose a country location for VPN or leave it disconnected if you want.
It is a bit hard to tell what difference it makes without experimenting with it on/off but initially it helped to watch TV programs when it was set to a US location.

Simple IPTV client
Loads of IPTV channels are available by googling the internet.They are intended to be played either with VLC or Kodi etc.  Mostly I found they didn't work properly or were dull or foreign.  You use a .M3U file which contains details of each channel.  You can load this as a URL or a file into VLC or copy the file across to Kodi which will then load the channels.  In my search, I just found a few US country music channels to watch. I found the quickest way to experiment was to download then cutdown the channel list on windows, copy it to kodi using mobaxterm, renaming it as list.m3u.  Simple IPTV client specified list.m3u as the local channel list so I just rebooted Kodi once I had loaded the list.  It was much easier to try out channels in VLC.  Unfortunately commercial ones tend to be very jumpy.

Other avenues
Many people use Kodi to watch sport but since it adversely impacts premium sports channels suitable mechanisms are regularly closed down.
Repositories are full of add-ons, some must be useful for other purposes but it is difficult to know where to start.