MA 2.10 — Synthesized from Marvin/Carl meeting notes, June 5 2026
Problem statement
Search in Music Assistant is split across two surfaces: a filter bar on list pages and a dedicated search page accessible from the navigation. Neither is context-aware — the search page ignores where you came from, and the filter bar is scoped only to the current list. Users who want to search while browsing a specific provider (e.g. Apple Music) or a specific context must navigate away or use a different control entirely. This adds friction and makes search feel like an afterthought rather than a primary interaction.
Community signals
- Library Search sort order/contextual (by default name A>Z), global search default order makes more sense — User notes that library search sorts A–Z by default while global search uses relevance. Two separate search surfaces with inconsistent behaviour; user explicitly calls for a unified contextual approach. Thread also cross-references a mobile app issue report.
- Requests and feedback about MA v2.7.0 (#4536) — Item 17 specifically: "a search bar at the top of the home screen (faster than clicking in the menu)." Explicit request for search to be persistently accessible without navigating away. (Note: the same thread also surfaces the notification popup problem, which is cited separately in #206.)
- MA User Interface documentation — Current documentation confirms search yields a max of 8 items across 8 categories by default, with no context-awareness. This architectural limitation is visible to users and shapes what they ask for.
- UX/UI topic — Search across MA: Global search and detailed search (MA Discord, Jan 21 2026) — Eriol opened this dedicated UX research thread following a dev team discussion. Key framing: "Search should be configured for all kinds of users, from the confident expert to the not sure novice user… balancing opportunities for exploration or suggesting the possibilities of exploration outside of what a user knows they want to search for." This is a design-team signal rather than direct community demand, but it confirms Eriol has already scoped search as a research priority — meaning alignment on this opportunity should be straightforward.
Scope & Boundaries
In scope
- Single persistent, globally accessible search input (replaces both the per-page filter bar and the navigation search item)
- Context-aware results: if triggered while browsing a specific provider, defaults to searching within that provider; if triggered from Discover, searches all sources
- Local results should appear instantly before remote results load
- On mobile web: search accessible from a persistent position near the player bar (inspired by Sonos and "Donuts" app pattern)
- On desktop: accessible from the top of any page without navigating away
Not in scope
- AI-powered semantic search or natural language queries
- Search indexing or backend changes (scoped to UI/UX routing of existing search APIs)
- Voice search
Foreseen solution
- Remove the filter bar from individual list pages and the dedicated search navigation item
- Introduce a single search component that is always visible (position TBD with Eriol — top of page on desktop, floating near player on mobile)
- The component reads the current navigation context and pre-filters accordingly; user can override to "search everywhere"
- Local library results render instantly; streaming/provider results populate progressively
Risks & open questions
- How does context detection work across nested pages? (e.g. browsing an album within Apple Music — does search scope to that album, the provider, or all?)
- Does removing the list filter bar break any power-user workflows?
- Mobile placement (floating vs. fixed bottom) needs testing — could conflict with player bar on smaller screens.
- Coordination with Eriol needed before implementation to define placement and interaction model.
Appetite
Medium. UI rework + context logic is non-trivial, but no backend changes expected.
Execution issues
No response
Decision log
| Date |
Decision |
Outcome |
| 2026-06-05 |
Replace both filter bar and search nav with single context-aware search |
Agreed in principle |
| 2026-06-23 |
Published to GitHub |
#204 |
MA 2.10 — Synthesized from Marvin/Carl meeting notes, June 5 2026
Problem statement
Search in Music Assistant is split across two surfaces: a filter bar on list pages and a dedicated search page accessible from the navigation. Neither is context-aware — the search page ignores where you came from, and the filter bar is scoped only to the current list. Users who want to search while browsing a specific provider (e.g. Apple Music) or a specific context must navigate away or use a different control entirely. This adds friction and makes search feel like an afterthought rather than a primary interaction.
Community signals
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Risks & open questions
Appetite
Medium. UI rework + context logic is non-trivial, but no backend changes expected.
Execution issues
No response
Decision log