[SanMiggel]

Dear community,

I'm not quite sure if I should call my problem a bug or a feature request.
As probably way too often there is an incompatibility with my Yamaha Receiver R-N500 and upnp network playback from xbmc.
When traversing folders on xbmc media server via upnp, the receiver sometimes shows "Access Error" and drops back into the root directory.

I tracked down the problem using WireShark. It seems that the Yamaha receiver sends a malformed URL to xbmc. The ampersand in the xml-request is not properly escaped. For your reference see the recorded packets of a good request and a bad request below.

It is clearly a bug in the Yamaha firmware and I complained already the their support - but was is the chance that they are actually fixing it? Du you have any ideas for a workaround from the xbmc side? I would be more than happy to continue using xmbc for this!

Best regards,
Michael Leigsnering

Good request:

Code:

POST /ContentDirectory/370e8b57-d95a-49c0-b4ed-3b1fa5041525/control.xml HTTP/1.1
Host: 192.168.178.20:1964
SOAPACTION: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse"
USER-AGENT: KnOS/3.2 bridgeCo-DMP/3.0 DLNADOC/1.50 INTEL_NMPR/2.0
CONNECTION: close
CONTENT-TYPE: text/xml; charset="utf-8"
Content-Length: 651

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
<ObjectID>musicdb://artists/10/?albumartistsonly=false</ObjectID>
<BrowseFlag>BrowseDirectChildren</BrowseFlag>
<Filter>@childCount,dc:creator,upnp:album,upnp:artist,res,res@protection,res@duration,res@size,upnp:albumArtURI,upnp:searchClass</Filter>
<StartingIndex>0</StartingIndex>
<RequestedCount>50</RequestedCount>
<SortCriteria>+dc:title</SortCriteria>
</u:Browse>
</s:Body>
</s:Envelope>

HTTP/1.1 200 OK
Ext:
Date: Thu, 10 Jul 2014 19:48:55 GMT
Content-Length: 1114
Content-Type: text/xml; charset="utf-8"
Connection: close
Server: UPnP/1.0 DLNADOC/1.50 Platinum/0.6.9.1

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><u:BrowseResponse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"><Result>&lt;DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/"&gt;&lt;container id="musicdb://artists/10/21/?albumartistsonly=false&amp;amp;artistid=10" parentID="musicdb://artists/10/?albumartistsonly=false" restricted="1"&gt;&lt;dc:title&gt;Ceu&lt;/dc:title&gt;&lt;dc:creator&gt;Unknown&lt;/dc:creator&gt;&lt;upnp:artist role="Performer"&gt;Ceu&lt;/upnp:artist&gt;&lt;upnp:artist role="AlbumArtist"&gt;Ceu&lt;/upnp:artist&gt;&lt;upnp:album&gt;Ceu&lt;/upnp:album&gt;&lt;upnp:class&gt;object.container.album.musicAlbum&lt;/upnp:class&gt;&lt;/container&gt;&lt;/DIDL-Lite&gt;</Result><NumberReturned>1</NumberReturned><TotalMatches>1</TotalMatches><UpdateID>0</UpdateID></u:BrowseResponse></s:Body></s:Envelope>

Bad request (immediately following after the above request):
Note that the ampersand in the <ObjectID> xml tag is not escaped.

Code:

POST /ContentDirectory/370e8b57-d95a-49c0-b4ed-3b1fa5041525/control.xml HTTP/1.1
Host: 192.168.178.20:1964
SOAPACTION: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse"
USER-AGENT: KnOS/3.2 bridgeCo-DMP/3.0 DLNADOC/1.50 INTEL_NMPR/2.0
CONNECTION: close
CONTENT-TYPE: text/xml; charset="utf-8"
Content-Length: 682

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
<ObjectID>musicdb://artists/10/21/?albumartistsonly=false&artistid=10</ObjectID>
<BrowseFlag>BrowseDirectChildren</BrowseFlag>
<Filter>@childCount,dc:creator,upnp:album,upnp:artist,res,res@protection,res@duration,res@size,upnp:albumArtURI,upnp:searchClass</Filter>
<StartingIndex>0</StartingIndex>
<RequestedCount>50</RequestedCount>
<SortCriteria>+upnp:originalTrackNumber</SortCriteria>
</u:Browse>
</s:Body>
</s:Envelope>

