Can confirm what @moe2046 said. I have MKV files with SRT subs muxed in and others with PGS subs muxed in. I make sure to add a name for all tracks. I just updated to 8.12 for the Android app on my SHIELD TV and just checked. The audio tracks are showing the names but none of the subtitle tracks are. If I check in the web app, I see the track names for the subtitles.
Seems kind of a silly oversight for that not to work for subs when that was one of 4 added features and not specifically called out for audio tracks but streams in general (not trying to say that in a snarky way, just stating an observation).
This feature is still not available on Apple TV.
I want to embed 3D subtitles at different depths and positions on my MKVs but the subtitle names are not displayed anywhere in the UI. It does work on Roku though, but I need to use the Apple TV for other “outdoor 3D movie experience” technical reasons…
My only solution, for now, is to use different language tags for each subtitle and then keep track of the subtitle settings on a piece of paper.
What happened to UNO Everywhere…?
I am on 8.17.1.25326 and I can confirm that the track names for the subtitles have still not been exposed, as was mentioned earlier in the thread.
@tom80H, can you check with the team on this as, again, it seems like a silly oversight to not have included the names for the subtitle tracks only the audio tracks.
Sorry you are totally right, they are m4v files, dunno where my brain was when I added they were mkv O_o
If it’s not supported in m4v/mp4 I could potentially use mkvmerge and try and convert everything, and change my current conversion scripts to output mkv instead.
Should subtitle and audio names work from mp4 at the moment or just from mkv?
@OttoKerner or @tom80H any comment on the name for the subtitle tracks not showing, at least on the Android clients as that is what I use for my main client? Would be nice at least know the devs are aware and it will be implemented eventually, just cause it’s weird that they would decide not to show the names for subtitle tracks but only for audio tracks.
Not much that I’m aware of. My takeaway so far has been it’s working on all/most platforms except for Android – not aware of the inner roadmaps/priorities of Plex.
Yea, go ahead and select one of those Commentary Tracks.
“Eeenie, Meenie, Miney, MO!”
No, wrong one…
But before you get there - Call Miss Cleo - 'cause you’re gonna need Advice from beyond the Ethereal Plane to get the Version with the Commentaries Selected:
I gotta tell ya - by that time, my Friends have run screaming from the building with their hair on fire. They’re not feeling all that satisfied with Plex’s solution to this problem that’s old enough to draw social security.
Having changed one of my files to mkv it does now work and I get audio and subtitle stream names in the web player. Sadly as has already been noted Android doesn’t show the subtitle stream names, that also applies for Android TV (at least as of version 8.13.0.22986).
I do however notice the default track setting works in mkv and correct subtitle streams are being selected in mkv, this wasn’t honoured in m4v despite the default setting being on for one of the subtitle tracks. This is a pretty big win for me.
Tomorrow I’m going to put a bit of effort into scripting up the conversion, it’s quite a pain since as far as I can tell both ffmpeg and mkvmerge are losing the track titles and neither provide a way for me to say “Take the handler_name metadata and make it into title” so I need to scan each file, get the names, then do the conversion and add extra switches to specify the title names I just read out. If I get this working I’ll stick it on github (actually probably bitbucket) and link to it here.
Yeah seems you are right, I have since discovered HandBrake is also setting the forced disposition on the subtitle streams which causes the behaviour. Sadly it also seems to have been marking the first subtitle stream in every file as default (even when specified with --subtitle-default none), that’s an issue for them though not here, it does mean I can’t auto-discover which of my already encoded m4v files should have a forced stream.
However I’ve created a bash script (bash 4+ sorry, so it won’t work on macOS, I think only the usage of readarray would need to be replaced to make it macOS bash compatible) which will use HandBrakeCLI to scan the source file, extract all the audio and subtitle stream names, and then use ffmpeg to convert the container format (with the copy codec so no transcoding occurs) while also setting all the stream names appropriately. One caveat is it won’t correctly handle stream names with newlines in, other weird characters should all work though.
I’m not even sure that line breaks are allowed in there. You shouldn’t try to tell a story within these labels.
I recommend you to use mkvmerge instead of ffmpeg.
Given that “missing link” has been closed and the subtitle track details are also available in the Android apps… let’s close this suggestion and free up everyone’s votes so you can vote for other suggestions you’d like to support.