Skip to content

[Backport to stable] 2.8.5#3670

Open
github-actions[bot] wants to merge 10 commits intostablefrom
backport/2.8.5
Open

[Backport to stable] 2.8.5#3670
github-actions[bot] wants to merge 10 commits intostablefrom
backport/2.8.5

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

@github-actions github-actions bot commented Apr 13, 2026

Automated backport PR for stable release 2.8.5 with cherry-picked commits:

LosCV29 and others added 10 commits April 13, 2026 07:31
Re-submitting #3514 against `dev`. The previous PR was merged to
`stable`
on 2026-03-30 but was overwritten a few days later by the `[Backport to
stable] 2.8.2` PR (#3564), which force-syncs `stable` from `dev`. Since
the fix never landed on `dev`, every subsequent release (2.8.2, 2.8.3,
2.8.4) has shipped without it.

Original description:

The Apple Music provider parses contentRating on albums (line 841) but
not on tracks, leaving track.metadata.explicit as None for all Apple
Music tracks. The Apple Music API does return contentRating on song
objects with values "explicit", "clean", or absent.

This prevents Music Assistant from distinguishing between explicit and
clean versions of the same track, affecting compare_track() matching
and any downstream integrations relying on the explicit flag.

Every other provider (Spotify, Tidal, Deezer, Qobuz, YouTube Music)
already sets metadata.explicit on tracks.

Ref:
https://developer.apple.com/documentation/applemusicapi/songs/attributes-data.dictionary
Fixes: music-assistant/support#5028

The "Continue listening" row on the discover page can show podcast
episodes that are no longer available — either because the podcast was
removed from the library, or the podcast provider dropped old episodes.
Clicking them causes errors. This happens because podcast episodes
aren't stored in MA's database (they're fetched live from providers),
but the playlog entries for them persist indefinitely with no link back
to their parent podcast, making targeted cleanup impossible without
architectural change.

So the solution in this PR is to filter podcast episode entries older
than 7 days from the in_progress_items query. Audiobooks are unaffected.

Deleting the playlog entry was considered but it was way more involved
and in the end I decided that there is no downside to just hiding. The
playlog already retains entries for every episode ever played regardless
of this change — this filter only affects what appears in the "Continue
listening" row. The playlog doesn't grow any larger than it did before.
And by preserving the data, if a user re-adds the same podcast later,
their resume positions and played/unplayed status are intact. If a user
plays a previously hidden episode again, the timestamp updates and it
immediately reappears in "Continue listening".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants