INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: AndrewFG on February 03, 2019, 04:33:16 pm
-
[Edit by JimH -- split from this thread: https://yabb.jriver.com/interact/index.php/topic,119386.0.html ]
You are quite correct. As I said before, I think there is improvement potential for MC to scrape meta data better from the HTTP headers, the SetAVT meta data, and the stream itself. It is not yet as good as it could be..
On the other hand, the UPNP standard is itself (IMHO) a bit weak concerning streaming media. Its specification, and indeed the whole concept of the HTTP transport, is optimized for sending finite length media files, rather than indefinite length streams. For example UPNP doesn’t have a fool proof mechanism for reconnecting to a stream in the case that the HTTP link gets broken. e.g. should the renderer report STOPPED, or TRANSITIONING, and should the controller repeat the SetAVT command. It is rather a rat's nest, I think.
-
I agree ... UPnP is a real mess. I've spent so much time adapting to different behaviours of different renderers and it never ends. In addition, HTTP which seems simple when you read the spec quickly, happens to be another pain when combining content-length or not, chunked-encoding, range and partial responses to unknown file sizes ... I'll see how I can adapt to MC :)
-
I agree ... UPnP is a real mess. I've spent so much time adapting to different behaviours of different renderers and it never ends. In addition, HTTP which seems simple when you read the spec quickly, happens to be another pain when combining content-length or not, chunked-encoding, range and partial responses to unknown file sizes ... I'll see how I can adapt to MC :)
It's sometimes odd and even broken in some implementations, but it's hardly "a real mess".
Our implementation is solid.
-
I did not say your implementation was bad. It has a few idiosyncrasies like this flac and chunked-encoding thingy. Mine is certainly much worse, but I really do believe that UPnP is a mess, when I see the amount of player variations that I had to deal with in my server/controller
-
Old joke:
The nice thing about computer standards is that there are so many to choose from.
-
Don’t knock UPNP. It is the ONLY non proprietary multi media inter working standard around. All others are proprietary and bound to the profit making and data grabbing aspirations of internet mega corporations.
-
I agree it's the only open one, but it has been made with too many compromises/personal interest and no good interop test suite / enforcing method. I work in 3GPP standard for a living and at least there is a lot of attention to iot, which helps solving some of the poor / privately motivated weird specifications. Problem with UPnP is that specification is fuzzy, subject to implementers' interpretations, plus they do mistakes, the certification is not strict, so eveybody gets away with. As a result, others try to workaround some of these mistakes and with all good intentions, they weaken the standard.
-
The DLNA specification makes the UPNP specification more precise. But its test regime is, if anything, less precise..
-
Does DLNA get any love now that the alliance has "dissolved" or is it just up to vendors to maintain and build?
-
Does DLNA get any love now that the alliance has "dissolved" or is it just up to vendors to maintain and build?
The standard is unchanging now. Someone promotes themselves for testing, but we've never done that anyway.
I think we could say that JRiver Media Center has now become something of a standard for others to test against. It gets significant attention from manufacturers and developers.
-
Thanks Jim that's good to know. I rely heavily on DLNA in my home network and often wonder as to how future proof - as much as standards or protocols can be - it is.
Maybe a case for a JRiver white-branded UpNP solution...although it sounds as though we're not far from that now.
Cheers