Describe the bug
When the Lingarr translator (translator_type: lingarr) fails, the logged error carries no identifying information about which file/episode/movie failed - just the raw exception string. There is no way to correlate a failed translation back to the media item that caused it, either from the log or from History (History only ever gets a row on success).
To Reproduce
- Configure Bazarr with
translator_type: lingarr pointing at a Lingarr instance.
- Trigger a translation on a file that ends up failing on the Lingarr side (rate limit, timeout, connection drop, etc.) - in my case Lingarr's own job runner has a 30-minute processing ceiling, so any file that takes longer than that on a slow AI backend reliably reproduces this.
- Check
bazarr.log for the resulting error.
Example from my logs:
2026-08-16 17:59:10,698 - bazarr.subtitles.tools.translate.services.lingarr_translator (79e3ef74fb30) : ERROR (lingarr_translator:109) - BAZARR encountered an error during Lingarr translation: Request timed out
2026-08-16 17:59:10,700 - root (79e3ef74fb30) : ERROR (main:85) - Translation failed: Request timed out
Neither line says what timed out. Across 54 occurrences of this pattern in my logs, I cannot tell which episodes/movies were affected without cross-referencing timestamps against Sonarr/Radarr activity by hand.
Expected behavior
The error log should include the source file path (or title/media type/id) that was being translated, since that context is already available in the code that's raising/catching the exception - it's just not included in the message.
Looking at bazarr/subtitles/tools/translate/services/lingarr_translator.py:
_translate_content()'s except blocks (requests.exceptions.Timeout, ConnectionError, RequestException, etc., around lines 165-181) log generic messages like 'Lingarr API request timed out' at debug level with no context, then raise a bare RequestError("Request timed out").- That bubbles up to
translate()'s outer except Exception as e: logger.error(f'BAZARR encountered an error during Lingarr translation: {str(e)}') (line 109) - by this point self.source_srt_file, self.video_path, and the title fetched via get_title(...) are all still in scope as instance attributes, but the log message only prints str(e).
Including self.source_srt_file (or self.video_path/title) in that final log line - and ideally in the intermediate debug lines too, promoted to error - would make these failures traceable without any behavior change.
Additional context
Separately, and possibly related: _translate_content() uses a hardcoded timeout=1800 for the request to Lingarr - which happens to line up almost exactly with Lingarr's own internal 30-minute Hangfire job-cancellation ceiling (reported upstream). With no margin between the two, any translation that's genuinely still progressing (just slow, e.g. a small local model) times out on the Bazarr side at essentially the same moment Lingarr's own job runner kills it - so this failure mode is easy to hit on modest hardware, which is presumably why I'm seeing it 54 times without much effort. Not asking for a fix here since the real ceiling lives in Lingarr, but flagging it as the likely reason this shows up in practice.
Software (please complete the following information):
- Bazarr: v1.6.0
- OS: Linux (Docker, linuxserver.io image)
Describe the bug
When the Lingarr translator (
translator_type: lingarr) fails, the logged error carries no identifying information about which file/episode/movie failed - just the raw exception string. There is no way to correlate a failed translation back to the media item that caused it, either from the log or from History (History only ever gets a row on success).To Reproduce
translator_type: lingarrpointing at a Lingarr instance.bazarr.logfor the resulting error.Example from my logs:
Neither line says what timed out. Across 54 occurrences of this pattern in my logs, I cannot tell which episodes/movies were affected without cross-referencing timestamps against Sonarr/Radarr activity by hand.
Expected behavior
The error log should include the source file path (or title/media type/id) that was being translated, since that context is already available in the code that's raising/catching the exception - it's just not included in the message.
Looking at
bazarr/subtitles/tools/translate/services/lingarr_translator.py:_translate_content()'s except blocks (requests.exceptions.Timeout,ConnectionError,RequestException, etc., around lines 165-181) log generic messages like'Lingarr API request timed out'atdebuglevel with no context, then raise a bareRequestError("Request timed out").translate()'s outerexcept Exception as e: logger.error(f'BAZARR encountered an error during Lingarr translation: {str(e)}')(line 109) - by this pointself.source_srt_file,self.video_path, and thetitlefetched viaget_title(...)are all still in scope as instance attributes, but the log message only printsstr(e).Including
self.source_srt_file(orself.video_path/title) in that final log line - and ideally in the intermediatedebuglines too, promoted toerror- would make these failures traceable without any behavior change.Additional context
Separately, and possibly related:
_translate_content()uses a hardcodedtimeout=1800for the request to Lingarr - which happens to line up almost exactly with Lingarr's own internal 30-minute Hangfire job-cancellation ceiling (reported upstream). With no margin between the two, any translation that's genuinely still progressing (just slow, e.g. a small local model) times out on the Bazarr side at essentially the same moment Lingarr's own job runner kills it - so this failure mode is easy to hit on modest hardware, which is presumably why I'm seeing it 54 times without much effort. Not asking for a fix here since the real ceiling lives in Lingarr, but flagging it as the likely reason this shows up in practice.Software (please complete the following information):