IPB

Welcome Guest ( Log In | Register )

> foobar2000 Development Forum Rules

This forum is for developer discussions only. If you have a problem / bug report / idea / feature request that isn't related to foobar2000 SDK, post it in an appropiate forum instead - tech support questions go to support forum, everything else goes to general forum.
All non-developer posts on this forum will be removed. Continued abuse of this forum will result in admin actions (warnings, account suspension).

 
Reply to this topicStart new topic
UPnP plugins: bug in talking to renderers, There seems to be a bug in two independend UPnP plugins
hzeller
post Jun 15 2013, 20:04
Post #1





Group: Members
Posts: 2
Joined: 15-June 13
Member No.: 108674



This is a post somewhere between support and developer forum I guess, but since I have pretty concrete analysis of the actual problem, this is probably better in the developer forum.

I think I've found a bug in these independent UPnP plugins for foobar2000
- UPnP MediaRenderer Output 1.0 beta 4
- UPnP/DLNA Renderer, Server, Control Point 0.99.46
This happens when connecting with a media renderer. Given that both these independent plug-ins are affected lets me assume that this might a problem with the underlying library, though I couldn't really verify that. Or maybe you used the same wrong example code-snippet somewhere ?

I am developer of gmrender-resurrect ( https://github.com/hzeller/gmrender-resurrect ), a media renderer based on gstreamer, so have seen this on the protocol level and am pretty confident that this is a problem in these plugins. I have added a workaround for this - however, this should be fixed 'at the source'.

The problem I see is that the plugins seem to have a problem with the device descriptor, more notably with the serviceId. By default, gmrender reports the serviceType for the transport service to be "urn:schemas-upnp-org:service:AVTransport:1" - which is required to recognize the service to be a transport layer.

Next to the serviceType, there is a serviceId field, that identifies the service in that device, usually, this is something like "urn:upnp-org:serviceId:AVTransport", but AFAIK can be of any string (it is only to be used to identify a particular instance of such a service when doing quries to the renderer). If you look around some device listing for renderers on http://www.upnp-database.info/ you see that strings are typically like that
(look at the serviceId row):

XMBC
http://www.upnp-database.info/service.jsp?serviceId=1583

some internet enabled TVs
http://www.upnp-database.info/service.jsp?serviceId=1924
http://www.upnp-database.info/service.jsp?serviceId=1820

What do I see with foobar2000 ?

When a different serviceId than serviceType is offered foobar2000, then the UPnP Media Renderer plugin reacts with 'XML error'. The UPnP/DLNA Renderer plugin does not spit out any error, but it refuses to 'Play'. When play is pressed, then is see on the renderer side, that the AVTransportURI is set, but then no 'Play' command issued - hence I assume that this plugin has the same problem with the plugin than the first one.

What it should do instead ?
The serviceId string should not matter.

I assume, somewhere there is a mixup in the code between serviceId vs. serviceType. Some code that verifies that serviceType is actually a proper transport service type - but accidentally the value is compared with the serviceId - so this then fails if the serviceId does not happen to be the same value.

You might ask, how this error could not have been detected before ? Interestingly, looking at foobar2000, the serviceId there is actually the same (minus some suffix) as the serviceType
http://www.upnp-database.info/service.jsp?serviceId=358
So I assume that you only tested with foobar2000 and it happened to have worked with it. This means, that foobar2000 works with itself, but not with the overwhelming majority of standard conforming media players.

I have now worked around this problem in gmrender-resurrect, see https://github.com/hzeller/gmrender-resurre...transport.c#L50 .. but of course, you should find the typo and fix it in foobar2000.

-henner
Go to the top of the page
+Quote Post
hzeller
post Jun 20 2013, 23:21
Post #2





Group: Members
Posts: 2
Joined: 15-June 13
Member No.: 108674



Alright, I found the problem, and it is not a problem in foobar2000 or the UPnP plugins, but indeed a typo in the code of gmrender-resurrect. When passing an argument to some UPnP library call, the service-ID was passed, but should've been the service-type as it was used to construct the xml-namespace.

Fixed now. So sorry to bother you.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 28th December 2014 - 04:36