Rune has stopped playing playlists via upmpdcli :-9

I don't know when this happened, but with the various OpenHome clients I have (Lumin, Kazoo, UpPlay), but it appears that both my Rune-based renders are no longer working properly. When presented with a playlist via a UPnP client, they play the first track and then stop. Subsequent tracks can be played by direct selection, but they don't then roll to the next one. Bummer.

I've had a look with Wireshark, but the UPnP protocol is pretty impenetrable from scratch. Yes, I can see things happening, and kind of decode them, but it's not simple. I am using upmpdcli which comes standard with Rune to interface mpd to OpenHome/DLNA/UPnP. The Rune player works from the web interface, with the entirely different playlist mechanism working fine. So - I think there's something afoot with the UPnPClient-upmpdcli interface.

Research on the upmpdcli website reveals that the code is currently at version 1.4.12 - my version of Rune (which is hardly supported at all!) is at something mad like 0.13 !!

I have choices:

• Go for another version of Rune - there is a much more recent version, with newer versions of everything, that has a truly horrible UI; frankly, I'd rather not have a UI, other than a means of simplifying restarts if things are hung up
• Try to install a newer version of upmpdcli, which means 
• Learning about ArchLinux pacman and so on
• Possibly recompiling upmpdcli for ARM (!)
• ... And thereby breaking the Rune I have
• Switch to another product
• Volumio - meh. 
• Moode ?
• picoreplayer - Logitech, not UPnP

Urgh. I happen to have a RPi with Volumio already installed, let's check that out first. Volumio has an OTA update facility, so I'll crank that up and see what happens.

OK, did that. It does now provide the continuous album play, but... the Tidal interface appears to be broken! I have to check back on my previous efforts in that respect.

Update - The Following Day!

In order to try things out independently , I installed upmpdcli on my Linux box, and pointed it at the Volumio MPD. It worked fine as a native OH renderer, showing up in all the right places, and controlling the Volumio MPD. Result, at least in terms of understanding the way things work, and providing further options (none of which seemed very useful!). The latest upmpdcli supports Tidal, BUT doesn't have a valid current API key/token, so although the Linn Kazzo CP shows it supports Tidal, you can't login.

Since I want Tidal (I'm paying for it!), and I don't want to give additional money Volumio for their Tidal interface to work when I'm fine with Kazoo, Lumin as CPs, and BubbleUPnPServer as a serverside streaming interface, I need to get things working as they were i.e.

                Linn Kazoo/Lumin CP
                         | | |
    ---------------------  | ------------------
    |                      |                  |
minimserver MS ------------|----------  Rune MPD+UPnP renderers
                 -----------                  |
                 |  |--------------------------       
    BubbleUPnPServer OH+Tidal

Much more investigation followed, into BubbleUPnPServer especially, trying to get consistent naming etc. so I could track what was seeing what and so on. However, couldn't seem to get BubbleUPnPServer (BUS) to "see" the new render instances i.e Volumio and the standalone upmpdcli instance. I spent ages tail-ing the log file, doing various restarts, with no luck...

Until, at one point, all the flipping upmpdcli instances became visible!! I was then able to add some test OpenHome renderer proxies in BUS, and they worked well, including Tidal. Then, just for the hell of it, I tried multiple tracks in a playlist for the renderers that previously hadn't worked, and they did. Damn. Anyway, after many hours, I'm back were I started, except that things work, and I know a lot more about how this setup actually works than I did! I might write something more about all this at some point.

I also loaded BubbleUPnP onto my Amazon Fire aka Android tablet, and it seems pretty handy. Other than a restriction on playlist length (16 max in the free version) and a certain tendency to overwrite the queue, it works ok, and of course it's easier to read on the bigger screen. I might even persuade my wife to use it!

Rune, bubbleUPnPServer, Linn, Names and Rooms

It's been a while since I've posted anything in this blog, largely because my RPi audio has just been working. However, a week or two (maybe more, grr) I thought it would be interesting to check out if Rune has moved on, and see if there were any interesting new features available.

I cautiously downloaded a fork of Rune, with a revised UI, and tried that, on a new SD card - yeah, that's a handy way to test things without changing the original.

Yuck. Hated the UI, and none of the features were interesting. I then tried a later version of the original Rune - didn't seem to work consistently with the Linn Kazoo OpenHome CP programs I have (iOS app and MacOs). Drat. I upgraded, or at least, re-installed the bubbleupnpserver I have installed on a separate RPi running the media server using minimserver, in an attempt to make it work better. Nope.

Back in went the original SD card. Things seemed to work... except they didn't. Songs would cut out and then recover, or not, completely randomly. Now, I had used an Apple AirPort to provide a wired-seeming interface to the RPi, rather than rely on the RPi built-in wireless. So I ran a cable from room A to room B, and ditched the Airport. That seemed to fix the outages... but still the Tidal streaming service, from the Bubble UPnP Server, wouldn't work, and the Linn Kazoo instances couldn't always find the renderers... Argh. Very Boring Indeed, especially as there didn't seem to be a rhyme or reason to this.

Looking at logs, it seemed that the Bubble Server and RPi Rune instance would get out of step, and the Linn Kazoos would be asking for the wrong IP address. Weird, as the IP address of the RPi Rune renderer is a dynamically advertised property, using DNLA/OpenHome protocols. I tried snooping packets using tcpdump and wireshark, but that wasn't much help, largely because I couldn't see the server <> Rune <> Kazoo packets because I wasn't running wireshark on the right box.

A bit of googling, and looking at the configuration file for upmpdcli, the program that provides the DNLA/UPnP interface for Rune, and I realised a number of things:

• The mysterious "Main Room" device that Kazoo could see is actually the native upmpdcli, which provides an OpenHome interface itself, offering a Room where the Product is located i.e. a potential grouping of multiple OH devices e.g. preamp, renderer,  whose name is configured in the config file using ohproductroom
• Bubble UPnP Server allows configuration of the Product and the Room, as separate fields. I had always used the same value for these - why not? Didn't seem to make any difference - but clearly there was confusion about the devices/rooms I was using
• upmpdcli also offeres a Tidal interface!! Handy to know...
• Kazoo detects the Room name, not the Product name!! Weird, but I suppose it makes sense if your devices/products have to be grouped together for control of a single audio stream

So - I

• reinstalled Bubble UPnP Server, just because...
• renamed the upmpdcli DNLA service on my Rune instance, so it would be redetected, and also altered the Room name, just in case
• redetected the Rune DNLA service in BUPnPS, and used different names for the OH Product and Room fields

Now things appear to work. For the time being anyway. Let's see how long they work for...

Incidentally, I tried using the two different OH interfaces available, from MacOs Kazoo:

• Bubble UPnP Server OH wrapper for upmpdcli DNLA
• upmpdcli native OH interface

They both work, but only the Bubble currently supports Tidal - I think there's more configuration required for upmpdcli. However, if I start a track from the media server in one, then switch to the other, it all gets a bit confused, and I'm not really surprised. I think I'll stick to the Bubble one for now, at least until I've worked out how to configure upmpdcli properly!

Update

It appears that the Rune version that I'm running has a very old upmpdcli, which does not include the Tidal interface. A little investigation reveals that because Rune is based on ArchLinux, rather than Raspbian (as Volumio is), the Debian apt-get mechanism for upgrading it doesn't work - ArchLinux uses PacMan, which an entirely different mechanism. Bugger. Almost makes one consider using a raw Raspbian, with an installation of MPD and umpmdcli to build one's won headless version. After all, I never really use the web interface for selecting music, although I do check it to see what's working sometimes!