---
key: sched.autotune-detailpanel-members
title: 2026-07-17 — Auto-Tune DetailPanel member list = live search-index roll-up, not EF enumeration (#384)
status: active
since: '2026-07-17'
supersedes: none
superseded-by: none
rule: The Auto-Tune DetailPanel's per-channel content-source list is a live `ISearchIndex.Search` roll-up through the server-owned `AutoTuneAxisMap.GenerateQuery`, not an EF distinct+count query, so the preview matches exactly what the built channel's SmartCollection will contain.
signals: 'Auto-Tune DetailPanel, search-index roll-up, SmartCollection fidelity · paths: `GET /api/v1/channels/auto-tune/members`, `MediaCollectionRepository.GetSmartCollectionItems` · issues: #384, #383, #69, #385, #386'
mechanics: '`AutoTuneAxisMap.GenerateQuery`; `LibraryBrowseItemMapper.GetShows/GetMovies`; `PagedLibraryBrowseItemsResponseModel`'
---

The Auto-Tune DetailPanel (#383) shows, per proposed channel, the distinct **content sources** its
generated SmartCollection resolves to (a genre channel's shows/movies), each weightable in the #385
write path. `GET /api/v1/channels/auto-tune/members?axis=&value=` backs that list.

**Why the search index, not an EF distinct+count query** — even though #69's *preview* enumeration uses
EF (`PreviewAutoTuneChannelsHandler.EnumerateTvShows/…`). The created channel's playout is built from a
**SmartCollection** whose members come from `ISearchIndex.Search` (`MediaCollectionRepository.GetSmartCollectionItems`).
For the DetailPanel to faithfully preview *what the built channel will actually contain*, the member list
must run the **same** query through the **same** index — so the handler calls the server-owned
`AutoTuneAxisMap.GenerateQuery(axis, value)` (client never sends Lucene, per #69 PR1) and rolls the matching
leaf items up to their distinct parents. #69's preview is a different granularity (enumerating candidate
axis *values* with EF exact counts to drive the min-items threshold); this is enumerating the *members of one
value*, where index-fidelity matters more than count-exactness. The two coexist deliberately.

**Roll-up + shape.** Episode axes (TvShow/TvGenre) → distinct parent shows (Episode→Season→ShowId), with
`ItemCount` = the **query-matching** episode count, not the show's total (a show contributes only its matching
episodes to a genre channel). Movie-genre axis → the matching movies are themselves the sources. Both reuse
the existing `PagedLibraryBrowseItemsResponseModel` / `LibraryBrowseItemResponseModel` DTOs and
`LibraryBrowseItemMapper.GetShows/GetMovies` (no new schema), ordered by title then id, paged in memory
(the distinct-source set is bounded — dozens for a genre). Search pulls up to the 10k cap
`GetSmartCollectionItems` already uses; a value resolving to >10k leaf items could under-report sources past
the cap — the same staleness bound the smart-collection path accepts. Read-only, catalog-read tier (no
`[RequiresAuthentication]`), so a cold review sufficed. Sibling backend child #385 (write-path overrides +
weights) and SPA child #386 remain open under the #383 milestone.

---