UMS configuration for different video file types and online video streaming
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: UMS configuration for different video file types and online video streaming
UMS only offers content in two ways: 1) Via UPnP AV/DLNA 2) Via the web interface in any browser. You can forget all about "screen sharing" and "mirroring" when it comes to UMS. The fundamental logic for such a media server is that is should merely serve. That means that it doesn't control playback, and that "clients" have to manage browsing and actually requesting the media. As such, it is obvious that "sharing/mirroring" is outside the scope.
I see that the projector supports DLNA, but it's not entirely clear to me how it allows you to browse and playback content, since I assume it doesn't have a remote control...? To be able to request media for playback, the device needs to have a way of accepting user input. Some devices, like Miracast and Chromecast is built around a different logic, where another device controls playback it the display device/renderer is merely a slave. This is a different concept, but it can also be done (partially) using UPnP AV/DLNA by using a third device as a controller. The third device must then also support UPnP AV/DLNA so that it can speak to both the server and the renderer, and manage browsing and playback. There are applications for mobile phones that will do this like BubbleUPnP for example. It does however have some limitations in the way it negotiates media compatibility, so you can experience "additional challenges" to get playback to work using this model than using a renderer that can contact the server directly.
While it is possible to get UMS to stream sources from the Internet in some circumstances, this is a patchy field since there's not really a standard way to deliver content from the internet, and getting the metadata needed to negotiate playback is especially challenging and completely undefined by any relevant standard. As such, think of UMS as a server for serving local content first and foremost.
I see that the projector supports DLNA, but it's not entirely clear to me how it allows you to browse and playback content, since I assume it doesn't have a remote control...? To be able to request media for playback, the device needs to have a way of accepting user input. Some devices, like Miracast and Chromecast is built around a different logic, where another device controls playback it the display device/renderer is merely a slave. This is a different concept, but it can also be done (partially) using UPnP AV/DLNA by using a third device as a controller. The third device must then also support UPnP AV/DLNA so that it can speak to both the server and the renderer, and manage browsing and playback. There are applications for mobile phones that will do this like BubbleUPnP for example. It does however have some limitations in the way it negotiates media compatibility, so you can experience "additional challenges" to get playback to work using this model than using a renderer that can contact the server directly.
While it is possible to get UMS to stream sources from the Internet in some circumstances, this is a patchy field since there's not really a standard way to deliver content from the internet, and getting the metadata needed to negotiate playback is especially challenging and completely undefined by any relevant standard. As such, think of UMS as a server for serving local content first and foremost.
Re: UMS configuration for different video file types and online video streaming
I don't think it has to do with buffering or size. If your network bandwidth is bad that could lead to problems, but in that case I would expect that playback would first start and then stop or lag/freeze. If it doesn't play at all, it's very likely caused by the wrong combination of formats/codec.
The way this works is that UMS tries to identify the renderer using either UPnP metadata or HTTP headers. This information is used to match a "renderer configuration" file, which then tells UMS what the renderer supports. UMS will then transcode formats that's not supported to one that is.
The problem probably lies somewhere in this "chain of events". I don't quite understand how you use UMS to control playback? Does that would mean that you click on the renderer on the "Status" tab in the GUI and then use this to tell the renderer what to play? It is theoretically possible, but very buggy and a feature that has never really been fully implemented. I think of it mostly as an experiment left there to confuse users. If you do this, I advice you to use something like BubbleUPnP to control it instead.
Regardless, there are two things that can really cause failure of format/codec resolution: 1) The renderer is misidentified or not configuration exists for it. 2) The existing configuration is wrong
To know what is the case, debug files are needed.
The way this works is that UMS tries to identify the renderer using either UPnP metadata or HTTP headers. This information is used to match a "renderer configuration" file, which then tells UMS what the renderer supports. UMS will then transcode formats that's not supported to one that is.
The problem probably lies somewhere in this "chain of events". I don't quite understand how you use UMS to control playback? Does that would mean that you click on the renderer on the "Status" tab in the GUI and then use this to tell the renderer what to play? It is theoretically possible, but very buggy and a feature that has never really been fully implemented. I think of it mostly as an experiment left there to confuse users. If you do this, I advice you to use something like BubbleUPnP to control it instead.
Regardless, there are two things that can really cause failure of format/codec resolution: 1) The renderer is misidentified or not configuration exists for it. 2) The existing configuration is wrong
To know what is the case, debug files are needed.
Re: UMS configuration for different video file types and online video streaming
Attaching screenshots is of little use. If you follow the description in red on the top of this thread, you will generate the proper debug files. The file you posted was readable, but contained no information about the problem at hand. It did however contain a lot of warnings about some network problem, but until the full log is posted it's hard to judge it's relevance.