jellyfin/Jellyfin.Server.Implementations, branch master

Merge pull request #17571 from obiwantoby/perf/batch-people-dto

2026-08-08T01:43:21Z

Batch people lookups when building item DTOs

Merge pull request #17541 from vdatanet/fix/byname-total-record-count

2026-08-08T01:40:58Z

Fix by-name endpoints reporting TotalRecordCount=0 next to a populated Items array

Batch people lookups when building item DTOs

2026-08-07T15:59:17Z

GetBaseItemDtos already batch fetches user data, child counts, played counts and artists before its per item loop, but AttachPeople still ran one GetPeople query per item. Rendering a page of items (for example a large playlist) fired one extra query per row. Add GetPeopleByItems to IPeopleRepository, which reads every requested item in a single query over the people mapping table and returns full PersonInfo (role, type and sort order) grouped by item id. GetBaseItemDtos prefetches this once when the People field is requested and passes it into AttachPeople, which reads from the batch instead of querying per item. The single item GetBaseItemDto path keeps its existing per item behaviour when no batch is supplied. Adds a DtoService test asserting people resolve from the batch and the per item GetPeople is never called.

Move the deletion of old related info to just before the save

2026-08-06T06:00:17Z

This makes the deletion of BaseItemProviders, BaseItemImageInfos, and BaseItemMetadataFields happen in batch as a contiguous block so the lock isn't held across items, just before the bulk SaveChanges.

Speed up search for existing item values

2026-08-06T03:48:26Z

Replace the O(n²) array .First scan with a dictionary lookup

Use a HashSet for existing items

2026-08-06T03:48:13Z

Makes the test O(log n)

Project the lowered person credit values once when updating people

2026-08-05T11:21:57Z

Merge remote-tracking branch 'upstream/master' into fix-byname-queries

2026-08-05T10:15:30Z

# Conflicts: # Jellyfin.Server.Implementations/Item/BaseItemRepository.cs

Fix by-name endpoints reporting TotalRecordCount=0 next to a populated Items array

2026-08-05T09:34:33Z

`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` 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.

Fix /Persons favourites timing out by removing the correlated favourites join

2026-08-03T22:40:53Z