Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AndrewFG]

That doesn't solve the problem.  Often times files don't play regardless of push or pull.  The problem is the difficulty in setting up the server profile; the customized views are secondary.  

I agree, DLNA implementation and documentation is extremely poor.  A better wiki and custom profiles are needed.  Even Bob agrees:  http://yabb.jriver.com/interact/index.php?topic=79476.msg541161#msg541161  However, nothing has been done about it and many other implementations are pushing way past MC in this regard.  Right now, it is purely trial and error and support is completely lacking.  I have yet to get things set up the way I would like completely on any of my DLNA devices.

Ok. Now I am with you. And I fully support you concerning the need for MC to improve its interworking with renderers. Indeed I have in my own way been nagging bob about this for quite some time too. So gentlemen (Bob, Hendrik, JimH, and Matt if you are up to it), can you please finally take this issue on board, and move it up the to do list?

There are actually two three main issues that must be addressed:

1) Semantic Issues

These are issues relating to the contents of UPnP xml payloads. For example some renderers (like Sony) don't accept pure UPnP semantics, and insist to have the DLNA extension flags / tags added to UPnP xml payloads sent to them. But other renderers don't accept payloads with those DLNA extension flags / tags. Also there are other semantic issues like whether small image icons are declared before large image icons. And indeed there are things like spelling mistakes too (devices expecting tag names "bitrate" vs "bitRate" for example). MC has a few switches in Settings where you can customize some of these things. But more are probably needed.

2) Media Format Issues

These are issues relating to the media format which MC streams to a renderer. MC is really extremely weak in this area; it only offers "original format", or "convert to a low common denominator format" (and the choice of such low common denominator formats is very weak). Some other competing servers on the market offer ways for users to write configuration (text) files that allow them specify which formats shall be sent to different renderers. But frankly that way of doing it is a) a kludge, and b) absolutely inhuman in terms of user friendliness.

What I have said, frequently and often, is that MC must make proper use of the GetProtocolInfo method. This is a mandatory method that all servers and renderers must implement. And indeed every server and renderer that I have ever seen does implement it. This method allows a renderer to declare a list of all the media formats that it is capable of playing (SinkProtocolInfo) and allows a server to declare a list of all the media formats that it is capable of sending (SourceProtocolInfo). The purpose of SinkProtocolInfo and SourceProtocolInfo is that the server is supposed to search through these two lists and choose the highest common denominator format that both are capable of.

MC does not do this. Instead of using this "highest common denominator" selection process, it has the above mentioned convert to "lowest common denominator" format selecting in its Settings. This is totally doof. And it is not the way that the authors of the UPnP specifications intended things to be. If MC would properly implement a highest common denominator negotiation between SinkProtocolInfo and SourceProtocolInfo, then this setting could be called "Auto". And it would just work. So the users would not be faced with the current frustrations of looking in the Wiki or posting on this forum.

MC is actually a class leader in implementing Auto settings for audio and video streaming settings over on board DACs, USB DACs and HDMI outputs. So why not also implement an Auto setting for streaming via UPnP too? Believe me, if MC would take this step, instead of being compared unfavorably with the competition, you would be able to wipe the floor with them. Please, please do it. (I would even offer help you with the algorithm coding, and testing too..)

EDIT: I forgot to mention a third type of issue

3) Optional Functionality Issues

