external subtitle not showing
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Re: external subtitle not showing
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"
Re: external subtitle not showing
To get the behavior your want, you should use
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.
Code: Select all
*,eng;*,und
Re: external subtitle not showing
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.
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.
Re: external subtitle not showing
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/
I was referring to this application, which has the ability to convert encoding among many other good features: https://notepad-plus-plus.org/
Re: external subtitle not showing
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.
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.