* 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>
Season and episode directories/files can now include provider ID
attributes in their names (e.g. "Season 01 [tvdbid=22222]" or
"Show S01E01 [tmdbid=99999].mkv"), consistent with the existing
behavior for series folders.
Supported providers: imdbid, tvdbid, tvmazeid, tmdbid.
Adds TmdbSeasonExternalId and TmdbEpisodeExternalId so that
the TMDB season and episode IDs are surfaced in the metadata editor.
Seasons do not have their own IMDb IDs, so we don't support imdbid parsing
in SeasonResolver. Instead, generate IMDb season URLs via
ImdbExternalUrlProvider using the parent series' IMDb ID and the
season number, matching the IMDb URL format:
imdb.com/title/{seriesId}/episodes/?season={N}
Add tests for the ExternalUrlProviders.
When "replace all metadata" was issued on a film, with the Web metadata
scrapers and "save to local metadata" disabled, after changing the
.nfo file, 'Community rating' was not updated in the server, remaining
the cached value.
Fixed by changing the flag on the 'MergeData' call
(line 809 - MetadataService.cs) to use the option defined by the
user and not the erroneous absolute 'false' value.
Also, in the .nfo parser an option for 'communityrating' was added
along with value conformity verifiers.
Validation tests were added.
A direct implementation using DriveInfo directly on a path does not work
as expected. The method will return a DriveInfo object with the given
path as both the Name and the RootDirectory, which is not helpful.
Instead, add parsing logic to find the best possible match out of all
filesystems on the system for the path, including handling edge cases
involving symlinked paths in the chain.
This ensures that the resulting DeviceId is a valid filesystem, allowing
it to be used in the UI to show a better description. It also includes
the new ResolvedPath which will show, if required, what the Path
resolved to after all symlinks are interpolated.
One possible issue here is that walking all drives as-is might become
slow(er) on a system with many partitions, but even on my
partition-heavy system with over a dozen ZVOLs and remote mounts, this
takes under 0.4 seconds including runup time for `dotnet run`, so I
imagine this should be fine.
theguymadmax