[PR #14960] [MERGED] Fix LUFS detection deadlock per issue #13697 #14199

New Issue

OVERLORD · 2026-02-07T07:26:04+03:00

OVERLORD commented

2026-02-07 07:26:04 +03:00

📋 Pull Request Information

Original PR: https://github.com/jellyfin/jellyfin/pull/14960
Author: @karm235
Created: 10/7/2025
Status: ✅ Merged
Merged: 10/12/2025
Merged by: @joshuaboniface

Base: master ← Head: 13697-fix-lufs-detection

📝 Commits (2)

51e20a1 Fix LUFS detection deadlock on albums with verbose output
6097045 cleanup

📊 Changes

1 file changed (+11 additions, -3 deletions)

View changed files

📝 Emby.Server.Implementations/ScheduledTasks/Tasks/AudioNormalizationTask.cs (+11 -3)

📄 Description

The current implementation of the Audio Normalization task has a deadlock issue when scanning albums containing tracks with non-uniform sample rates (e.g., an album where most tracks are 48kHz but one is 96kHz). The task hangs during album LUFS calculation because ffmpeg generates verbose output about sample rate conversions, but the code stops reading stderr after finding the LUFS value.

Root Cause
When processing albums with mismatched sample rates, ffmpeg outputs additional warnings/messages to stderr while resampling. The original code used break to exit the loop immediately after finding the LUFS value, which stopped reading from stderr. This causes ffmpeg's stderr buffer to fill up, and ffmpeg blocks waiting for the buffer to drain, resulting in a deadlock.

Changes
Replaced the break statement in CalculateLUFSAsync with a foundLufs flag that allows the loop to continue reading and draining ffmpeg's stderr stream after the LUFS value is found. This prevents the deadlock by ensuring the stderr buffer never fills up,regardless of how verbose ffmpeg's output is.

Issues
Fixes #13697

Remarks
In my testing of this issue I never got the "Failed to find LUFS value in output" error; it simply hung. This should fix that issue based on the original description of the issue, though.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/jellyfin/jellyfin/pull/14960 **Author:** [@karm235](https://github.com/karm235) **Created:** 10/7/2025 **Status:** ✅ Merged **Merged:** 10/12/2025 **Merged by:** [@joshuaboniface](https://github.com/joshuaboniface) **Base:** `master` ← **Head:** `13697-fix-lufs-detection` --- ### 📝 Commits (2) - [`51e20a1`](https://github.com/jellyfin/jellyfin/commit/51e20a14c29b67bf9e8c0bbf9e92f1fe406062c3) Fix LUFS detection deadlock on albums with verbose output - [`6097045`](https://github.com/jellyfin/jellyfin/commit/6097045d71b4518cc118a98917125927c676e128) cleanup ### 📊 Changes **1 file changed** (+11 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `Emby.Server.Implementations/ScheduledTasks/Tasks/AudioNormalizationTask.cs` (+11 -3) </details> ### 📄 Description The current implementation of the Audio Normalization task has a deadlock issue when scanning albums containing tracks with non-uniform sample rates (e.g., an album where most tracks are 48kHz but one is 96kHz). The task hangs during album LUFS calculation because ffmpeg generates verbose output about sample rate conversions, but the code stops reading stderr after finding the LUFS value. **Root Cause** When processing albums with mismatched sample rates, ffmpeg outputs additional warnings/messages to stderr while resampling. The original code used break to exit the loop immediately after finding the LUFS value, which stopped reading from stderr. This causes ffmpeg's stderr buffer to fill up, and ffmpeg blocks waiting for the buffer to drain, resulting in a deadlock. **Changes** Replaced the break statement in CalculateLUFSAsync with a foundLufs flag that allows the loop to continue reading and draining ffmpeg's stderr stream after the LUFS value is found. This prevents the deadlock by ensuring the stderr buffer never fills up,regardless of how verbose ffmpeg's output is. **Issues** Fixes #13697 **Remarks** In my testing of this issue I never got the "Failed to find LUFS value in output" error; it simply hung. This *should* fix that issue based on the original description of the issue, though. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

OVERLORD added the pull-request label 2026-02-07 07:26:04 +03:00

OVERLORD closed this issue

2026-02-07 07:26:06 +03:00

Sign in to join this conversation.

Branches Tags

master

renovate/major-skiasharp-monorepo

renovate/sharpcompress-0.x

renovate/svg.skia-5.x

renovate/ghcr.io-devcontainers-features-docker-in-docker-4.x

release-10.11.z

standards-fix

release-10.9.z

openapi-cache

release-10.10.z

explicit-load

explicit-load-v2

feature/entity-framework

only-count-folder-item

fix/ci-workflow-refactor

release-10.8.z

release-10.7.z

EraYaN-add-management-interface

release-10.6.z

release-10.5.z

release-10.4.z

release-10.3.z

release-10.2.z

release-10.1.0

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#14199