Fix searching within an artist returning no results in Music Assistant - #177673
Fix searching within an artist returning no results in Music Assistant#177673marcelveldt wants to merge 5 commits into
Conversation
|
Hey there @music-assistant, @arturpragacz, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
There was a problem hiding this comment.
Pull request overview
Adds parameterized coverage for Music Assistant artist-search filtering.
Changes:
- Tests unfiltered, album-filtered, and track-filtered artist searches.
Comments suppressed due to low confidence (1)
tests/components/music_assistant/test_media_browser.py:482
- Assert that every artist search requests both album and track media types. The mocked
searchresult ignores themedia_typesargument, so these cases still pass if_search_within_artistrequests only one type; in production the missing type would never be returned and its filter would be empty. Checking the call arguments covers the synchronization this test is intended to protect.
assert mock_search.call_args.args[0] == "Test Artist - test"
assert {item.media_class for item in search_results.result} == expected_classes
An artist search asks for albums and tracks, but the media type around it decided what was kept. Coming from an artist that meant looking for artists in an album and track response, so nothing survived. Keep only what an artist can actually hold, and ask the server for just that.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (2)
tests/components/music_assistant/test_media_browser.py:541
- Remove comments that only narrate the following assertions. The asserted query and media types already make these operations clear.
# the artist name scopes the query that is sent to the search api
assert mock_search.call_args.args[0] == "Test Artist - test"
# a filter narrows what we ask for, instead of asking for everything
# an artist can hold and dropping most of the response again
homeassistant/components/music_assistant/media_browser.py:676
- Honor
media_filter_classeswhen the artist content type is also supplied._get_media_types_from_queryprioritizesmedia_content_type, so an artist query with a track-only filter produces[ARTIST]; this fallback then replaces it with both albums and tracks, returning albums despite the requested filter. The service and websocket APIs allow both fields together.
media_types = [
media_type
for media_type in media_types
if media_type in ARTIST_MASS_MEDIA_TYPES
] or ARTIST_MASS_MEDIA_TYPES
A filter is the only thing the user picks themselves, but it was ignored whenever a media type came along with it, so filtering an artist search down to tracks still returned albums.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (2)
homeassistant/components/music_assistant/media_browser.py:680
- Preserve an empty intersection for an explicit filter. If an artist-scoped action requests a valid but incompatible class such as
artistorplaylist, this fallback replaces the user’s filter with albums and tracks, so the response contains media classes the caller explicitly excluded. Only use the artist defaults when no filter was supplied; an incompatible explicit filter should return an empty result without calling the server.
media_types = [
media_type
for media_type in media_types
if media_type in ARTIST_MASS_MEDIA_TYPES
] or ARTIST_MASS_MEDIA_TYPES
homeassistant/components/music_assistant/media_browser.py:660
- Return no results when the explicit filter contains no supported Music Assistant class. The service and WebSocket schemas accept every
MediaClass, so a valid request such asmedia_content_type=albumwith animagefilter reaches the new filter-first branch, maps to an empty list, and then falls back to every searchable audio type. That both ignores the chosen filter and broadens the search beyond the surrounding type.
This issue also appears on line 676 of the same file.
# Determine which media types to search
media_types = _get_media_types_from_query(query)
Asking for something we cannot search for, or for something an artist cannot hold, quietly widened the search instead of leaving it empty, so the results held exactly what the filter was meant to keep out.
Proposed change
Searching within an artist in Music Assistant could come back empty even when the artist had matching albums and tracks. An artist search always asks the server for albums and tracks, but the media type surrounding the search decided what was kept from the answer. When that media type was the artist itself, we ended up looking for artists in a response that only held albums and tracks, so everything was dropped.
This is not reachable from the media browser, which reports items as plain music, but it is through the
music_assistant.searchandmedia_player.search_mediaactions.A related one turned up next to it: a filter is the only part of a search the user picks themselves, but it was ignored whenever a media type came along with it, so narrowing an artist search down to tracks still returned albums.
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: