Allow streaming radio to use external now-playing source, instead of the (limited) stream metadata

[solacedesigns]

Streaming radio track info in MA is currently limited to ICY metadata, and when a station's ICY feed is empty or
malformed, you're kind of stuck with a less than ideal experience.

When I got a Tuneshine (it's a small 9x9 inch low res pixel (64x64) display designed mostly for displaying artwork of whatever music you are listening. I quickly realized I wanted to drive this from Music Assistant since that's how I listen to my music about 90% of the time when I'm at home. I used Claude Code enabled in one of my test Home Assistant instances to help me utilize the Tuneshine API and built-in support to push artwork and now playing info (as well as radio station and streaming source info, and more recently, DJ shift changes/current DJ artwork/titles, etc.) to my Tuneshine.

Eventually I decided I wanted this info to be easily displayable anywhere in my house so I had Claude help me build a tvOS and Android TV app that displays a higher resolution version of what I use the Tuneshine for with a lot more info/data.

A couple of issues I've encountered

Two stations I listen to daily can never show a track or a cover in the Music Assistant UI, whatever metadata
providers are enabled:

• CHIRP Radio broadcasts an empty ICY StreamTitle — metaint present, value blank —
  so streamdetails.stream_title is None. Nothing to parse.
• WFUV mangles & into _ and never separates artist from title.

Both publish good now-playing data on the web. CHIRP's is the same feed their own site and
social bot run on:

https://storage.googleapis.com/chirpradio-public/playlist.json
→ now_playing: { artist, track, release, label, dj, artist_is_local, lastfm_urls{…} }

Richer than ICY can express — label, whether the artist is local, and who's on the mic.

Issues I encountered when trying to figure out a solution

MA's existing answer to "this broadcaster has an API" is a provider: radioparadise,
abc_radio_network, sverigesradio, orf_radiothek, bbc_sounds, somafm,
mammamiradio. Clearly right for national broadcasters. But a provider for one Chicago community station isn't a reasonable thing to ask you to merge or maintain, and I wouldn't propose it.

So it got me to thinking, what if there was just a way to add a Playlist feed URL to a streaming station (whether from TuneIn, SiriusXM, etc.), that it can use to parse track names/artist/album data to display a much more rich visual display in Music Assistant than just the station logo.

Proof of concept

I run a small service next to MA that subscribes to player_updated over MA's WebSocket
and drives an LED now-playing display plus a couple of TV apps and a Dashboard widget for HA. It started out just
mirroring current_media; the station-feed layer got added a month ago because two of my
presets showed nothing but a logo.

Examples:

Configuration is three lines per station — keyed by the station name exactly as MA
reports it, which turned out to be a stable and convenient key:

nowplaying_apis:
  CHIRP Radio: { type: chirp, url: "https://storage.googleapis.com/chirpradio-public/playlist.json" }
  KEXP:        { type: kexp,  url: "https://api.kexp.org/v2/plays/?limit=1&format=json" }
  WFUV:        { type: rss,   url: "https://wfuv.org/playlist/feed" }
nowplaying_prefer: true     # feed wins over ICY where one is configured
nowplaying_ttl: 20          # cache seconds
feed_poll_seconds: 15

Three format handlers, ~20 lines each. Everything else — artwork lookup, display, the
sensors my TV apps read — is shared with the ICY path, because the feed just fills in
artist / title / album / image and then rejoins the normal flow.

What the month taught me

• Feed-preferred with ICY fallback is the right default. Where a feed exists it's
  strictly better; when a fetch fails, falling back to ICY beats blanking the display.
• Polling only while that station is playing is enough. 15s with a 20s cache is
  generous for something that changes every three minutes.
• Feed images need validating before use. CHIRP publishes Last.fm image hashes that
  have since been retired — I hit one last week that 404s at every size while Last.fm
  serves a different hash for the same album. An unchecked feed image renders as a broken
  image, which is worse than the station logo. I now HEAD it once, cache the result, and
  fall through to a normal artwork lookup if it's gone.
• Feeds carry state that isn't a song. KEXP's API returns air breaks alongside music;
  entries need filtering by play_type == "trackplay" or you show a stale song through
  the news. Any generic implementation wants a way to say "this entry isn't a track".
• User agents matter. KEXP's API 403s the default Python-urllib UA.
• The extra fields are worth exposing. CHIRP's dj, label and artist_is_local
  ended up more interesting than the artwork — the DJ name is on my display because the
  feed happened to carry it.

What it looks like in practice

When playing CHIRP Radio for example, MA shows the station logo and my display shows the album artwork, Track Title, Artist Name, streaming source logo in the bottom right with the bitrate below it, and an optional DJ/Show/Schedule information in the top left corner and Station Name and Logo in the top right (this can be swapped using the settings in both tvOS and Android TV), the same radio stream at the same time, the only difference is that one of them read the feed.

The obvious limitation of doing this downstream: it can't fix MA's own UI, which is what
prompted me to write this proposal up rather than keep it to myself.

---

Some general background on streaming radio data feeds

Recognise common platforms from a URL. A large share of stations run software with a
predictable endpoint — Icecast /status-json.xsl, Shoutcast /stats?json=1, AzuraCast
/api/nowplaying/<station>, Triton nowplaying-v2, Radio.co, and Spinitron, which a
great many US non-commercial stations use. One parser each, and hundreds of stations light
up without anyone writing a provider.

A generic field mapping for everything else, covering feeds like CHIRP's:

nowplaying:
  url: https://storage.googleapis.com/chirpradio-public/playlist.json
  artist: now_playing.artist
  title: now_playing.track
  album: now_playing.release                    # optional
  image: now_playing.lastfm_urls.large_image    # optional

Nothing downstream needs to change: once artist and title exist,
update_radio_stream_artwork() already finds the cover.

Is there appetite for this type of info/data to be shown in MA at all, or would you rather keep now-playing in MA strictly to whatever data the providers hand out in their stream?

[solacedesigns]

Ended up just building a custom Lovelace player that satisfies my needs for now.