Yes I know… but I’m hoping that some day Plex will fix it.
If they could just show after the language what ever the user adds after it in the file name.
eng.cc.srt -------> English [cc]
eng.forced.srt —> English [forced]
that way the user selects the one they want when playing the video…
I have to admit that I’ve struggled with the same problem until I found the “logic” in the naming convention of Plex. It is well known that Plex will recognise the forced subtitles when the naming is:
<movie_name>.<language>.forced.srt
As the topic says: such a convention does not exist for sdh subtitles… BUT.
I discovered that Plex displays the same subtitles types in alphabetic order, based on the “language” part, or better: actually based on the part that comes right after <movie_name>. So if you stick to the convention of naming your movies and subtitles like (I’ll take eng for this example):
<movie_name>.eng.srt
<movie_name>.sdh.eng.srt
you’ll see two english subtitles in Plex out of which always the second one will be the sdh. (s comes after e in the alphabet)
In case you have Turkish (I just took a langauage that starts with a letter after s) subtitles and you name them like
<movie_name>.tur.srt
<movie_name>.sdh.tur.srt
then you’ll see two turkish subtitles in Plex and the first one will always be the sdh (since s comes before t in the alphabet).
This makes it - at least to me - easier to recognise which one is which. Of course I agree that creating a “forced”-like convention in Plex for sdh subtitles would be a nice feature.
Well… I really am not seeing an avenue to fame and riches by fixing the Circular Head Chopper mask for actor images, or audio/sub descriptive services, so I guess you’re right.
Maybe the user begging phase is 10 years, not a mere 5.
Who knows?
It’s just odd that things like this have to be tagged Development, when standard, run of the mill, cosmetic housekeeping should have already handled it.