Embedded subtitle provider fails when filename is too long

[mightyguava]

Describe the bug
When using the embedded subtitle provider to extract embedded ASS subtitles, if video file name is almost 255 characters, the ffmpeg command can add an extension for the extracted subtitles that causes the file to exceed 255 characters, causing it to fail on ext4 and zfs filesystems with "Filename too long".

Consequently, the provider gets throttled for 10 minutes. Being the only provider on my Bazarr instance, the set of non-throttled providers becomes 0, and all other wanted files fail to download subtitles.

Output from ffmpeg:

/config/cache/embeddedsubtitlesprovider/Kaguya-sama - Love Is War (2019) - S01E11 - 011 - Ai Hayasaka Wants to Get Soaked Chika Fujiwara Really Wants to Eat It Miyuki Shirogane Wants to See You I Can't Hear the... [Multi-Audio HDTV-1080p][8bit][h264][AAC 2.0][EN+JA+PT+ES]-DragsterPS.es-MX.ass.ass: Filename too long

To Reproduce
Try to use the embedded subtitle provider with a file with a really long filename. The one I specifically had issues with is

Kaguya-sama - Love Is War (2019) - S01E11 - 011 - Ai Hayasaka Wants to Get Soaked Chika Fujiwara Really Wants to Eat It Miyuki Shirogane Wants to See You I Can't Hear the... [Multi-Audio HDTV-1080p][8bit][h264][AAC 2.0][EN+JA+PT+ES]-DragsterPS.mkv

The provider wants to write subs to a file named

Kaguya-sama - Love Is War (2019) - S01E11 - 011 - Ai Hayasaka Wants to Get Soaked Chika Fujiwara Really Wants to Eat It Miyuki Shirogane Wants to See You I Can't Hear the... [Multi-Audio HDTV-1080p][8bit][h264][AAC 2.0][EN+JA+PT+ES]-DragsterPS.es-MX.ass.ass

which is 257 characters long.

Expected behavior
I see 2 options:

1. The embedded provider should truncate the filename, or compute a SHA digest like in Datatables warning and OSError - Subtitles not found #1313 instead of using the full file name for the cache keys.
2. Don't throttle / discard the embedded provider because it doesn't fail due to network failures and such.

Software (please complete the following information):

• Bazarr: v 1.2.4
• Sonarr version v 3.0.10.1567
• OS: docker linuxserver/bazarr on Synology

[morpheus65535]

Option #1 isn't possible. Better dealing with throttling is the only other option I see for those poor file system that can't support long filename in 2023.

Can you provide the full debug log while reproducing the throttling?

@vitiko98 can you take a look at it please?

[mightyguava]

I'm trying to extract subtitles on my whole Sonarr library for the first time so the debug logs are going to be a bit difficult (~2000 files on the wanted list)... I imagine that'll be tens of megabytes at least and will take hours to generate, and sift through. Is this non-debug log ok?

04/09/2023 20:58:23|INFO    |root                            |Throttling embeddedsubtitles for 10 minutes, until 23/09/04 21:08, because of: ExtractionError. Exception info: 'Error calling ffmpeg: Command \'[\'/usr/bin/ffmpeg\', \'-v\', \'quiet\', \'-y\', \'-i\', "/media/Anime/Kaguya-sama - Love Is War/Season 01/Kaguya-sama - Love Is War (2019) - S01E11 - 011 - Ai Hayasaka Wants to Get Soaked Chika Fujiwara Really Wants to Eat It Miyuki Shirogane Wants to See You I Can\'t Hear the... [Multi-Audio HDTV-1080p][8bit][h264][AAC 2.0][EN+JA+PT+ES]-DragsterPS.mkv", \'-map\', \'0:5\', \'-c:s\', \'copy\', \'-f\', \'ass\', "/config/cache/embeddedsubtitlesprovider/Kaguya-sama - Love Is War (2019) - S01E11 - 011 - Ai Hayasaka Wants to Get Soaked Chika Fujiwara Really Wants to Eat It Miyuki Shirogane Wants to See You I Can\'t Hear the... [Multi-Audio HDTV-1080p][8bit][h264][AAC 2.0][EN+JA+PT+ES]-DragsterPS.en.ass.ass", \'-map\', \'0:6\', \'-c:s\', \'copy\', \'-f\', \'ass\', "/config/cache/embeddedsubtitlesprovider/Kaguya-sama - Love Is War (2019) - S01E11 - 011 - Ai Hayasaka Wants to Get Soaked Chika Fujiwara Really Wants to Eat It Miyuki Shirogane Wants to See You I Can\'t Hear the... [Multi-Audio HDTV-1080p][8bit][h264][AAC 2.0][EN+JA+PT+ES]-DragsterPS.es-MX.ass.ass", \'-map\', \'0:7\', \'-c:s\', \'copy\', \'-f\', \'ass\', "/config/cache/embeddedsubtitlesprovider/Kaguya-sama - Love Is War (2019) - S01E11 - 011 - Ai Hayasaka Wants to Get Soaked Chika Fujiwara Really Wants to Eat It Miyuki Shirogane Wants to See You I Can\'t Hear the... [Multi-Audio HDTV-1080p][8bit][h264][AAC 2.0][EN+JA+PT+ES]-DragsterPS.pt-BR.ass.ass"]\' returned non-zero exit status 1.'|
04/09/2023 20:58:23|INFO    |root                            |BAZARR All providers are throttled|
04/09/2023 20:58:23|INFO    |root                            |BAZARR Finished searching for missing Series Subtitles. Check History for more information.|
04/09/2023 22:19:02|INFO    |root                            |BAZARR Finished searching for Subtitles to upgrade. Check History for more information.|

I assume the code is just short-circuiting in this loop here

bazarr/bazarr/subtitles/wanted/series.py

Lines 76 to 83 in 07697fa

	for episode in episodes_details:
	providers_list = get_providers()
	if providers_list:
	_wanted_episode(episode)
	else:
	logging.info("BAZARR All providers are throttled")
	break

for those poor file system that can't support long filename in 2023.

I feel the pain at that sentiment. But ext4, zfs, and btrfs are probably the most common filesystems used for servers and they all only support up to 255 chars. It's probably worthwhile to work well with them?

[morpheus65535]

I feel the pain at that sentiment. But ext4, zfs, and btrfs are probably the most common filesystems used for servers and they all only support up to 255 chars. It's probably worthwhile to work well with them?

I totally agree, sorry for the unnecessary rough comment.

I'm pretty sure that, from the log you provided, we'll be able to add something to catch the exception and simply carry over to the next one. Unfortunately, it may result in retrying to extract the same subtitles on the next search task occurrence. I'll let vitiko look at it, maybe he have something in mind. ;-)

[vitiko98]

Should be fixed in upcoming beta. Thanks for the report!

[mightyguava]

Worked for me in beta 26, thanks!