Unnamed repository; edit this file 'description' to name the repository. https://git.lodewillems.com/jellyfin/atom?h=master 2026-08-05T09:34:33Z 2026-08-05T09:34:33Z vdatanet joan@vdata.net 2026-08-05T09:34:33Z urn:sha1:4adaf7f146ee895d714ae87af6858101bb10e505 `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.