BUG: Invalid XML returned from (at least) UPNP GetMediaInfo invocation after playing track from DLNA server

Flesh

Member
Joined
Feb 18, 2024
Messages
43
@WiiM Support @WiiM Team

Using UPNP Tool on Android to view the XML returned by my WiiM Pro. Running latest version of firmware available to my device right now (4.8.611135).

After playing a track from a DLNA server, calling GetMediaInfo returns invalid XML -- the prefix "song" isn't declared. We should expect the xmlns:song declaration. WIthout it, strict XML parsers throw errors attempting to ingest this XML.

See below for full output from my call to GetMediaInfo. Please let me know if you need any other information.

Can this please be fixed? The lack of the namespace declaration is causing an error that prevents me from fully utilizing the Pro at this time.


XML:
<?xml version="1.0"?>
<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:sec="http://www.sec.co.kr/">
    <item id="0f5e5f493ca0ef8750aff86978cbd452" parentID="d5b751ddaac6cb1262c54837f9ec0718" restricted="1">
        <dc:title>pink-noise</dc:title>
        <upnp:class>object.item.audioItem.musicTrack</upnp:class>
        <res protocolInfo="http-get:*:audio/wav:DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01D00000000000000000000000000000">http://10.111.24.20:8096/audio/0f5e5f49-3ca0-ef87-50af-f86978cbd452/stream.wav?DeviceProfileId=4fe7bc9ee8e841f5956bb7b529337f46&amp;DeviceId=test&amp;MediaSourceId=0f5e5f493ca0ef8750aff86978cbd452&amp;Static=true&amp;Tag=42ea25c8922d5c78ce7555e2838592f5&amp;dlnaheaders=true</res>
        <song:rate_hz>44100</song:rate_hz>
        <song:format_s>16</song:format_s>
        <song:bitrate>705</song:bitrate>
    </item>
</DIDL-Lite>
 
Ok, I posted the latest WiiM Amp firmware, looks like you posted the latest Pro Plus version which is older than that. I suspect the next firmware version for the Pro Plus might well include that fix too. You should note however that new firmware is rolled out gradually over the entire estate, normally over a period of a few days to a week.
All of that makes sense, except that I also was told I was on the early access list, so I would have expected to see it by now.
 
All of that makes sense, except that I also was told I was on the early access list, so I would have expected to see it by now.
That’s presuming they’ve actually included the fix yet in the Pro Plus firmware. Please be patient, I’m sure it’ll come soon.
 
That’s presuming they’ve actually included the fix yet in the Pro Plus firmware. Please be patient, I’m sure it’ll come soon.
I'm confused perhaps more, because this entire thread was started regarding the WiiM Pro, not the WiiM Amp. I was told "mid-April" hence the questions at this point that my early-access listing hasn't seen anything hitting the devices yet. Just looking for an updated schedule from @WiiM Support -- not being impatient. :)
 
I'm confused perhaps more, because this entire thread was started regarding the WiiM Pro, not the WiiM Amp. I was told "mid-April" hence the questions at this point that my early-access listing hasn't seen anything hitting the devices yet. Just looking for an updated schedule from @WiiM Support -- not being impatient. :)
Ok, sorry, I just recalled having seen the fix on a recent firmware update and didn’t check the thread title, but as I said, if they’ve fixed it for one model, they’re likely to planning to fix it across the board :)
 
Looks like song is declared on the current version of the Pro firmware...

XML:
<?xml version="1.0"?>
<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
           xmlns:song="www.wiimu.com/song/"
           xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">
    <upnp:class>object.item.audioItem.musicTrack</upnp:class>
    <item id=""> <song:subid></song:subid>
        <song:description></song:description>
        <song:skiplimit>0</song:skiplimit>
        <song:id>100477306</song:id>
        <song:like>0</song:like>
        <song:singerid>710</song:singerid>
        <song:albumid>100477305</song:albumid>
        <song:quality>2</song:quality>
        <song:actualQuality>LOSSLESS</song:actualQuality>
        <song:atmos>0</song:atmos>
        <song:guibehavior></song:guibehavior>
        <song:soundScapeType></song:soundScapeType>
        <song:playCase></song:playCase>
        <song:originSource>Tidal</song:originSource>
        <res protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;" duration="00:03:27.000"></res>
        <dc:title>Over The Rainbow</dc:title>
        <upnp:artist>Sarah Vaughan</upnp:artist>
        <upnp:album>In The Land Of Hi-Fi</upnp:album>
        <upnp:albumArtURI>https://resources.tidal.com/images/e5d6cb96/b041/433a/9e4c/6806477a4c11/640x640.jpg</upnp:albumArtURI>
        <song:rate_hz>44100</song:rate_hz>
        <song:format_s>16</song:format_s>
        <song:bitrate>563</song:bitrate>
    </item>
</DIDL-Lite>
 
@WiiM Support is version 4.8.612733 supposed to be the one that resolved this issue? I am still seeing the same issue after using the WiiM as a DLNA renderer to play from a DLNA server (unbound "song" prefix).
 
@WiiM Support is version 4.8.612733 supposed to be the one that resolved this issue? I am still seeing the same issue after using the WiiM as a DLNA renderer to play from a DLNA server (unbound "song" prefix).
There seem to be a .614047 starting to roll out with that fix mentioned in the release notes if my memory isn't failing me (it hasn't hit my Pro plus yet). I'd say wait a few days....
 
Looks like song is declared on the current version of the Pro firmware...

I've just come across this thread because I was looking for solutions to a similar-ish problem with the WiiM Pro Upnp responses. I believe that the <upnp:class> element should be inside the item object that it is describing the type of. In the XML snippet that you've posted above it is in the wrong place. I'm getting the same from my WiiM Pro running the latest firmware, which causes the Python DIDL-Lite library to fail to parse track information. Interestingly, the XML at the start of this thread does have <upnp:class> in the right place.

Anyway, just an FYI. I've raised a ticket but thought that I would mention it here as this thread is only a couple of weeks old.
 
Back
Top