This patch fixes issue #16032 where the Playlists media folder ignored a user-uploaded Primary image and kept showing the generated collage. The root cause was DTO image precedence on UserView items for CollectionType.playlists. We now prefer the display parent (PlaylistsFolder) Primary image when available by clearing the UserView Primary tag and setting ParentPrimaryImageItemId/ParentPrimaryImageTag. Added tests cover both paths: parent custom image preferred, and fallback to existing UserView Primary when parent has none.
* Add underscore and dot as multi-version file separators
Extend IsEligibleForMultiVersion to recognize _ and . as valid
separators between the base movie name and the version suffix.
Common naming patterns like 'Movie_4K.mkv' or 'Movie.UHD.mkv'
are now correctly grouped as alternate versions during library scan.
* Address review: remove comment, add 3D recognition assertions
---------
Co-authored-by: aimarshall615-creator <aimarshall615@gmail.com>
* fix: cap GetVideoBitrateParamValue at 400 Mbps
The previous cap of int.MaxValue / 2 (~1073 Mbps) is far beyond any
realistic transcode target and allows encoder parameters derived from
it (e.g. -bufsize = bitrate * 4 for QSV) to grow to multi-gigabit
values, which is incorrect regardless of whether the encoder tolerates it.
400 Mbps is a safe upper bound for all current hardware encoders:
- Intel QSV H.264 peaks at ~300 Mbps (High 5.1 CPB = 168.75 Mbit)
- HEVC High Tier Level 5.x supports ~240 Mbps
- AV1 hardware encoders have no meaningful real-world constraint at
this level
The existing FallbackMaxStreamingBitrate mechanism (default 30 Mbps)
provides a similar guard but only when LiveStreamId is set, covering
M3U and HDHR sources. Plugin-provided streams and any source that
bypasses the LiveTV pipeline are not subject to it and can pass
unreasonably high values downstream. This cap closes that gap for
all encoder paths.
Suggested by @nyanmisaka in review of #16376.
* Update MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs
---------
Co-authored-by: Bond-009 <bond.009@outlook.com>
* Add spec-compliant dvh1 HLS variant for Dolby Vision Profile 5
DV Profile 5 has no backward-compatible base layer, so
SUPPLEMENTAL-CODECS cannot be used. The master playlist
currently labels P5 streams as hvc1 in the CODECS field,
even though DynamicHlsController already passes
-tag:v:0 dvh1 -strict -2 to FFmpeg for P5 copy-codec
streams, writing a dvh1 FourCC and dvvC configuration box
into the fMP4 init segment. This mismatch between the
manifest (hvc1) and the bitstream (dvh1) causes
spec-compliant clients like Apple TV and webOS 24+ to set
up an HDR10 pipeline instead of a Dolby Vision one.
Add a dvh1 variant before the existing hvc1 variant for P5
copy-codec streams. Both variants point to the same stream
URL. Spec-compliant clients select dvh1 and activate the
DV decoder path. Legacy clients that reject dvh1 in CODECS
fall through to the hvc1 variant and detect DV from the
init segment, preserving existing behavior.
Fixes#16179
* Address review: support AV1 DoVi P10, add client capability check
- GetDoviString: add isAv1 parameter, return dav1 FourCC for AV1 DoVi
(P10 bl_compat_id=0) and dvh1 for HEVC DoVi (P5)
- Remove redundant IsDovi() check; VideoRangeType.DOVI is sufficient
and correctly limits to profiles without a compatible base layer
- Replace IsDoviRemoved() with client capability check using
GetRequestedRangeTypes(state.VideoStream.Codec) to only emit the
dvh1/dav1 variant for clients that declared DOVI support
- Update comments and doc summary to reflect P5 + P10/bl0 scope
* Use codec string instead of boolean for DoVi FourCC mapping
Replace bool isAv1 with string codec in GetDoviString for
future-proofing when DoVi extends to H.266/VVC or AV2.
* Move AppendDoviPlaylist next to AppendPlaylist
* Fix SA1508: remove blank line before closing brace
* Use AppendLine() instead of Append(Environment.NewLine)
When a stalled HLS client sends ReportPlaybackStopped with a negative
PositionTicks (e.g. HLS.js reporting position on buffer stall), the
ArgumentOutOfRangeException was thrown before GetSession was called,
causing CloseLiveStreamIfNeededAsync to never run. This left the
ILiveStream.ConsumerCount permanently incremented, permanently holding
a tuner open with no active viewer.
Fix by acquiring the session and performing live stream cleanup before
throwing the validation exception, so tuner resources are always freed
even when playback reporting fails with invalid position data.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Joshua M. Boniface