| Age | Commit message (Collapse) | Author |
|---|
|
Delete old related info in bulk as late as possible in UpdateOrInsertItems
|
|
Fix disabled plugins being re-enabled on restart
|
|
Fix concurrent ffmpeg segment racing
|
|
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.
|
|
ImageHelper.GetNewImageSize passed the caller-supplied width/height straight
through to SkiaEncoder.EncodeImage, which allocates an SKImageInfo of exactly
that size. Nothing bounded those values against the source image, so a request
like Items/<id>/Images/Primary?width=23100&height=23100 made the server allocate
and resample a 23100x23100 surface from, say, a 600x336 poster: the reporter
measured 100% of a core for 10-15 minutes and 6-12 GB resident per request.
The item images endpoints do not require authentication, so any caller who knows
an item id can trigger this, and varying the size by one pixel misses the cache
every time.
Add DrawingUtils.ScaleDownToFit, which scales a size down uniformly until it
fits inside a bounding box and returns it unchanged if it already does, and
apply it in GetNewImageSize against the original image dimensions. Requests
that ask for more pixels than the source now get the source resolution back,
scaled to the requested aspect ratio. Downscaling paths are untouched, and
DrawingUtils.Resize keeps its existing behaviour for the transcoding callers in
EncodingJobInfo and StreamInfo, which legitimately size video output.
ResizeFill already refused to upscale; this makes width/height consistent
with fillWidth/fillHeight.
Fixes #17056.
|
|
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.
|
|
Improve People deduplication, fix search and restrict ItemByName responses
|
|
Fix PCM audio transcoding to wav returning HTTP 500 and headerless output
|
|
Revert "Refresh Live TV channel icons on every guide update."
|
|
This reverts commit 372c1681d8272c6fa8f120a132bc40351067fb10.
|
|
|
|
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.
|
|
`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.
|
|
This is a nasty one. The failure mode is:
1. Request A started FFmpeg and waited for a segment.
2. Request B requested an earlier or far away segment.
3. Jellyfin thought FFmpeg should to restart at a different position.
4. Request B killed the existing transcoding job.
5. Killing that job cancelled the same token request A was using.
6. The cancellation produced http 500 to request A.
To fix this:
we lock transcoding job state changes and segment handling per playlist, and use a thread safe counter to track how many http responses are still using each job’s segments. A job is only stopped or replaced once that counter reaches zero.
|
|
|
|
|
|
|
|
Fix extras naming and version assignment
|
|
Allow client-rendered graphical subtitles during remux
|
|
Fix Live TV returning unreachable "server-local" streaming URLs to clients.
|
|
|
|
# Conflicts:
# Jellyfin.Server.Implementations/Item/BaseItemRepository.QueryBuilding.cs
|
|
|
|
|
|
Fix 3D format detection when the tag is the last token of the path
|
|
|
|
Reduce correlated subqueries to improve query performance
|
|
Fix hyphenated numbers in episode titles parsed as multi-episodes
|
|
Fix incorrect year on local trailers
|
|
|
|
|
|
|
|
Avoid NRE when sorting by user-dependent keys without a user
|
|
|
|
Fix play queue index handling in SyncPlay
|
|
Apply cleaning logic on ForcedSortName
|
|
|
|
|
|
|
|
A query sorted by a user-dependent key (PlayCount, IsFavoriteOrLiked,
DatePlayed, IsPlayed, IsUnplayed) but carrying no User caused a
NullReferenceException inside UserDataManager.GetUserData, surfacing as
"Failed to compare two elements in the array" (InvalidOperationException
wrapping the NRE from the LINQ sort) and 500-ing the /Items request.
Root cause: LibraryManager.GetComparer assigned comparer.User = user
without a null guard, so PlayCountComparer.GetValue called
UserDataManager.GetUserData(null, item), dereferencing user.Id.
Two-part fix:
- LibraryManager.GetComparer: when user is null and the sort key requires a
user (IUserBaseItemComparer), substitute the SortName comparer so the
result stays deterministic instead of 500-ing. SortName is the project's
canonical tiebreaker (ItemsController injects it for album-by-artist).
- UserDataManager.GetUserData: ArgumentNullException.ThrowIfNull(user) as
defense in depth (matches the existing guards on the SaveUserData
overloads in the same file). On master this overload was rewritten to use
ResolveUserDataRow, so the NRE dereferences user.Id rather than
user.InternalId as on the release branch — same bug, different line.
Also fixes DateLastMediaAddedComparer being statically mis-tagged as
IUserBaseItemComparer: its GetDate is static and never reads User, so it
does not need one. Without this, the SortName fallback above would wrongly
engage for DateLastContentAdded on anonymous queries (returning SortName
order instead of date order). Re-tagged to IBaseItemComparer and dropped the
unused User/UserManager/UserDataManager properties.
Tests:
- UserDataManagerTests.GetUserData_NullUser_ThrowsArgumentNullException:
reproduces the crash (NRE -> now ArgumentNullException). Added to master's
existing UserDataManagerTests.
- LibraryManagerSortTests.Sort_UserDependentKey_NullUser_FallsBackToSortNameWithoutThrowing:
Sort with a user-dependent key + null user no longer throws and returns
items ordered by the SortName fallback (direction preserved).
- LibraryManagerSortTests.Sort_DateLastContentAdded_NullUser_OrdersByDateNotSortName:
guards that DateLastContentAdded still sorts by date with no user (fixture
chosen so date-desc and SortName-desc disagree, so a revert is caught).
Full Jellyfin.Server.Implementations.Tests suite: 642 passed, 0 failed.
Fixes #17393
|
|
Match VobSub MKS subtitle profiles by container
|
|
fix: don't throw ArgumentNullException on partial UpdateItem payloads (#17366)
|
|
Prevent unauthenticated re-run of the startup wizard on misconfiguration
|
|
|
|
Truncate ISO-639-2 language display names at first delimiter
|
|
* Fix subtitle encoding
* Add short-circuit
* Use IsTextFormat
* Update MediaBrowser.MediaEncoding/Subtitles/SubtitleEncoder.cs
Co-authored-by: Bond-009 <bond.009@outlook.com>
---------
Co-authored-by: Bond-009 <bond.009@outlook.com>
|
|
Backport and extend path traversal fixes
|
|
free-space failures on Windows CI runners
BackupServiceTests rooted its temp directory under Path.GetTempPath(), which
on GitHub-hosted windows-latest runners resolves to the constrained system C:
drive. BackupService.CreateBackupAsync requires 5GiB free at the backup path
before starting, and the C: drive's free temp space can dip below that,
failing CreateBackupAsync_WithCorruptKeyframeDataRow_SkipsRowAndCompletesBackup
even though the fix itself is correct. Rooting the test directory under
AppContext.BaseDirectory keeps it on the same (much larger) drive as the repo
checkout on all platforms, without touching the real BackupService free-space
check.
|
|
Addresses review feedback from @Bond-009 on PR #17370: the test helper
InvokeUpdateItem was invoking the private UpdateItem(BaseItemDto, BaseItem)
method via reflection. Jellyfin.Api.csproj already grants
InternalsVisibleTo("Jellyfin.Api.Tests"), so the method is changed to
internal and the test now calls it directly, removing the
GetMethod/Invoke boilerplate.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
|
security-path-traversal-fixes
# Conflicts:
# Jellyfin.Api/Controllers/HlsSegmentController.cs
# Jellyfin.Api/Controllers/PluginsController.cs
|
