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.
Explicitly set StandardErrorEncoding and StandardOutputEncoding to
Encoding.UTF8 when invoking the FFmpeg subprocess.
This prevents log encoding issues and character corruption on Windows
environments that default to non-UTF8 ANSI code pages.
This fixes garbled metadata and font names in the FFmpeg logs.
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
* Cleanup extracted files
* Pagination and fixes
* Add migration for attachments to MigrateLibraryDb
* Unify attachment handling
* Don't extract again if files were already extracted
* Fix MKS attachment extraction
* Always run full extraction on mks
* Don't try to extract mjpeg streams as attachments
* Fallback to check if attachments were extracted to cache folder
* Fixup
FFmpeg deletes segments based on its own transcoding progress,
but we need to delete segments based on client download progress.
Since disk and GPU speeds vary, using hlsenc's built-in deletion
will result in premature deletion of some segments. As a consequence,
the server has to constantly respin new ffmpeg instances, resulting
in choppy video playback.
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
gnattu