This would enable me to read what’s currently being played. I already have this working for both Roon and Plexamp. It would be awesome to enable it for Airplay as well.
MQTT requires a broker. This could be integrated in Ropieee, but alternatively exposing settings to connect to an external broker would be fine for me as well. And would simplify the changes on the Ropieee end.
This change would require recompiling shairport-sync with MQTT support, as well as exposing some of the associated settings via the web ui.
@spockfish is this something you are interested in?
If it’s useful and possible (seeing that Ropieee is not OSS), I’d be willing to contribute this change.
RoPieee already makes extensive use of MQTT itself: the display is controlled via MQTT.
There’s a simple reason for that: the goal is that ‘every’ service can use the screen.
But what I don’t want is to use existing MQTT implementations available by different services (like Shairport-Sync): this means I need to adapt the screen software to the various services and that’s something I don’t like. So I’m walking a different path: there’s a piece of software, called ‘ropieee-controller’ which acts like a ‘bridge’ to MQTT, specifically for the screen. So the idea is that this piece of software can handle different services (where Roon is already implemented) and expose the required information then, via MQTT, to the display in an abstracted form. Theoretically it means that the display then does not have a notion whether the data is coming from Roon, Shairport-Sync or any other service.
So… no, I’m not interested in exposing the Shairport-Sync MQTT implementation, sorry. It’s just not aligned with the vision and long-term goal for RoPieee. I do however am working on a generic solution, and I certainly see an option in the future in exposing RoPieee’s MQTT for ‘external’ use.
Understood. And that sounds like a sensible approach.
If you would be willing to make ropieee-controller public (or shared with me), I would be willing to contribute metadata from shairport-sync (through a pipe or UDP). I’d be happy to follow whatever structure/architecture/coding style you have started and discuss my implementation with you of course.
I can develop this ‘offline’ outside of Ropieee with a local compiled copy of shairport-sync. And since the controller just publishes MQTT, this sounds like a very nicely isolated piece of functionality, easy to work on outside of the rest of the system.
That’s in essence the route I’m taking. My first attempt after Roon is with Librespot (Spotify), where step 1 is a simple shell script that forwards the events from Librespot to ropieee-controller. There I can do whatever magic is necessary to publish it on MQTT in ‘RoPieee format’.
I appreciate your willingness to participate. But here’s my thing: I’m a business owner with a very limited amount of free time. And I’m out of coding for the last 20 years: I’m doing ‘managerial stuff’ all day. So for me RoPieee is ‘me time’: keeping my coding skills to a certain level, keeping my brain flexible and be able (in contradiction with my day job) to ‘get into the zone’.
But the most important part? That I don’t need to consider anyone (that’s what I’m doing on a daily basis in my company). I decide when I work on it, I decide what I find interesting or not, I decide if a feature makes it. If that sounds egoistic… it is But that part of ‘freedom’ is what makes it possible to do what I do and spend a illogical amount of effort (time and money) on something and have fun (mostly) while doing it.
I actually find myself in a similar situation – CTO for the last 10 years (being a Dutchie you might know WeTransfer?) and no time for coding outside of hobby projects.
I totally get it. And you egotism on this.
If you change your mind, feel free to send me a DM
For now, I’ll simply fall back to monitoring Last.fm, which is a reasonable proxy for playing over airplay in my case.
But that part of ‘freedom’ is what makes it possible to do what I do and spend a illogical amount of effort (time and money) on something and have fun (mostly) while doing it.