These are issues relating to non mandatory UPnP functions (such as the now famous SetNextAvTransportUri for gapless playback). Here again MC has a Setting where the user can choose manually if his renderer supports that function. However it would also be perfectly possible for MC to automatically check if the renderer supports this method (the method is either declared or not declared in the renderer's Device Description).

[JimH]

... DLNA implementation and documentation is extremely poor.

I don't think we can document DLNA.  There are just too many variables and gotchas.  When we can, we program around them.

The good news is that our DLNA is becoming one that manufacturers commonly test against.

[AndrewFG]

When we can, we program around them.

Yup. Please see my prior post Jim.

[connersw]

I don't think we can document DLNA.  There are just too many variables and gotchas.  When we can, we program around them.

This is untrue, and passing the buck.

At a minimum, you could document what the Options do and when to try them.  What does that DLNA check box do?  What about DLNA Extra?  What doess WMC compatible mean?  What does mimetype overide do?  Right now, all a user can do is randomly tick things on and off to see what works and what doesn't.  More often than not, it doesn't.  How about at least a basic trouble shooting guide?

Through scouring the forums, I've learned that the Video Format settings are as follows:
Very high = 1080p
High = 720p
Medium = 480p
Low = 240p
DVD = 480/576
Why can that not be documented?

As Andrew stated, you are missing a golden opportunity.  Almost every TV sold now is a "smart" TV with some implementation of DLNA.  Consumers are looking for an easy way to view their media on their new TV, and JRiver is getting crushed by its competitors in that regard. 

[JimH]

What makes you think JRiver is "getting crushed by its competitors"?  Just curious.

I don't mean to "pass the buck" (or lie).  We just have to choose our battles.

[JimH]

What I have said, frequently and often, is that MC must make proper use of the GetProtocolInfo method. This is a mandatory method that all servers and renderers must implement. And indeed every server and renderer that I have ever seen does implement it. This method allows a renderer to declare a list of all the media formats that it is capable of playing (SinkProtocolInfo) and allows a server to declare a list of all the media formats that it is capable of sending (SourceProtocolInfo). The purpose of SinkProtocolInfo and SourceProtocolInfo is that the server is supposed to search through these two lists and choose the highest common denominator format that both are capable of.

My understanding of this is that, even though the intention is good, devices don't report the list reliably.  Maybe Bob will comment.

[Hendrik]

I kinda agree that getting DLNA working with my TV was anything but easy. I had to mess with the settings for half an hour to get any video playing, and google around for another half to figure out how to send more than SD video.
I'm sure we can do something to try to improve this.

[bob]

I don't see a reason to rehash this.
GetProtocolInfo IMO is bad.

I've detailed why several times (inaccurate, lack of proper flexibility in description of capability, etc).
If you happen to have a device that can almost state what it can do with GetProtocolInfo, well you are in the minority for sure.

[connersw]

What makes you think JRiver is "getting crushed by its competitors"?  Just curious.

Plex did not even exist prior to 2010.  Now, it is ubiquitous.  Few people I talk to even know what JRiver is, and I associate with a tech/geek heavy crowd.  Even my 70-year old parents know what Plex is (do that thing that lets me see the Grandkid's pictures on the TV). 

I don't mean to "pass the buck" (or lie).  We just have to choose our battles.

I absolutely understand that you must choose your battles; not everything can be a priority.  However, your chosen priority seems somewhat misaligned lately.  How many average consumers want to purchase a computer running Linux that can only play music to sit humming next to their TV?  Even your core group of users in your poll showed minimum interest.  Then compare that to the number of consumers that just bought a new "smart" TV and want to easily show content from a computer they already have onto that new TV.  Google "stream computer to TV" or something similar, and how many pages in do you need to go before you finally come across JRiver?

I don't mean to be argumentative.  JRiver and MC do a ton of things extremely well, and that is the reason I have stuck with it.  I think I know my way around the software fairly well, and I try my best to share what I know on the forums to help others.  However, it is frustrating when after months, there are things that I can still not get to work right.  The requests for help seem to oscillate between deaf ears and shoulder shrugs of "meh, DLNA is funky so that's as good as it gets." 

Sorry to digress this thread. 

[JimH]

... there are things that I can still not get to work right. 

Are you posting a list?

[connersw]

No 1080p Video on LG TV:  http://yabb.jriver.com/interact/index.php?topic=84313.0
No 1080p Video on WD Live:  http://yabb.jriver.com/interact/index.php?topic=86725.0
No Video at all on Meazy A2W:  http://yabb.jriver.com/interact/index.php?topic=89439.0

[AndrewFG]

I don't see a reason to rehash this.

Well we keep seeing customers complaining here that they can't get MC to work with their new player. That seems enough reason to me.

GetProtocolInfo IMO is bad.

Do you mean bad because the technical specification is broken, or bad because you tried it and it didn't work, or bad because you just don't like it?
Personally I think we ought to have a fact based discussion.
 

I've detailed why several times (inaccurate, lack of proper flexibility in description of capability, etc).
If you happen to have a device that can almost state what it can do with GetProtocolInfo, well you are in the minority for sure.

I just started up a load of devices in my home that has either a UPnP renderer or server on it. And I ran GetProtocolInfo on them all. See the listings in the attached text file. As you can see, there is a huge amount of information in those responses. Now I tend to believe that software writers don't write code to put so much stuff in a response argument without having a good reason. Are you saying that the guys who wrote this code just put in garbage for the sake of it? (Dare I ask did you put garbage in the MC code for the sake of it?)

C'mon guys, this is no more nor less than the kind of data that people put in the EDID handshakes on computer monitors, or in HDMI media format handshakes, or indeed any other handshake for that matter. I don't think you should write it off without trying it..

[AndrewFG]

^
Just so you know.. for completeness I added an extra paragraph to my original post..

[bob]

Don't want to overbeat a dead horse but I did detail in past posts several braindead protocolinfo's and how the protocol is incapable of describing the full range (or in the case of things like audio/x-flac, audio/wav, etc even a decent hint) as to what the device can support.

Now one can ignore these shortcomings and add an "auto" setting based on protocolinfo which will probably work with simple media much of the time however I don't see enough of a reward in that to offset higher priority projects.

Just my opinion.

[AndrewFG]

Don't want to overbeat a dead horse but I did detail in past posts several braindead protocolinfo's

Hi bob, the way that I envisage the Auto function working is a kind of soft fall back process as follows:

1) Choose the highest common denominator between MC's SourceProtocolInfo, and the renderer's SinkProtocolInfo, (on video allow formats with higher resolution than the source because MC is good at up-scaling)
2) Try to stream that format, and check if the renderer GET socket was not prematurely closed, and the renderer status GetPositionInfo reports playing Ok
3) If the playback was not Ok then fall back to highest common denominator between the original source format (which should anyway be in MC's SourceProtocolInfo), and the renderer's SinkProtocolInfo
4) Repeat 2)
5) If the playback was still not Ok then fall back to something fairly standard like L16 (for audio)
6) Repeat 2)
7) If the playback was still not Ok then fall back to something absolutely basic like MP3 (for audio)
8 ) Repeat 2)
9) If the playback was still not Ok then give up and report an error...

