| Age | Commit message (Collapse) | Author |
|---|
|
Fix concurrent ffmpeg segment racing
|
|
Improve People deduplication, fix search and restrict ItemByName responses
|
|
Fix PCM audio transcoding to wav returning HTTP 500 and headerless output
|
|
`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
|
|
Fix AdjacentTo being ignored on non-recursive item queries
|
|
# Conflicts:
# src/Jellyfin.Database/Jellyfin.Database.Providers.Sqlite/Migrations/JellyfinDbModelSnapshot.cs
|
|
and type
|
|
Fix (Un)Played filter correctness and performance
|
|
Allow duplicate LinkedChildren for Playlists
|
|
|
|
|
|
|
|
user can access
|
|
|
|
|
|
Fix series merging
|
|
Fix incorrect year on local trailers
|
|
|
|
Fix play queue index handling in SyncPlay
|
|
|
|
|
|
|
|
|
|
TheMelmacian/feature/library_specific_language_filter_values
Improve language filters to only fetch language codes that match the requested items/libraries (follow up to #9787)
|
|
|
|
security-path-traversal-fixes
# Conflicts:
# Jellyfin.Api/Controllers/HlsSegmentController.cs
# Jellyfin.Api/Controllers/PluginsController.cs
|
|
Exempt people from the allowed tags visibility check
|
|
extract page count from archives and PDFs
|
|
Add XML docs to small entity interfaces and remove CS1591 suppressions
|
|
|
|
Fix format negotiation in hybrid SW decode and CUDA tonemap pipeline
|
|
Remove episode image override hack
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The CUDA hwcontext in FFmpeg 8.1 has added support for 10bit
fully-planar formats, but few CUDA filters support them.
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
|
|
|
|
|
|
|
|
Fixes for multi version handling
|
|
Three index bugs in PlayQueueManager, two of which leave
PlayingItemIndex out of bounds, making every subsequent Buffering/Ready
request throw and leaving the group unusable until it empties:
- RemoveFromPlaylist did not compensate for removed items preceding the
playing item: removing the playing item together with earlier items
could select the wrong item or crash with an out-of-bounds index.
- Next/Previous on an empty playlist with RepeatOne/RepeatAll reported
success or set PlayingItemIndex to 0 on an empty list, crashing
downstream in Group and corrupting the index.
- SetPlayingItemByIndex accepted an index equal to the playlist count
(latent off-by-one, callers currently pre-validate).
|
|
|
|
|
