Universal Media Server | Forum

If I go to Transcode Settings, the Transcoding quality under Misc Settings is greyed out and cannot be changed. It's stuck on Automatic(Wired) which is bad since I have wifi and am getting choppy video when using this app and it won't let me make the changes I need to...

How do I fix this? I tried doing a clean install but that did nothing.

I attached the trace logs as per the reporting guidelines, I also attached a pic of the greyed out options. I appreciate any help!

You're running more than once instance of UMS, which leads to all kind of errors in your log. I would fix that first, and then see what works and not. If you have ever clicked "installed as a service", that's the most likely reason for this. Uninstall the service and reboot and that should be taken care of.

@Nadahar beat me too it, there are errors saying that a port is being used

Automatic speed tests were added not long ago so UMS can decide the best quality options to use for each renderer, so that option was disabled in the GUI. I can't remember if it can be overridden.

Your network speed to your renderers is very slow though, even for wifi, which will be why you are getting choppy video. There may be things you can do to improve your speed but I don't know much about networking to be much help.

Nadahar wrote: ↑Wed Jul 21, 2021 6:08 am You're running more than once instance of UMS, which leads to all kind of errors in your log. I would fix that first, and then see what works and not. If you have ever clicked "installed as a service", that's the most likely reason for this. Uninstall the service and reboot and that should be taken care of.

I looked at "services.msc" and didn't see UMS there. Also in Task manager I only see 1 instance of it when I launch UMS. How can I see this service or duplicate? I tried reinstalling UMS as a clean install but that did not help

You should be able to see UMS in the service manager if it was running as a service. In task manager it might just show up as "java.exe" or "javaw.exe".

As long as it's not installed as a service and you just start it once, there shouldn't be more instances. All I know is that in your log, both the ports that UMS tried to bind to was reported to already be in use (5001 and 9001). The chance that another running software is using both these ports is extremely small, so I pretty much take that as "proof" that UMS is already running. But in theory, there could be other reasons, like the OS or some "security software" not allowing UMS to bind to those ports.

If you can't find anything "suspicious", you can generate a new log file and we can see if the bind problem persists.

Nadahar wrote: ↑Wed Jul 21, 2021 7:34 am You should be able to see UMS in the service manager if it was running as a service. In task manager it might just show up as "java.exe" or "javaw.exe".

As long as it's not installed as a service and you just start it once, there shouldn't be more instances. All I know is that in your log, both the ports that UMS tried to bind to was reported to already be in use (5001 and 9001). The chance that another running software is using both these ports is extremely small, so I pretty much take that as "proof" that UMS is already running. But in theory, there could be other reasons, like the OS or some "security software" not allowing UMS to bind to those ports.

If you can't find anything "suspicious", you can generate a new log file and we can see if the bind problem persists.

So I checked that the "Only run a single instance of UMS" tickbox was ticked and I changed the port to 6001 but I'm still getting the same issue. I've attached the logs now. I really appreciate your help! it should be noted that UMS does work for me, jus that for some reason I can't change the transcode quality.

EDIT: I found a way to kind of work around this, if you go to "C:\ProgramData\UMS" and open UMS.conf with notepad, you can change the transcode quality. It's not a great work around since the actual UMS app should let me do it regardless. Is it maybe because UMS is installed in programfiles, maybe a win10 permissions issue?

I think there has been some "confusion" as a result of the bind error in your first log. I don't see this in your second log, which is good.

When multiple instances run so that you get bind errors, there will be all kind of errors in the log that makes that log quite useless as a source to find real problems, which is why I suggested that it was addressed first. I thought that it was a possibility that the "sharing" of the configuration files between the instances could lead to locked files which led to problems saving changes. But, it doesn't really explain why the settings would be grayed out. However, "all kind of things" can go wrong when running multiple instances, so it was hard to say for sure.

I don't know why there were two instances when you made your first log, but I suspect that it could be caused by problems in UMS' restart procedure that is used when starting "trace mode", and that the "former process" never shut down properly. If this was what happened, it means that you only had this "double instance" problem when making the log, and that this hasn't been an issue contributing to your original problem.

The most likely cause for it being grayed out, especially when it works when you edit the configuration file manually, is that this is a new bug in recent versions of UMS. I haven't run UMS since before version 7, so I wouldn't know if a GUI bug has been introduced. So, I've probably done nothing but add confusion to the case

I'm not sure but I think the change in being able to manually change the quality was done here and instead to automatically use the highest quality for the speed of the network.

Nadahar wrote: ↑Thu Jul 22, 2021 7:10 am I don't know why there were two instances when you made your first log, but I suspect that it could be caused by problems in UMS' restart procedure that is used when starting "trace mode", and that the "former process" never shut down properly. If this was what happened, it means that you only had this "double instance" problem when making the log, and that this hasn't been an issue contributing to your original problem.

I was thinking the same thing as I have seen this several times now. Maybe a delay or a check that ports have been freed should be added before UMS is restarted when switching to trace mode.