Describe the bug
Uploading one subtitle (via the API used by third-party tools, e.g. Subtitlarr) results in Bazarr's history page showing that same upload logged multiple times, all with the identical timestamp. The number of duplicate rows always matches the number of desired/configured languages on that item's profile, not the number of files actually uploaded.
Here's an artifact with basically the same information
https://claude.ai/code/artifact/2ff35bc4-e027-477a-96a5-5f6f8a5f5614?via=auto_preview
To Reproduce
- Configure a movie/series profile with multiple desired languages (e.g. EN, ES, CA, IT).
- Upload a single subtitle in one language (e.g. Catalan) via POST /api/movies/subtitles (or /api/episodes/subtitles), a single call, single file.
- Open the item's history in the UI.
Expected behavior
One uploaded file should produce one history entry.
Screenshots
Software (please complete the following information):
- Bazarr: latest as of posting date
- OS: unraid
extra info
The history table shows one entry per desired language configured on the profile, all sharing the exact same timestamp, even though only one language's subtitle was ever sent.
Example (movie "Blended", profile with 4 desired languages: EN/ES/CA/IT, only Catalan translated and uploaded):
Name Language Date
Blended Catalan 08/26/26 09:57:52
Blended Catalan 08/26/26 09:57:52
Blended Catalan 08/26/26 09:57:52
Blended Catalan 08/26/26 09:57:52
Same behavior observed on TV show profiles (4 desired languages -> 4 duplicate rows) and anime profiles (2 desired languages -> 2 duplicate rows) - the duplicate count consistently tracks the profile's language count, not the upload count.
Investigation on the sending side
Before filing, I traced the client application's (Subtitlarr) own code and logs to rule out it sending multiple requests:
The client's outbound HTTP log shows exactly one POST request to /api/movies/subtitles for this item, receiving a single 204 No Content response, one second before the four duplicate rows appear in Bazarr's history.
No loop, retry, or per-language fan-out exists anywhere in the client's upload code path — verified by reading the full call chain from translation to upload.
The client's internal data model stores one record per (item, language) pair, so a single-language translation cannot itself expand into multiple upload attempts.
This points to the duplication happening inside Bazarr's own history-write logic when processing an incoming subtitle upload - it appears to write one history row per desired-language slot configured on the item's profile, rather than one row for the actual file received.
Describe the bug
Uploading one subtitle (via the API used by third-party tools, e.g. Subtitlarr) results in Bazarr's history page showing that same upload logged multiple times, all with the identical timestamp. The number of duplicate rows always matches the number of desired/configured languages on that item's profile, not the number of files actually uploaded.
Here's an artifact with basically the same information
https://claude.ai/code/artifact/2ff35bc4-e027-477a-96a5-5f6f8a5f5614?via=auto_preview
To Reproduce
Expected behavior
One uploaded file should produce one history entry.
Screenshots
Software (please complete the following information):
extra info
The history table shows one entry per desired language configured on the profile, all sharing the exact same timestamp, even though only one language's subtitle was ever sent.
Example (movie "Blended", profile with 4 desired languages: EN/ES/CA/IT, only Catalan translated and uploaded):
Name Language Date
Blended Catalan 08/26/26 09:57:52
Blended Catalan 08/26/26 09:57:52
Blended Catalan 08/26/26 09:57:52
Blended Catalan 08/26/26 09:57:52
Same behavior observed on TV show profiles (4 desired languages -> 4 duplicate rows) and anime profiles (2 desired languages -> 2 duplicate rows) - the duplicate count consistently tracks the profile's language count, not the upload count.
Investigation on the sending side
Before filing, I traced the client application's (Subtitlarr) own code and logs to rule out it sending multiple requests:
The client's outbound HTTP log shows exactly one POST request to /api/movies/subtitles for this item, receiving a single 204 No Content response, one second before the four duplicate rows appear in Bazarr's history.
No loop, retry, or per-language fan-out exists anywhere in the client's upload code path — verified by reading the full call chain from translation to upload.
The client's internal data model stores one record per (item, language) pair, so a single-language translation cannot itself expand into multiple upload attempts.
This points to the duplication happening inside Bazarr's own history-write logic when processing an incoming subtitle upload - it appears to write one history row per desired-language slot configured on the item's profile, rather than one row for the actual file received.