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.
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.
Using ExecuteAndCapture (and the async version) requires something to manage the captured exception, which we don't do. Errors would be silently dropped and the writes/deletes treated as if they succeeded.
If left at Default, sqlite3_enable_shared_cache is process-global, so a plugin enabling it makes these connections share a cache too.
Contention then surfaces as SQLITE_LOCKED ("database table is locked"), which the busy handler does not cover, busy_timeout is skipped and the command fails at CommandTimeout instead.
`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.
`GetProgressiveAudioFullCommandLine` forced the raw PCM muxer and a bogus
sample rate whenever the audio encoder was `pcm_*`, regardless of the
container the client asked for. Two separate failures came out of it:
- `-ar ` + `state.BaseRequest.AudioBitRate` used a *bitrate* as a *sample
rate*, and `AudioBitRate` is optional. When it is absent the argument
degrades to a bare `-ar`, ffmpeg aborts with `Expected number for ar but
found: -ar` / `Error opening output files: Invalid argument` (exit 234)
and the request fails with HTTP 500. Every `GET /Audio/{id}/stream.wav`
that does not carry an explicit `AudioBitRate` hits this.
The sample rate was already being set correctly a few lines below from
`OutputAudioSampleRate`, so the line is dropped rather than repaired.
- `-f s16le` overrode the muxer even for a real container. A request that
did supply a bitrate (`/Audio/{id}/universal` passes
`MaxStreamingBitrate`) survived the first bug but produced raw headerless
samples served under an `audio/wav` content type, so clients saw a body
with no RIFF header. The raw muxer is now only forced when the requested
container is actually raw PCM, which keeps the I2S/MCU route from #10321
working.
Also drop the `containerInternal = ".pcm"` assignment in
`StreamingHelpers.GetStreamingState`: it is written after
`state.OutputContainer` has already been read from the same variable and is
never read again, so it has no effect and only obscures where the output
container comes from.
Verified against ffmpeg 8.1.2 with a 96 kHz FLAC source: before, the wav
command line exits 234; after, it produces a valid `RIFF/WAVE` 48 kHz stereo
`pcm_s16le` file, while the raw `.pcm` route still yields exactly
2 s x 48000 x 2ch x 2 B = 384000 bytes of headerless samples.
Cody Robibero