external subtitle not showing

[poloce]

Hi guys,

I been using UMC for quite a few years. And I never got the external sub to work. (they are under the same name)
I always had to us MKVtool to merge the sub into the .mp4 and so that it shows up on my TV with a sub option.

Can someone take a look and let me know if my settings are wrong?
Or can the TV model somehow only shows mrv's sub but not .srt? could this be the cause of it?

[Nadahar]

Debug files from when you try to play something with subtitles that doesn't work is much more helpful than a screenshot. That said, your "Audio/subtitles language priority" setting is wrong as far as I can see. It's supposed to be pairs of languages separated by ";", where the pairs are separated by "," internally. The pairs are "audio language, subtitles language". Your first "pair" seems to only be "eng", which isn't a valid pair. I don't know exactly what you were aiming for here, but if you always want English subtitles you should use "*,eng;*,und"

[poloce]

Hi,

I changed to below setting. Basically I want to play eng sub even when audio is English, if Eng sub are not available, then play all other sub.

However it still not playing my external sub while the file name does shows {Stream ext:subrip.....} on my TV at the end of the movie name, I thought it worked, but still no show.

And here is the debug file which I am seeing it's loading the srt, but not displaying on my TV.

DEBUG 2019-07-13 11:26:08.691 [HTTPv2 Request Worker 3] Recognized media renderer "VIERA E6 SeriesA"
DEBUG 2019-07-13 11:26:08.693 [HTTPv2 Request Worker 3] Starting transcode/remux of Fantastic.Beasts.The.Crimes.Of.Grindelwald.mp4 with media info: Container: MP4, Size: 2885007332, Video Bitrate: 2728301, Video Tracks: 1, Video Codec: h264, Duration: 2:20:59.499, Video Resolution: 1920 x 800, Display Aspect Ratio: 2.39:1, Scan Type: Progressive, Frame Rate: 23.976, Frame Rate Mode: CFR, AVC Level: 4.1, File Title from Metadata: Fantastic.Beasts.The.Crimes.Of.Grindelwald.2018.EXTENDED.1080p.BluRay.H264.AAC-RARBG, Audio Tracks: 1 [Id: 0, Language Code: eng, Audio Codec: AAC-LC, Bitrate: 224000, Channels: 6, Sample Frequency: 48000 Hz], Subtitle Tracks: 1 [External, type: SUBRIP, lang: und, externalFile: E:\Movie\1 Western Movies 【西洋電影】\Fantastic.Beasts.The.Crimes.Of.Grindelwald.2018.EXTENDED.1080p.BluRay.H264.AAC-RARBG\Fantastic.Beasts.The.Crimes.Of.Grindelwald.srt, external file character set: UTF-16LE], DLNAThumbnail: [Format = JPEG, Resolution = 320×134, Size = 7948, DLNA Profile = JPEG_RES_320_134], Mime Type: video/transcode

[Nadahar]

To get the behavior your want, you should use

Code: Select all

*,eng;*,und

Your debug files aren't created in "trace mode", so unfortunately the information about subtitles selection isn't there. You should make new debug files, making sure that you're running "trace mode" first. See the red text on top of the page for a detailed description of how to make debug files.

[poloce]

ok, I change the setup for audio/sub option and here is the debug file with trace.

[Nadahar]

In your latest log, everything seems to work "fine". The subtitles file is found, announced to the Viera and the Viera requests and receives the subtitles file once playback has started. The reason they aren't actually rendered isn't shown in UMS' log since this is a decision made by the TV.

I have a strong suspicion of what the reason might be though: your SRT file is UTF-16LE. There is no proper standard for SRT files, so this isn't "defined" anywhere as far as I know, but I can't imagine that the Viera will accept UTF-16 encoded files. You should try to convert the subtitles file to UTF-8 and see if that makes a difference.

There are many ways to convert text files, but in case you don't have a "favorite way", I can suggest Notepad++. That's how I do it. What you need to do is to open the file in Notepad (make sure to make a copy so you don't "ruin" the original file if the conversion goes wrong), go to "Format" on the menu and then select "Convert to UTF-8". The document won't change visibly, but once you save it, it should be overwritten using UTF-8 encoding instead. I'm not sure if the Viera will appreciate a BOM or not, but I would try without BOM first.

[poloce]

Thanks for the help.

And that's exactly why I don't understand, so the issues it's not showing up might be my TV.

Also I didn't see an option in notepad to convert from some reason. Try using online convert site but didn't work too. And what is "BOM" you mention?

[poloce]

I found another converter that was able to convert, and it does show up now.
I had to choice UTF8 on my Viera also to let the text show up correctly.

Thanks for the help.

BTW, is there another software or ways to convert or tell the type of SRT files I have? Any why is UTF16 works for PC but not for Viera?

Also, when I added filename.zh.srt UMC won't recolonized it. Did I do something wrong? Does UMC sees it as different file name? I simply want to add the language to name but doesn't seems to work

[Nadahar]

Please note that Notepad and Notepad++ are two different applications

I was referring to this application, which has the ability to convert encoding among many other good features: https://notepad-plus-plus.org/

[Nadahar]

As I said, there is no proper standard for SRT files, so everybody has to "choose" how they want to implement it. Back when these files were "invented", the "normal" system was to use localized character sets (aka code pages), like Latin1 or JIS for example. I guess the assumption was that subtitles files would somehow be in the expected character set/code page "by itself", or that this was the responsibility of the user.

After Unicode became in widespread use, all this has changed. Today, UTF-8 is more or less the "unofficial standard". UTF-8 has shown to be the best choice in a lot of situations. UTF-16 really was a "mistake" made back when there were much fewer Unicode characters so that it was thought that 16 bits would be sufficient to encode all code points. This has been proven wrong a long time ago, which makes UTF-16 kind of useless. The whole idea was that the memory/storage space would be easily predictable by counting characters. In the old days of "code pages" each character was 8 bits/1 byte. As such, you knew that 5 characters would need 5 bytes of storage, in this prediction is used in a lot of low-level code allocating space etc. UTF-16 was thought to give the same, simple prediction with the only difference that each character would use 16 bits/2 bytes. The price for this convenience was high though, since all texts would suddenly double in size. When it later turned out that 16 bits wasn't enough anyway, the "benefit" suddenly wasn't true anymore.

Today, UTF-16 is encoded so that although most code points require 16 bits, some require 32 bits. This means that the space requirement for a string can't be known in advance, you have to know what the actual content is to know how much space it will require. As a result, UTF-32 has been created, which still offers the benefit of being size-predictable. But, UTF-32 wastes even more space, now every character use 32 bits/4 bytes.

UTF-8 has "dynamic width", so that the most used characters (US-ASCII) only use 8 bits/1 byte, most others use 16 bits/2 bytes while some use 32 bits/4 bytes. Although the size-predictability is lost, most have found ways to deal with this in the meanwhile, and the storage space is used much more effectively, especially for the "English alphabet" (US-ASCII).

For computer software, it's usually very easy to support multiple encodings, because this is built in to the OS. As such, computer applications can support UTF-8, UTF-16 and UTF-32 without much development effort. For the Viera, it's a very different story, since there's no OS "below" that can handle the conversion. As such, I guess they didn't see that supporting UTF-16 was worth the effort.

Having SRT files encoded as UTF-16 is a pretty strange concept to me though, who even use UTF-16 anymore? So, in a way, I can understand them in their choice.