HTTP/1.1 500 Bad Request
Date: Thu, 10 Jul 2014 19:48:58 GMT
Connection: close
Server: UPnP/1.0 DLNADOC/1.50 Platinum/0.6.9.1

[Robinaut]

Hello SanMiggel,

I'm encountering the same problem with my Yamaha Receiver R-N500 and XMBC running on a Raspberry Pi. In my case, "Access Error" only shows up when I want to browse the UPNP database by "Artists". Strangely, there is no problem with browsing by "Album" or "Interpret".

Did you find any solution or workaround to this problem? This bug is really annoying....

Greetings,

Robinaut

[SanMiggel]

Hi,

The problem was exactly the same for me: it works for some categories, but fails for other. I actually managed a workaround, however, it requires building XBMC from source (I used the current gotham master). Furthermore, it probably breaks the media center capabilities for any other devices than the Yamaha Receiver.

Here is what I did:

• As stated above, the problems lies in the escaping of the URL.
  
• The workaround is patching the file lib/libUPnP/Platinum/Source/Devices/MediaServer/PltMediaItem.cpp
  
• I simply added another layer of escaping for the m_ObjectID (see diff/patch below).
  

As I said, it's not nice and probably breaks things, but at least it works.

Best
SanMiggel

Here is the diff/patch:

Code:

--- PltMediaItem.cpp.orig    2014-10-24 09:40:48.655501537 +0200
+++ PltMediaItem.cpp    2014-07-21 21:41:28.358064533 +0200
@@ -919,21 +919,30 @@
}

/*----------------------------------------------------------------------
|   PLT_MediaContainer::ToDidl
+---------------------------------------------------------------------*/
NPT_Result
PLT_MediaContainer::ToDidl(NPT_UInt64 mask, NPT_String& didl)
{
    // container id property
     didl += "<container id=\"";
-    PLT_Didl::AppendXmlEscape(didl, m_ObjectID);
+    
+    /* Yamaha Quirk: add another layer of escaping */
+    NPT_String tempStr;
+    PLT_Didl::AppendXmlEscape(tempStr, m_ObjectID);
+    PLT_Didl::AppendXmlEscape(didl, tempStr);
+    
+    /*end quirk*/
+    
+    // original line
+    //PLT_Didl::AppendXmlEscape(didl, m_ObjectID);

    // parent id property
     didl += "\" parentID=\"";
     PLT_Didl::AppendXmlEscape(didl, m_ParentID);
    
    // ref id
     if ((mask & PLT_FILTER_MASK_REFID) && !m_ReferenceID.IsEmpty()) {
        didl += "\" refID=\"";
        PLT_Didl::AppendXmlEscape(didl, m_ReferenceID);
     }

[Montellese]

We've come across a few UPnP clients which have this problem. At least one of them is even DLNA certified yet has the exact same flaw in the XML processing. Personally I think embedding XML inside XML by escaping < and > is a very stupid idea but unfortunately that's how the UPnP specification has defined it.

I'm not sure if there's a generic workaround which works for standard and non-standard clients. The only thing I can think of is not using URLs that contain an ampersand but that would be a rather huge rewrite inside XBMC core.

We do support some client quirks by trying to identify the client and then acting differently but that's mostly different values and not something as general as data encoding.

[SanMiggel]

Great to hear a comment from a developer. The whole UPnP thing seem overly complicated and error prone... In fact the Yamaha R N-500 is also DLNA certified.
See http://europe.yamaha.com/en/products/aud.../r-n500_g/
So much for that...

I also tried to think of a better workaround than my simple quirk. However, I gave up quickly when thinking about the implications.
Should I still write a bug report for this? Maybe this helps keeping track of the issue for the future...

[Montellese]

IIRC there already was a bug report but I closed it because the bug is not in XBMC. But you can add your findings to it.

[SanMiggel]

Good, I added my findings in the bug report. Hopefully it will be re-opened one day...

[Robinaut]

Thanks a lot for tracking this issue!