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:
Incidentally, I tried using the two different OH interfaces available, from MacOs Kazoo:
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
- 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
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!
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!
No comments:
Post a Comment