Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: UPnP plugins: bug in talking to renderers (Read 3992 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

UPnP plugins: bug in talking to renderers

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

UPnP plugins: bug in talking to renderers

Reply #1 –
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.