Universal Media Server | Forum

Hi, I just installed UMS for the first time, 14.13.0 on macOS 15.6, M1. Thanks for making it!

The main thing I'm trying to accomplish is play Dolby Vision MKV files to my LG TV, which only supports DV in MP4. I heard about UMS's ability to remux on the fly, but I ran into some problems.

The first thing is that the tsMuxeR provided inside the app bundle is broken and won't start up. It looks like it's the Linux version? I downloaded the latest version from their Github, and replaced it, and now it seems to start ok. UMS recognizes my TV, and that the DV MKV files (but not non-DV ones) need remuxing, which it does. The TV indicates that it's Dolby Vision.

But there's a delay of several seconds in the audio. It's not there if I turn off remuxing/transcoding, or if I do full transcoding, but then I lose Dolby Vision. Is there some way to fix the remuxing sync? I tried moving tsMuxeR to the top of the engine list, and using "force fps from ffmpeg" or not, but it doesn't help. So now I'm back to manually remuxing to MP4.

I haven't attached a log, because it looks like it contains a lot of personal information that I'm not comfortable with sending. Is there something I should look for? Otherwise it will take me a bit to redact things, if it's necessary.

This has been brought up before here and was due to subs as it causes it to become out of sync and it is a bit of a headache due to LG tv's not supporting DV in MKVs.

The main reason for this is FFmpeg does not preserve the DV metadata when transcoding so UMS tries a workaround using tsMuxeR but as it is an extra step and if there is any change like seeking this can make the whole thing fail and lose the DV data. Although the last time I checked this there was an update to FFmpeg to preserve DV data but don't know of the status of getting this to work in UMS.

From the previous thread the user mentioned they could adjust the delay in the TV menu to get it back in sync so this may be you best option at the moment.
Make sure you have GPU encoding acceleration method for h264/265 enabled if you have one to speed up transcoding too.

You could manually reencode the video into MP4 using other tools, I see xmedia mentioned as an option, or try to avoid getting videos that have DV in MKV.

I'll mention that the wrong version of tsMuxeR is being installed, there may be a mis-configuration of the build script on Github.

Thanks, I did see that post, but it's not the issue I'm having. That was about subtitles not working or being out of sync. My problem is audio being delayed, by around 5 seconds. I'm not using subtitles, and there's no audio delay setting in the TV menu. Also, there's no video transcoding going on, only remuxing, so GPU acceleration isn't relevant. It happens either if I set tsMuxeR directly, or use "Remux videos with tsMuxeR when possible instead of transcoding" with the FFmpeg engine. The DV data is actually working with remuxing, it's just the audio is out of sync/delayed.

At the end of this thread, SubJunk says "it should automatically mux those DV streams, I do it all the time":

[Solved] Remuxing Dolby Vision for LG 2023+ TV

So maybe it's a Mac thing, or a regression? For now I can go back to manually remuxing to MP4 with Subler, which works ok but takes time. Hopefully it can be made to work on the fly, it's the main reason I came to UMS...

It could still be an issue with subs just they may be for foreign language or not enabled on the TV, or could be doing a similar thing to what I was seeing in that thread but without logs I cannot tell.

Ok, I've been fighting with UMS a bit, and learning the ropes. Things got a lot more stable after I turned off "resume"...

Looks like the sync problem when remuxing is only with certain files, so far all webdl shows from Apple. Others from Netflix, Amazon, etc. don't have the audio delay problem. I don't know what Apple is doing different in their files. Also, it seems to get fixed if I just seek around a bit in the file, when it starts playing again it's in sync. So it's easy enough to work around it.

There are some other weird things when remuxing, like patchy green and purple artifacts in some files, that go away if I manually remux to MP4, or files that say they're remuxing but only give HDR not DV. I'll see if I can get some time to make logs.

Yeah the resume feature in UMS can cause problems, I'm not 100% sure it is working correctly as it should be making a virtual file you have to select to resume but playing the original file plays the resume file instead from what I have seen in some logs. I'm not sure if this is the intended outcome or not.

There is a setting you can add to your renderer's conf to disable resume for just that device so it can handle resuming if you have others that you want to use it on, but if not then just turning off resume will do. If you edit the conf you should copy it to C:\ProgramData\UMS\renderers so it does not get overwritten when you update UMS and to make sure it will be used set the LoadingPriority to a higher value and change the RendererName so you can see if it is being used.

If you find the colours are going green and purple it could be the loss of the DV data like I mentioned before.
From what I worked out there are several things that have to happen at the same time and if anything gets out of sync it can break it or make it fall back to full transcoding with the loss of DV.

I only have the one device, so just turning off resume globally in the UMS settings is fine, but I'll keep that in mind, thanks.

The green and purple colours aren't the loss of DV data per se, and they aren't falling back on full transcoding. But yes, it seems like something is being messed up with the metadata or how it's applied, when doing the remuxing.

It's something very strange that I've never seen before. It's not the typical thing like when playing a DV file on a player that doesn't support it, and the whole image is tinted green/purple. What I'm seeing is sort of drawn masks or large rectangular patches, over certain elements of the scene like part of someone's face, of very slight purple or other colouring overlaying an otherwise correctly rendered image. It's only happening with one set of files, and only when being remuxed by UMS. If I remux them to MP4 manually, they're fine.

I'm learning that there are a huge number of possible variations in video files, and I guess the remuxing might have a hard time with some edge cases. I'm starting to wonder if Dolby Vision is even worth all the trouble. I might go back to just plugging my Mac's HDMI into the TV, but I find using the built-in Media Player in the TV gives a better image. When it works.

I have noticed the audio delay with some files too, unfortunately. Certain release groups are providing better releases than others so I recommend paying attention to which group released the ones that work well and avoid the ones with the delay problems.

Can you please let us know which version of tsMuxeR you had to switch to, and which UMS installer you use on macOS?

SubJunk wrote: ↑Sat Oct 04, 2025 2:55 pm I have noticed the audio delay with some files too, unfortunately. Certain release groups are providing better releases than others so I recommend paying attention to which group released the ones that work well and avoid the ones with the delay problems.

Can you please let us know which version of tsMuxeR you had to switch to, and which UMS installer you use on macOS?

Fyi, tsMuxeR is still broken in the latest public UMS 15.1.0 Mac release, as well as the previous 14.x one. The binary inside the app bundle appears to be for Linux. I replaced it with the one in tsMuxer-2.7.0-mac.zip at https://github.com/justdan96/tsMuxer/releases/tag/2.7.0 There were several steps to get it to run again, because it breaks the code signature.

I've found that the audio delay while remuxing is in all Apple TV+ series web-dl files, regardless of the release group. Simply skipping back one time after it starts playing seems to resync it, so it's not a big deal, once you know that.

Just seen another post that WebOS 2025 now supports DV in MKV so remuxing will not be needed, however it appears to have a memory leak in their media player but not sure of the actual details.

If your TV has had this update you could try and play from the #--TRANSCODE--# folder and select "no transcoding" so it is streamed unaltered.
If DV is working then the conf can be tweaked to say the TV can now play this.

I don't know if the WebOS version is sent in the headers to UMS so there might not be a way for UMS to automatically switch to a conf with DV set as supported in MKV.
It would be helpful to see your logs if the TV has WebOS 2025 to see if this is possible otherwise it will have to be something the user has to do.