Improve Source List Organization / Metadata

[cmelbye]

Is your feature request related to a problem? Please describe.
Snapcast integration in Iris is really great, but the source list doesn't convey as much information as it could. It isn't easy to see which rooms are currently synchronized and what they're listening to. (Just the name of the source)

Describe the solution you'd like

• The source list could be organized by what you are listening to, not where you can listen.
• It could also incorporate metadata provided by Snapcast. This would give a better picture of the audio that's currently playing on a source, or whether the source is playing anything at all.

This is just an idea of potential UX to start a conversation:

Describe alternatives you've considered
N/A

Additional context
N/A

[jaedb]

I can see you've put a decent amount of thought into how this could function - I really like where you're going with this. As I understand it, Snapcast doesn't provide metadata of the source audio which would make this somewhat difficult to achieve.

It looks like there is an existing PR for Snapcast to pull this data: badaix/snapcast#749

In theory Iris could lean on the Settings > Servers section and maintain simultaneous connections to all of those servers to get the meta from Mopidy directly, however I wouldn't expect it to be reliable in matching Mopidy servers to Snapcast streams.

[cmelbye]

@jaedb Yes, currently Snapcast does support metadata for certain stream types. The only one I'm aware of is AirPlay/shairport-sync but there could be others. Iris sees track, artist, cover art, etc. in a debug request to Snapcast.

And it looks like they plan to add support for MPD soon, too. For streams that don't have metadata, there would always need to be some sort of fallback in Iris.

[cmelbye]

This is the response to Server.GetStatus when I'm using AirPlay:

{
  "server": {
    [removed for brevity]
    "streams": [
      [removed for brevity]
      {
        "id": "AirPlay",
        "meta": {
          "ALBUM": "All That - Single",
          "ARTIST": "Emotional Oranges & Channel Tres",
          "COVER": "[removed for brevity]",
          "STREAM": "AirPlay",
          "TITLE": "All That"
        },
        "status": "playing",
        "uri": {
          "fragment": "",
          "host": "",
          "path": "/home/pi/shairplay-sync",
          "query": {
            "chunk_ms": "20",
            "codec": "flac",
            "name": "AirPlay",
            "sampleformat": "44100:16:2"
          },
          "raw": "airplay:////home/pi/shairplay-sync?chunk_ms=20&codec=flac&name=AirPlay&sampleformat=44100:16:2",
          "scheme": "airplay"
        }
      }
    ]
  }
}

[jaedb]

Ah, that is interesting. The examples and (at the time) recommended implementation of Mopidy + Snapcast was to use filesink, which appears to omit this level of metadata. This is also a simple method of getting audio streaming between docker containers (which Iris encourages) so is what I've used to date.

I feel that when Snapcast provides support for MPD, then this would be a lot more straightforward.

Have you managed any other simple method of getting audio between docker containers? Check out docker-compose.example.yml for the current approach. I had experimented with pulseaudio and it was a terrible experience.

[cmelbye]

Yeah, until Snapcast provides support for MPD metadata, I don't think it's possible. The existing support for metatags is very specific to AirPlay. This WIP branch is adding support for MPD: https://github.com/badaix/snapcast/compare/metatags#diff-dff401eacf0622e6c71058ab8bc65e87bb19470fe5801fc0a086cdffbfc55f20R39

From what I can tell, it is using the same pipe stream that the Iris docker configuration is using. What's new is an IP/port that connects to MPD to poll for metadata. In the branch above, that IP/port is currently hardcoded to 127.0.0.1:6600 but I imagine it would be a configuration option when finalized.

So perhaps that docker example would need to inform the snapserver container of an IP/port from the mopidy container that it can use for MPD connection. I forget how services work in Docker but I assume this is possible to set up...

[bendschs]

+1 for that, snapcast is getting metadata from shairport sync already.

[jaedb]

I am currently exploring how this could be achieved without depending on the Snapcast metadata. It may require some sensible stream naming (ie match Mopidy to Snapcast server by name) in order to link the two.

So far the proof-of-concept is focused on a Mopidy server-switcher (so you can easily switch between instances):

[RoggerFabri]

Any chances to include the group "master" volume into groups with more than one client? This was the previous behaviour for the outputs panel, and it was quite handy when syncing multiple clients to the same volume level.

Something like that:

[Chaphasilor]

@jaedb 3.60 looks and works pretty well so far. I had some issues with snapcast metadata not refreshing for a few minutes, but it started working again afterwards.

The only thing missing I could find was the group volume control as shown in the previous comment here. That would be useful to have, especially the mute toggle :)

[jaedb]

@Chaphasilor at the moment the meta data is sent to Snapcast only when the current track changes. So on new connections or streams, you'll need to add a trak and start playing for Snapcast meta to be updated. After that point though, you should be golden.

[Chaphasilor]

Ah okay that makes sense, I was playing around with two instances of Iris so that might have been the cause then :)

[jaedb]

@RoggerFabri can you please convert your request to a new Feature Request with a reference back to this one? I'm closing this issue as the original feature specification has now been released 😁