What do you think?

[AndrewFG]

I kinda agree that getting DLNA working with my TV was anything but easy. I had to mess with the settings for half an hour to get any video playing, and google around for another half to figure out how to send more than SD video.
I'm sure we can do something to try to improve this.

I am toying with the idea of writing a "smart settings" app that runs a UPnP diagnostic on the renderer and recommends what settings the user ought to make manually in MC so that it will work optimally with that renderer. I am thinking that if you guys don't want to integrate such functionality into MC itself, then it could be a standalone app. Or perhaps alternately an MC plug-in, although I don't know if the MC plug-in interface has the right hooks for such a thing ??

[JimH]

I am toying with the idea of writing a "smart settings" app that runs a UPnP diagnostic on the renderer and recommends what settings the user ought to make manually in MC so that it will work optimally with that renderer. I am thinking that if you guys don't want to integrate such functionality into MC itself, then it could be a standalone app. Or perhaps alternately an MC plug-in, although I don't know if the MC plug-in interface has the right hooks for such a thing ??

Interesting idea.  Thanks.  Starting as a standalone app might be the path of least resistance. 

[bob]

Hi bob, the way that I envisage the Auto function working is a kind of soft fall back process as follows:

1) Choose the highest common denominator between MC's SourceProtocolInfo, and the renderer's SinkProtocolInfo, (on video allow formats with higher resolution than the source because MC is good at up-scaling)
2) Try to stream that format, and check if the renderer GET socket was not prematurely closed, and the renderer status GetPositionInfo reports playing Ok
3) If the playback was not Ok then fall back to highest common denominator between the original source format (which should anyway be in MC's SourceProtocolInfo), and the renderer's SinkProtocolInfo
4) Repeat 2)
5) If the playback was still not Ok then fall back to something fairly standard like L16 (for audio)
6) Repeat 2)
7) If the playback was still not Ok then fall back to something absolutely basic like MP3 (for audio)
8 ) Repeat 2)
9) If the playback was still not Ok then give up and report an error...

What do you think?

I think it's a good idea in theory.
What I've run into that would give trouble with this approach is that some renderers simply lock up when you send them something they can't play and that requires a power cycle to clear.
Also, it really only works for 2 channel material as far as I can see.
To me the major flaw in the protocol with the exception of L16, there is no way to specify supported sample rates, bitrates, channels.
I've suggested an extension along the lines of the L16 specification. This would be especially useful for wave and flac.
For video material, the DLNA flags attempt to be more specific about that supported abilities like frame rate, etc but there seems to be little consistency in the way this is specified by the various manufacturers.

I was thinking as an alternative, one could have a database of supported capabilities for specific devices that could be imported (perhaps automatically) into MC as a preset. It sounds similar to your idea.

[AndrewFG]

^

I think in my app I will do the following:

1. Download the device description, get any DLNA or Microsoft flags in the HTTP header, check for any DLNA entry in the DDD => tells you already a lot about the device capabilities, manufacturer class, and semantic expectations.

2. Download the service description and check if SetNextAvTransportUri is supported.

3. Call GeProtocolInfo and parse into a table of audio, video an image capabilities.

4. Ask the user some questions about the type of media in their library.

5. Make a recommendation on MC manual settings that matches the above.

In a second phase, the app could query the MC library and answer question 4 automatically. And it could also prefill the MC server settings and the MC settings for that renderer.

A question bob, could you please share with me (PM) what the various MC server settings checkboxes actually do to the xml payloads. Some like bitrate I know, but some like PS3 or DLNA, DLNAExtra are less obvious.

[AndrewFG]

GetProtocolInfo IMO is bad.

