diff options
| author | vdatanet <joan@vdata.net> | 2026-08-05 11:34:33 +0200 |
|---|---|---|
| committer | vdatanet <joan@vdata.net> | 2026-08-05 11:34:33 +0200 |
| commit | 4adaf7f146ee895d714ae87af6858101bb10e505 (patch) | |
| tree | d10cc70a8edf2678a992012b0fedfc0c64224986 /Emby.Server.Implementations/TextEncoding/NLangDetect/Profiles/swa | |
| parent | 7fbc1ff8c0192b608a493324f2b7eafcf0a4383e (diff) | |
Fix by-name endpoints reporting TotalRecordCount=0 next to a populated Items array
`GetItemValues` -- the shared path behind `/Artists`, `/AlbumArtists`, `/Genres`,
`/MusicGenres` and `/Studios` -- disabled the total record count whenever the
query carried no `Limit`:
if (!filter.Limit.HasValue)
{
filter.EnableTotalRecordCount = false;
}
A request without an explicit limit therefore came back with N entries in `Items`
and `TotalRecordCount = 0`. Clients that page on the reported total -- the
documented contract every other list endpoint honours -- read that as an empty
library. `/Items` and `/Persons` do not share this path and report the count
correctly, which is what makes the inconsistency visible from the outside.
Measured against master with a 62-track music library:
GET /Artists?UserId=... -> TotalRecordCount=0 Items=5
GET /Artists?UserId=...&limit=100 -> TotalRecordCount=5 Items=5
Dropping the block costs nothing: `representativeIds` is materialised into a
`List<Guid>` a few lines below regardless, so `.Count` was already available and
the count is now reported from it. Callers that genuinely want to skip the count
still can -- `EnableTotalRecordCount = false` is honoured as before.
The block also mutated the caller's own query object, so a query instance reused
across calls silently lost its total after the first limitless one. That is
covered by a test as well.
Diffstat (limited to 'Emby.Server.Implementations/TextEncoding/NLangDetect/Profiles/swa')
0 files changed, 0 insertions, 0 deletions
