Universal Media Server | Forum

Could you post logs? see the section in red above.

As a work around you could play from the #--TRANSCODE--# folder and select your subs that way. This will transcode and burn them into the video stream which is not ideal if the original file is supported by your TV but should work OK for now.

I'm pretty sure this is because of the change they made to how subtitles support is indicated in the renderer configuration files. It used to be (before a certain version, probably v9 something) that support for external subtitles could be specified on a separate line that applied to all containers. Then they changed this so that instead it must be specified on the individual supported lines, so that it's possible to support a certain subtitles type for one container type but not for another.

That is all well, the problem is that most of the existing renderer configurations weren't updated to this new syntax. This means that subtitles support most renderers were effectively removed, and that they will only be fixed one by one when somebody complains that it has stopped working.

I don't remember how the "new" format looks, but if you can find one of the renderer configurations that has been "updated", it should be easy enough to see. The same changes then need to be done to all the "supported" lines where it applies, and you should be good to go. Then a PR should be created to update the renderer configuration that comes with UMS, so that the "fix" is done for other users as well, and so that version updates won't invalidate the changes.

The "si:" (internal subtitles) and "se:" (external subtitles) are the ones I was thinking of. However I can't see them in the LG-LA740s.conf in your "trace files". Also, remember that you have to restart UMS after editing the renderer configuration file for the changes to apply.

When it comes to being worried about "falling behind" the latest version, there's nothing to worry about. That's a "hoax" that many software companies use to make users upgrade, it's easier for them if everybody is running the latest version, and it often also generates more money for them. It's mostly software that "directly interfaces with the Internet" that is critical to keep updated, like web browsers etc. UMS doesn't do that at all, it only operates on your local network (unless you configure some kind of port forwarding for your web interface, which you really shouldn't because there's no "security features" in the web interface). UMS doesn't have authentication (passwords etc), encryption or any other such "security" feature, so most "security vulnerabilities" found in software is irrelevant. The UPnP AV/DLNA protocol that is the basis for this is also without authentication, the whole idea is that the protocol should be easy for home users to use, and authentication always makes things much more difficult, typically making it "out of reach" for the majority of users or at the very least very inconvenient to use. It is assumed that the server and the renderers run on local networks that is protected by a router or similar. In addition, it relies on multicast IP, which generally isn't routed and thus "unreachable" as soon as you have to go through a router. So, to sum it up, you have nothing to worry about with running an older version when it comes to security.

From your trace log I find: ...which points to the missing "se:" entries in your renderer configuration file.

Another problem I see in our UMS.conf is "disable_transcoding = true". This option is only meant for troubleshooting, it really disables a good chunk of the logic that normally applies, so I wouldn't be surprised if this cuts short some of the subtitles processing. You should remove it, and instead make sure that your "supported" lines match the actual capabilities of your renderer. UMS will never transcode if it doesn't have to, so as long as it knows that the renderer can play the file, it will not transcode. Thus, disabling transcoding is pointless, even though you want to avoid transcoding, I assume it's better to have a video transcoded than not playing at all.

@jareeq You're not "hacking" anything, it's the way it's supposed to work. It is true that the "supported" line must match "exactly", if it doesn't match the line isn't used.

There are some confusion regarding what codec "codes" to use, I don't remember exactly what applies in UMS, but I'm pretty sure that "aac|aac-he|aac-lc" isn't necessary. HE-AAC and AAC-LC are both AAC, they are just more specific. I doubt that the "aac" entry does anything, although I'm not sure. The same goes for "mp4" under video codec. There are no video codec that can be identified as MPEG-4, the MPEG-4 standard describes two different video codecs, one is MPEG-4 Visual and the other is AVC/H.264. MPEG-4 visual is sometimes called "mp4v", sometimes "mp4sp" or "mp4asp" (which are really just different profiles of MPEG-4 Visual, "Simple Profile" and "Advanced Simple Profile"). In any case, just specifying "mp4" seems unlikely to match anything. Most people aren't familiar with MPEG-4 Visual, but DivX and XVid are implementations of this codec.

The codes are defined here: https://github.com/UniversalMediaServer ... #L590-L695

If we assume that it is to be trusted, it seems like "mp4" is indeed valid as a video codec, and I can only assume that it means MPEG-4 Visual, although AVC/H.264 is "just as much" MPEG-4. "aac" on the other hand is not listed.

"aac-he" doesn't seem to be valid either, it's supposed to be "he-aac".

Regarding codecs you don't know if is supported, you should either find out in a manual or online, or you should test it. Leaving something as "supported" that really isn't supported will just lead to no playback if you encounter such a file. You don't have to add codecs (like EAC-3) to get anything to work unless you have files using that codec. If you have files using that codec and playback works, with subtitles and all when specified like this, then you in fact know that your TV does support it. Otherwise the file wouldn't play.

Edit. I can't understand how this line can make SRT work with MKV's though, as you're missing the "se" spec:

The "format/codecs overview" you linked does indicate EAC-3 support in MPEG-TS and AVI files (although strangely not in MP4 or MKV, which makes me thing the "overview" is probably inaccurate). "Dolby Digital Plus" in another name for EAC-3, while "Dolby Digital" means AC-3.

It has always been the case that it must "match exactly", the reason why it used to work in the older version for you was probably because you disabled transcoding. Logic change in the code has probably made this "glitch" unavailable in later versions. It was never meant to work this way anyway. It's as simple as to specify a match for everything the TV supports. It might be that they made a modification at some stage that doesn't require "se:" and "si:" as long as you have these defined: Specifying them on the individual "supported" line does give you more flexibility to actually indicate what's supported. I believe that the "external" subtitles support probably is the same for all containers/formats, while the "internal" probably isn't.

As far as I can tell from your log, transcoding is still disabled, so it's very difficult to determine what's going on as parts of the logic isn't applied as a consequence. Enable transcoding and generate a new log.