Bazarr+ v2.5.2 (Murmuration)
Codename: Murmuration (Provider Hub patch on the v2.5 line).
v2.5.1 tightened the multi-instance formation. v2.5.2 is a focused Provider Hub fix: WhisperAI transcriptions that legitimately take longer than 30 seconds are no longer killed mid-flight, no matter what timeouts you had configured. It also adds a global "default worker timeout" setting so the general case the reporter asked about is tunable too. No schema changes, no breaking changes.
Headline: WhisperAI transcriptions no longer die at 30 seconds
If you pointed Bazarr+ at a self-hosted Whisper service as a last-resort provider, every transcription was cut off after ~30 seconds and failed, regardless of the response and transcription timeouts you set on the provider (#288). Setting transcription to 600s or 3600s made no difference; the worker was killed at 30.
Root cause
WhisperAI is a migrated built-in, so on Bazarr+ it runs inside a Provider Hub worker subprocess. The host that supervises that subprocess enforces a deadline and kills the worker when it expires. That deadline was computed from a hardcoded 30-second default and only recognized the config keys worker_timeout / timeout_seconds / timeout. WhisperAI's Provider Hub config declares response_timeout_seconds and transcription_timeout_seconds, which matched none of those keys, so the deadline stayed at 30s. Your configured timeouts only ever bounded the HTTP calls inside the worker; the host guillotined the whole subprocess first.
The fix
The host-side worker deadline now derives from whatever timeouts a plugin actually declares (any *_timeout_seconds key, plus the legacy keys), padded with a small margin so the worker's own timeout fires cleanly before the host steps in, and capped at 24 hours (raised from the previous 1-hour ceiling so a long transcription is never silently re-clipped). For a config of response 600 / transcription 3600, the worker is now given 3630 seconds instead of 30.
Upgrading with a WhisperAI provider that kept failing on long files? Just update and restart. Your existing response/transcription timeouts now take effect, no reconfiguration needed.
New setting: Default worker timeout
The reporter also asked for a general, tunable worker timeout. There is now a Default worker timeout setting under Settings → General → Provider Hub (default 120 seconds, range 30–86400).
It is the fallback deadline for any Provider Hub plugin that does not declare its own timeouts. Plugins that do declare a longer timeout (like WhisperAI's transcription timeout) raise the deadline above this value, so this is a floor, not a cap.
Verification
Beyond unit coverage, the fix was verified end to end against a real Whisper ASR service through the real worker machinery: a genuine 95-second transcription completes under the new deadline, and is killed at exactly 30 seconds under the old one, reproducing and then resolving the reported failure.
CI / Docker
- Release-only image publishing is unchanged: Docker images publish on a push to
masterand on av*tag (build-docker.yml); the GitHub Pages site deploys fromsite/onmaster. - A new backend test module (
test_provider_hub_worker_timeout.py) was added to the CI guard-list, so the timeout derivation, floor, margin, cap, and fallback are all covered on every run.
Dependency Updates
None in this release. v2.5.2 is a focused code fix with no dependency changes.
Database Migrations
No schema changes in this release. The new setting lives in the normal configuration and is created with its default on first start. Single-instance and PostgreSQL installs are unaffected. Nothing to do manually.
Included Pull Requests
Contributors
- Thanks to Aracnoss for the clear, reproducible bug report (#288) that made the root cause easy to pin down.
Upgrade / Migration Notes
- No breaking changes. Update and restart as usual.
- A WhisperAI provider that was timing out at 30s starts working on this upgrade with your existing timeout settings; no reconfiguration required.
- The new Default worker timeout defaults to 120s and only acts as a fallback; you do not need to touch it unless you run a plugin that declares no timeout of its own.
- PostgreSQL remains fully supported and first-class.
Full Changelog: v2.5.1...v2.5.2