A search that asks for no media is answered with media #58

New issue

Closed

opened 2026-08-04 08:44:06 +02:00 by Claude · 1 comment

Claude commented

2026-08-04 08:44:06 +02:00

Collaborator

/Search/Hints?includeMedia=false is ignored.

Upstream answers nothing: it restricts IncludeItemTypes to the by-name kinds,
and none of those survives the access filter. This server answers with the full
media result.

Found while fixing #55 and #56, present on main before either, and orthogonal to
both — it is about which kinds a search may return rather than which library
it looks in or which columns it matches.

`/Search/Hints?includeMedia=false` is ignored. Upstream answers nothing: it restricts `IncludeItemTypes` to the by-name kinds, and none of those survives the access filter. This server answers with the full media result. Found while fixing #55 and #56, present on main before either, and orthogonal to both — it is about which *kinds* a search may return rather than which library it looks in or which columns it matches.

Claude commented

2026-08-04 09:00:55 +02:00

Author

Collaborator

A search asked for no media now answers with the names alone.

SearchManager.BuildIncludeItemTypes (SearchManager.cs:416) leaves the
request's kinds untouched while IncludeMedia is on. With it off, it adds the
by-name kinds the other flags allow — Genre+MusicGenre, Person, Studio,
MusicArtist — each only while the list so far names nothing or names that
kind. None of those is filed under a library, so the access filter drops every
one and the answer is empty.

Two details that a plausible reading gets wrong, and that measuring caught:

A request naming its own kinds keeps them. IsEmptyOrContains([Movie], Genre) is false, so nothing is added and the list stays [Movie] — a search
for movies with media off is still a search for movies, answering 3 here, not
everything. My first implementation emptied the list and answered 7.
The list grows as it is tested. Once Genre is added to an empty list,
IsEmptyOrContains is false for Person, Studio and MusicArtist, so they
are never reached. The first kind added closes the door on the rest.

Verified live against upstream over a production database, 11 of 11 including
the ordering:

request	upstream	before	now
`alien&includeMedia=false`	0	7	0
`rock&includeMedia=false`	0	50	0
`alien&includeMedia=false&includeItemTypes=Movie`	3	3	3
`love&includeMedia=false&includeItemTypes=Episode`	72	72	72
`alien&includeMedia=true` / bare	7	7	7

A search asked for no media now answers with the names alone. `SearchManager.BuildIncludeItemTypes` (`SearchManager.cs:416`) leaves the request's kinds untouched while `IncludeMedia` is on. With it off, it adds the by-name kinds the other flags allow — `Genre`+`MusicGenre`, `Person`, `Studio`, `MusicArtist` — each **only while the list so far names nothing or names that kind**. None of those is filed under a library, so the access filter drops every one and the answer is empty. Two details that a plausible reading gets wrong, and that measuring caught: - **A request naming its own kinds keeps them.** `IsEmptyOrContains([Movie], Genre)` is false, so nothing is added and the list stays `[Movie]` — a search for movies with media off is still a search for movies, answering 3 here, not everything. My first implementation emptied the list and answered 7. - **The list grows as it is tested.** Once `Genre` is added to an empty list, `IsEmptyOrContains` is false for `Person`, `Studio` and `MusicArtist`, so they are never reached. The first kind added closes the door on the rest. Verified live against upstream over a production database, 11 of 11 including the ordering: | request | upstream | before | now | |---|---|---|---| | `alien&includeMedia=false` | 0 | 7 | 0 | | `rock&includeMedia=false` | 0 | 50 | 0 | | `alien&includeMedia=false&includeItemTypes=Movie` | 3 | 3 | 3 | | `love&includeMedia=false&includeItemTypes=Episode` | 72 | 72 | 72 | | `alien&includeMedia=true` / bare | 7 | 7 | 7 |

Claude closed this issue

2026-08-04 09:00:56 +02:00