Coming back to this statement, I know bob will hate me for pointing this out (again), but today (as one does) I was reading again the UPnP AV Architecture Specifications http://upnp.org/specs/av/UPnP-av-AVArchitecture-v1-20020625.pdf and I just happened to notice chapter 5.3 again which explains the functions expected of a UPnP Control Point.

In my opinion MC does properly fulfill the UPnP architecture expectations concerning functions 1, 2¹⁾, 5²⁾, 6, 7, 8, 9³⁾ and 10²⁾ but it does not fulfill the architecture expectations concerning functions 3 and 4.


5.3. Control Point

Control Points coordinate the operation of the MediaServer and the MediaRenderer, usually in response to user interaction with the Control Point’s UI. The following describes a generic Control Point algorithm that can be used to interact with a wide variety of MediaServer and MediaRenderer implementations.

1. Discover AV Devices: Using UPnP’s Discovery mechanism, MediaServers and MediaRenderers in the home network are discovered.

2. Locate Desired Content: Using the Server’s ContentDirectory::Browse() or Search() actions, a desired Content Item is located. The information returned by Browse()/Search() includes the transfer protocols and data formats that the MediaServer supports to transfer the content to the home network.

3. Get Renderer’s Supported Protocols/Formats: Using the MediaRenderer’s ConnectionManager::GetProtocolInfo() action a list of transfer protocols and data formats supported by the MediaRenderer is returned to the Control Point.

4. Compare/Match Protocols/Formats: The protocol/format information returned by the ContentDirectory for the desired Content Item is matched with the protocol/format information returned by the MediaRenderer’s GetProtocolInfo() action. The Control Point selects a transfer protocol and data format that are supported by both the MediaServer and MediaRenderer.

5. Configure Server/Renderer: [REDACTED]

6. Select Desired Content: Using the AVTransport service (whose InstanceID is returned by either the Server or Renderer), invoke the SetAVTransportUR() action to identify the content item that needs to be transferred.

7. Start Content Transfer: Using the AVTransport service, invoke one of the transport control actions as desired by the user (e.g. Play, Stop, Seek, etc).

8. Adjust Rendering Characteristics: Using the MediaRenderer’s Rendering Control service, invoke any rendering control actions as desired by the user (e.g. adjust brightness, contrast, volume, mute, etc).

9. Repeat: Select Next Content: Using either the AVTransport::SetAVTransportURI() or AVTransport::SetNextAVTRansportURI() actions, identify the next content item that is to be transferred from the same Server to the same Renderer. Repeat as needed.

10. Cleanup Server/Renderer: [REDACTED]


Notes:
1) as the MC control point is also a server, obviously MC does need to call the Browse() or Search() actions on itself
2) these functions are actually not required for HTTP playback
3) the per renderer settings in MC determine whether SetAVTransportURI() or SetNextAVTRansportURI() are used

[bob]

Hi Andrew,
I agree with your conclusions about the spec and MC as a control point but given the shortcomings of the protocolinfo description itself I just don't see it rising to the priority it'd require to get on the list. If the protocolinfo WAS completely descriptive of the capabilities of the renderer it would be useful but since that's impossible given the way it's constructed, the spec is not very useful in this respect IMO.

(edited to clarify that I was referring to the (Sink)Protocolinfo)

[ddennerline]

This type of auto-capabilities negotiation happens all the time in protocols. If a client (or server) publishes incorrect capabilities, then all bets are off. I don’t think it fair to punish users because a specification is not 100% clear. Perhaps a good majority of devices might play fairly - don't penalize the small majority that do. In very early days, SSL had negotiation issues also. As time progressed, SSL/TLS negotiation problems were minimized. I suspect the DLNA protocol capabilities issues follow in the same path.

If anything, it should be possible to fingerprint a device’s playback capabilities and allow user to move features up/down or delete capabilities. This is typically the kind of kludge that is done to allow client and server to play nicely.

For me having very high DLNA compatibility and reliability is important. I don’t want to use SMB shares or other hacks to play my music at high fidelity. If a client supports lossless playback through a fancy DAC, the server should send lossless stream.

I will happily pay more than $50 for media server software where I can play music anywhere in my house. I suspect many users would pay for an upgrade that would cover some of the ideas outlined by AndrewFG.

[zezo]

This is a great topic as it covers some major issues and also covers my own issue with jriver (http://yabb.jriver.com/interact/index.php?topic=89205.0)

I totally understand that DLNA is a bit underdeveloped as a specification, but there are some good examples (serviio) for handling this by using per device/group of devices profiles which can come prebuild with jriver and also provide the opportunity for adding new profiles or editing existing ones. This has proven to work extremely well and don't understand why it is ignored as a possible solution.
Cheers!