Parse isAvailable for song/video search results - #1001
Merged
Conversation
MarvinSchenkel
requested a deployment
to
coverage
August 21, 2026 09:20 — with 
GitHub Actions
Waiting
GitHub Actions
Waiting
MarvinSchenkel
marked this pull request as ready for review
August 21, 2026 09:21
17 tasks
There was a problem hiding this comment.
Pull request overview
This PR adds an availability signal (isAvailable) to parsed song/video search results so consumers can detect greyed-out (unplayable) items up front, aligning search parsing behavior with existing playlist parsing.
Changes:
- Parse
musicItemRendererDisplayPolicyinparse_search_result()and expose it asisAvailableforsong/videoresults (defaulting toTrue). - Update
search()docstring examples to include the new field. - Add unit tests covering default/greyed-out/other-policy behaviors for
parse_search_result().
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| ytmusicapi/parsers/search.py | Adds isAvailable parsing for song/video items in parse_search_result(). |
| ytmusicapi/mixins/search.py | Documents isAvailable in search() example output. |
| tests/parsers/test_search.py | Adds unit tests validating isAvailable behavior in the search result parser. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
MarvinSchenkel
had a problem deploying
to
coverage
August 21, 2026 09:29 — with
GitHub Actions
Failure
GitHub Actions
Failure
MarvinSchenkel
added a commit
to music-assistant/server
that referenced
this pull request
Aug 21, 2026
# What does this implement/fix? YouTube Music searches were performed without the user's credentials, while every other YTM call already authenticates. Because of that, YouTube could not apply the account and region context to search results, so tracks that are not playable for the user were still returned as regular results (and failed with "No playable items found" when played). - Pass the account headers and (brand account) user to the ytmusicapi search call, like all other YTM helpers already do. - Add a regression test that verifies search authenticates its client. Note: the full fix for the linked issue also needs an upstream ytmusicapi change to expose the availability flag on search results (sigma67/ytmusicapi#1001); this PR is the server-side part and is safe on its own. **Related issue (if applicable):** - related issue music-assistant/support#6154 ## 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. --> - [ ] 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` ## 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.
sigma67
approved these changes
Aug 27, 2026
sigma67
left a comment
sigma67
left a comment
Owner
There was a problem hiding this comment.
Looks good - parser-only change, defaults to available and only flips on the grey-out policy. Thanks!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Search results currently carry no availability signal: when YouTube Music marks an item as unavailable for the requesting account or region, it sets
musicItemRendererDisplayPolicy: MUSIC_ITEM_RENDERER_DISPLAY_POLICY_GREY_OUTon themusicResponsiveListItemRenderer(the item shows greyed out in the web client). The playlist parser already translates this intoisAvailable, butparse_search_resultignores it, so consumers treat every search hit as playable and only find out when playback fails (see music-assistant/support#6154 for a downstream report).Changes:
parse_search_resultnow setsisAvailableonsongandvideoresults, mirroring the existing logic inparsers/playlists.py(defaults totrue).search()docstring examples.tests/parsers/test_search.py.pytest tests/parsers/passes (59 tests, 4 new); ruff and mypy are clean on the touched files. I couldn't extend the live-API search tests as I have no way to reliably trigger a greyed-out result across accounts/regions.