You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Filenames for external subtitle files for hearing impaired captions end in either .hi or .sdh
So I have files that will end in .en.hi or .en.sdh for English hearing imparied files.
I've tried numerous combinations, including using the 3 letter code eng.hi, eng.sdh etc, but ineviitably Medusa strips the language code and only keeps the .sdh or .hi. These are then recognised in players like Plex as Hindi or Southern Kurdish, rather than English SDH which is incredibly frustrating.
Can you either confirm what the required naming convention needs to be, or update the Subtitles.py to cater for this properly?
Separate note - Logs don't seem to clearly indicate processing of any enternal subtitle files - would be great if these were also updated to confirm processing of these files (and any renaming like below).
To Reproduce
Steps to reproduce the behavior:
Place in post-processing folder the following files:
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.en.srt
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.en.hi.srt
... after processing the proccessed files will become
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.en.srt
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.hi.srt
Expected behavior
language code + hi/sdh should be retained on subtitle post processing.
Debug logs (at least 50 lines):
General > Advanced Settings > Enable debug
2024-03-25 14:24:03 INFO POSTPROCESSQUEUE-POST-PROCESS :: Completed Postproccessing
2024-03-25 14:24:03 INFO POSTPROCESSQUEUE-POST-PROCESS :: Post-processing completed.
2024-03-25 14:24:03 INFO POSTPROCESSQUEUE-POST-PROCESS :: Processing succeeded for /share/TV/_PostProcessing/American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4
2024-03-25 14:24:02 INFO POSTPROCESSQUEUE-POST-PROCESS :: 73141: No subtitles found for American Dad! S20E16
2024-03-25 14:24:02 WARNING SNATCHQUEUE-SNATCH-402910 :: Torrent file content is empty: Abbott.Elementary.S02E16.Teachers.Conference.1080p.AMZN.WEB-DL.DDP5.1.H.264-NTb[TGx]
2024-03-25 14:24:01 INFO POSTPROCESSQUEUE-POST-PROCESS :: No subtitles found for American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4
2024-03-25 14:24:01 INFO POSTPROCESSQUEUE-POST-PROCESS :: No show id found for 'American Dad!' ({'year': 2005})
2024-03-25 14:24:01 INFO POSTPROCESSQUEUE-POST-PROCESS :: Series American Dad! not found in show ids
2024-03-25 14:24:00 INFO POSTPROCESSQUEUE-POST-PROCESS :: Trying to clean any empty folder under /share/TV/TV/American Dad
2024-03-25 14:23:48 INFO POSTPROCESSQUEUE-POST-PROCESS :: This download is marked a priority download so I'm going to replace an existing file if I find one
2024-03-25 14:23:48 INFO POSTPROCESSQUEUE-POST-PROCESS :: New size: 98.65 MB
2024-03-25 14:23:48 INFO POSTPROCESSQUEUE-POST-PROCESS :: New file: /share/TV/_PostProcessing/American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4
2024-03-25 14:23:47 INFO POSTPROCESSQUEUE-POST-PROCESS :: Checking /share/TV/_PostProcessing/American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4 for minimal one video and audio stream
2024-03-25 14:23:46 INFO POSTPROCESSQUEUE-POST-PROCESS :: Processing /share/TV/_PostProcessing/American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4
2024-03-25 14:23:46 INFO POSTPROCESSQUEUE-POST-PROCESS :: Processing path: /share/TV/_PostProcessing
2024-03-25 14:23:46 INFO POSTPROCESSQUEUE-POST-PROCESS :: Beginning postprocessing for path /share/TV/_PostProcessing and resource None
Describe the bug
Filenames for external subtitle files for hearing impaired captions end in either .hi or .sdh
So I have files that will end in .en.hi or .en.sdh for English hearing imparied files.
I've tried numerous combinations, including using the 3 letter code eng.hi, eng.sdh etc, but ineviitably Medusa strips the language code and only keeps the .sdh or .hi. These are then recognised in players like Plex as Hindi or Southern Kurdish, rather than English SDH which is incredibly frustrating.
Can you either confirm what the required naming convention needs to be, or update the Subtitles.py to cater for this properly?
Separate note - Logs don't seem to clearly indicate processing of any enternal subtitle files - would be great if these were also updated to confirm processing of these files (and any renaming like below).
To Reproduce
Steps to reproduce the behavior:
Place in post-processing folder the following files:
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.en.srt
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.en.hi.srt
... after processing the proccessed files will become
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.mp4
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.en.srt
American Dad! S20E16 A New Era for the Smith House 1080p WEB-DL Ntb.hi.srt
Expected behavior
language code + hi/sdh should be retained on subtitle post processing.
Screenshots
After
Medusa (please complete the following information):
Medusa Info: | Branch: master
Commit: Unknown
Version: 1.0.19
Database: 44.19
Python Version: | 3.11.8 (main, Feb 19 2024, 17:01:17) [GCC 13.2.1 20231014]
SSL Version: | OpenSSL 3.1.4 24 Oct 2023
OS: | Linux-5.10.60-qnap-x86_64-with
Locale: | en_US.UTF-8
Timezone: | AEDT
Debug logs (at least 50 lines):
General > Advanced Settings > Enable debug
Additional context
n/aMedusa Info: Branch: master
Commit: Unknown
Version: 1.0.19
Database: 44.19
Python Version: 3.11.8 (main, Feb 19 2024, 17:01:17) [GCC 13.2.1 20231014]
SSL Version: OpenSSL 3.1.4 24 Oct 2023
OS: Linux-5.10.60-qnap-x86_64-with
Locale: en_US.UTF-8
Timezone: AEDT
The text was updated successfully, but these errors were encountered: