Print

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

[Scobie]

Running Andrew's analyser across my renderers and looking at the results in conjunction with this thread:

https://yabb.jriver.com/interact/index.php/topic,90343.msg620519.html#msg620519

Andrew mentions here the 2 methods of ascertaining a player's status, event or polling, and the method that's used in turn determines whether "Ignore Transport Events" should be selected in DLNA Controller options, indicating that polling is used.

The analyser tells me that for one of my renderers "GetTransportSettings" is not implemented, and the http log shows the associated 602 error.

However it also tells me that "GetTransportInfo" is implemented returning State, Status and Speed:

<?xml version="1.0" ?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><r:GetTransportInfoResponse xmlns:r="urn:schemas-upnp-org:service:AVTransport:1"><CurrentTransportState>STOPPED</CurrentTransportState>
<CurrentTransportStatus>OK</CurrentTransportStatus>
<CurrentSpeed>1</CurrentSpeed>
</r:GetTransportInfoResponse>
</s:Body>
</s:Envelope>

How do these Actions differ in terms of player status; is the response to GetTransportInfo enough for the MC DLNA controller config to be left in event mode or should polling mode still be the way to go?

I'm asking both for my own understanding and also because I'm not entirely sure that toggling that setting for that renderer has any effect. For what it's worth it seems to plays fine with both "Ignore Transport..." "Disable SetNext..." left unchecked, but perhaps I don't know what I should be looking for.

Cheers

Scobie

[AndrewFG]

The GetTransportSettings method returns information about the play back mode (normal, repeat, shuffle, etc.) of the renderer, and also its recording mode capabilities (if any). It is probably not a show stopper, but its lack of implementation is indicative of shoddy coding by the manufacturer. I don’t know if MC depends on this action in any critical way, or if the 602 error would cause problems in MC.

The critical methods are GetTransportInfo (which returns the player state STOPPED, PLAYING, TRANSITIONING, etc.) and GetPositionInfo (which returns the current play position). Both these methods are critical for MC to know what state the renderer is in, and what is happening with the play out process.

The UPNP standards mandate an Event Notification mechanism where the renderer pushes its changes of state (STOPPED, PLAYING, etc.) to the Control Point. This allows a MC to be informed immediately when the playing state changes. Some bad renderers don’t implement this notification mechanism properly (or it may be being blocked by the router), so MC can fallback to polling GetTransportInfo every few seconds (aka Ignore Transport Events). This fallback polling is slower and asynchronous, so it can lead to unpredictable command timing errors. Note that in such cases MC is doing its best to work around faults in the bad renderer, but it cannot always succeed.

[Scobie]

Thanks Andrew, clear and concise as always. From what you say it appears that GetTransportInfo is the more crucial of the 2 for reliable operation, and if present “Ignore Transport Events” can be safely left unchecked...?

Also given what you said re TransportSettings and playback mode, does that imply those actions would only make sense if the renderer was a media player of some sort? The one in question is an AVR, would it actually need them?

Cheers

[AndrewFG]

When a Control Point pushes media to a renderer it calls the method SetAVTransportURI to inform the renderer of a url that it must play.

The CP can push individual single tracks to a renderer through SetAVT.. commands (or its analog SetNextAVT.. for gap less play). In this case the CP itself handles functions like REPEAT (it calls SetAVT.. repeatedly passing the same url) or SHUFFLE (it calls SetAVT.. passing a preselected list or urls in random order).

However, it is also possible for the CP to call SetAVT.. and pass the url of a PlayList rather than the url(s) of single track. In this case the Playing Mode of the renderer determines the actual sequence (REPEAT, SHUFFLE) of the individual tracks being played. This playlist mode is less common, since a) not all renderers can do it, and b) (therefore) MC does not use it either..

[AndrewFG]

Thanks Andrew, clear and concise as always. From what you say it appears that GetTransportInfo is the more crucial of the 2 for reliable operation, and if present “Ignore Transport Events” can be safely left unchecked...?

Basically, yes.

An exception might be if the router, firewall, or A/V software is blocking the events. For UPNP commands the Control Point acts as “client”, and the renderer acts as “server”; whereas for event notifications the CP acts as “server” and the renderer as “client”. And some network infrastructure setups may route in one direction but not in the other. In such a case Ignore Transport Events could avoid the issue. But it would be better to fix the underlying network issue..

[Scobie]

Ok thats interesting thanks again for the explanation. Always comes down to the plumbing.

I imagine if your Whitebear software detects a response then the network is letting it through, so in that instance no issue.

[AndrewFG]

I imagine if your Whitebear software detects a response then the network is letting it through, so in that instance no issue.

It’s a reasonable assumption. And certainly true concerning the router and LAN setup. But it is still theoretically possible to have a firewall software on the PC that blocks incoming traffic to MC.exe but allows incoming traffic to the DMRA. Uncommon, but not impossible..

[Scobie]

Andrew I'd like to learn more about DLNA, can you recommend any resources?

I have the UPnP standards doc (600-odd pages) and have found 1 quite expensive ($180) book on Amazon, but is there an online resource or text that is available that you would recommend?

Thanks

[AndrewFG]

It’s an interesting question..

In the beginning was the UPNP organisation (www.upnp.org) which created the UPNP device architecture. Then within UPNP.org different working groups created specifications for different types of devices based on that architecture (e.g. printers, routers, lights, switches, and digital media renderers, digital media servers etc.). Then the Digital Living Network Alliance was created which took the UPNP DMR and DMS specifications and added precision to them (probably the 600 page document that you have). Then these standards were submitted to the International Standards Organisation and became adopted as ISO Norms. And finally as a result both UPNP.org and DLNA.org seem to have been dissolved. (If you browse to UPNP.org you will now be redirected to openconnectivity.org). So the original documents are actually quite hard to pull together now. I think they are on the ISO.org site, but you probably have to pay for them.