/
/
# What does this implement/fix? The Radio Paradise provider, in the web interface and mobile app, would "flap" between the current track's album art and the next's, sometimes multiple times per song. I tracked it down to two things: we were using streams with the ogg container and flac audio, where the stream itself never had metadata. It is a constant stream vs. a chained Ogg stream and in Ogg metadata _has_ to come at the start of the track. And that meant we would call their API every 10 seconds to get what's currently playing, which has a wall-clock time stamp but their servers seem to return variable data (it 'jumps' forwards and backwards up to 30 seconds at somewhat random). Especially around track boundaries we would get the next track data, then the current track, then the next, at an almost coin flip. Additionally, we buffer data and the wall-clock isn't in sync with what we're actually playing over the speakers. With this change, we now use a flac stream that has the ICY metadata in the stream itself so we can *know* what the actual current track is. We then search the values returned by the API for the matching track title and enrich when they match. To do that, I had to add some infrastructure to the streams controller. Specifically, to detect in-band metadata, pass along the cleaned-up title, and suppress the core metadata writer for providers that opt-in. Thus far, I only opted-in Radio Paradise but potentially any ICY or IN_BAND (chained ogg) provider could also switch to using this, if it better matches / suits their needs. I don't use mammamiradio or nts but if they ever have album art sync issues, this could potentially solve that for them. The fact that I don't _know_ of anyone complaining outside of Radio Paradise means I'd have loved to fix this purely within the RP provider (minimum viable fix!), but if I didn't register the metadata callback with the stream controller I'd just end up fighting the core metadata writer, which would replicate the original bug in a different way. * It generally updates ~5 seconds before the track change, per my live testing over the past couple of days. I believe Radio Paradise flips the metadata just before the track transition on purpose to give folks like us time to fetch the new album cover and update our display, as well as to account for their transition fades. ## Types of changes <!-- Tick exactly one box. CI (.github/workflows/pr-labels.yaml) derives the label from the ticked box and applies it automatically; the release-notes generator uses that same label to slot this change into the next release notes. --> - [X] Bugfix (non-breaking change which fixes an issue) — `bugfix` - [ ] New feature (non-breaking change which adds functionality) — `new-feature` - [ ] Enhancement to an existing feature — `enhancement` - [ ] New music/player/metadata/plugin provider — `new-provider` - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) — `breaking-change` - [ ] Refactor (no behaviour change) — `refactor` - [ ] Documentation only — `documentation` - [ ] Maintenance / chore — `maintenance` - [ ] CI / workflow change — `ci` - [ ] Dependencies bump — `dependencies` ## Checklist - [X] The code change is tested and works locally. - [X] `pre-commit run --all-files` passes. - [X] `pytest` passes, and tests have been added/updated under `tests/` where applicable. - [ ] For changes to shared models, the companion PR in `music-assistant/models` is linked. - [ ] For changes affecting the UI, the companion PR in `music-assistant/frontend` is linked. - [X] I have read and complied with the project's [AI Policy](https://github.com/music-assistant/.github/blob/main/AI_POLICY.md) for any AI-assisted contributions. - [ ] I have [raised a PR against the documentation repository](https://github.com/music-assistant/music-assistant.io/blob/main/CONTRIBUTING.md) targeting the main or beta branch as appropriate.