/
/
# What does this implement/fix? When resolving a radio station, we first open the station URL to look at its headers. If that URL turns out to be a playlist file, we then downloaded the exact same URL a second time to read it. That second download was the odd one out: every other radio request (the header probe, the ICY stream, the plain stream, the HLS fetch) goes out over the streaming session, which identifies itself as ffmpeg and tolerates the sloppy TLS setups radio servers are known for. The playlist download instead used the regular session, with the Music Assistant user agent and strict certificate checking. A station behind a filter, or with an expired certificate, could therefore answer the first request fine and reject the second one — a confusing failure that looked like a broken playlist. The playlist is now read from the response we already have, so there is no second request to diverge. **Related issue (if applicable):** - n/a ## Types of changes - [ ] 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` - [x] Maintenance / chore — `maintenance` - [ ] CI / workflow change — `ci` - [ ] Dependencies bump — `dependencies` ## Changes - Radio resolving reads a station's playlist from the response it already opened, instead of downloading the URL twice. - Splits the parsing half of `fetch_playlist` into `parse_playlist_data`, so both callers share the same parsing (and the same 64 KB read cap, now a named constant). - A playlist whose download breaks off halfway is now reported as a broken playlist, instead of the station URL being treated as an audio stream for the next three hours. - HLS stations that only announce themselves through their content type (no `.m3u8` in the URL) are now recognised as HLS instead of being treated as a plain stream. - Playlists are now read to the end rather than to whatever arrived first, so a larger playlist no longer silently loses entries (this also affects playlists imported through the built-in, SomaFM and Apple Music providers). - Adds tests covering playlist unwrapping, HLS detection, chunked downloads and the truncated-download case. ## 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.