Print

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

[mhwlng]

I have a UPNP control point on the same pc as MC and when I request metadata

local args = {itemid,
"BrowseMetadata",
"upnp:album,upnp:artist,upnp:genre,upnp:title, res@size,res@duration,res@bitrate,res@sampleFrequency,res@bitsPerSample,res@nrAudioChannels, res@protocolInfo, res@protection,res@importUri",
0,
1,
""}
local outargs = {}
_,outargs = UPNP.ContentDirectory:InvokeAction("Browse", args)


then I get results like :

<item xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" id="2005968.mp3" parentID="" restricted="true">
<dc:title xmlns:dc="http://purl.org/dc/elements/1.1/">Someone Else's Mess</dc:title>
<upnp:class xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/">object.item.audioItem.musicTrack</upnp:class>
<upnp:artist xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/">Abra Moore</upnp:artist>
<upnp:album xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/">No Fear</upnp:album>
<upnp:genre xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/">Rock</upnp:genre>
 <res protocolInfo="http-get:*:audio/mpeg:*" duration="0:03:37" size="5223362">http://169.254.2.2:49343/Music/2005968.mp3</res>
</item>

the MC pc has IP address 192.168.1.34


the IP address 169.254.2.2 is my windows mobile device (connected via activesync/usb)

also I have seen IP address 127.0.0.1

<res protocolInfo="http-get:*:audio/mpeg:*" duration="0:03:32"> size="4925440">http://127.0.0.1:49343/Music/2021033.mp3</res>

Marcel

[John Gateley]

This is a hard problem: the UPnP server is careful to use the IP address that corresponds to the network interface it received the request from. This is for multi-homed computers (fairly common nowadays).

If you request on localhost, it'll reply on localhost. The only thing I can suggest is to make the control point use the "real" IP address instead of localhost, even though it is on the same machine.

I'm open to suggestions too.

j

[mhwlng]

The control point API doesn't have any functions to influence what network interface to use :

http://msdn.microsoft.com/en-us/library/aa381109(VS.85).aspx

What would be useful is : if you could perhaps add a registry option, to optionally always use (the ip address of) a certain network interface ?

e.g.

UPNPNetworkInterface = "Atheros L1 Gigabit Ethernet 10/100/1000Base-T Controller"

the registry string is empty by default, which would result in the current behaviour ?

Marcel

[John Gateley]

This doesn't feel very elegant to me. Any other ideas? -- j

[mhwlng]

no, sorry...

I thought, that I came up with a 5 minute modification for you

I don't see any other way of preventing URI's like :

http://169.254.2.2:49343/Music/2005968.mp3
or
http://127.0.0.1:49343/Music/2005968.mp3

 (the problem only occurs when the upnp control point is on the same pc as MC, but the UPNP renderer is a different device)

I can't control the interface that the control point api selects...


Marcel

[John Gateley]

It's more like 30 minutes, but the part that is troublesome is that it is user-interface. If I could make a quick fix that was invisible, that'd be fine. But putting something that the user interacts with makes things more complex,  requires more support etc. I'd like to come up with a way to do this without changing the user interface.

I'm just guessing but the multicast search is probably going out on localhost, right?
One thing I could do would be to disable localhost entirely...

j

[mhwlng]

my suggestion was to have just a registry option, NO user interface at all, to make things easier for you..

It's not only localhost

http://169.254.2.2 is the address given by activesync to my windows mobile pda ?

Marcel

 

[John Gateley]

How is the 169.254.x.x address interfering?

j

[mhwlng]

my denon 3808 is at 192.168.1.254
169.254.2.2 is not reachable from that device

so, if I tell the denon to play this URI http://169.254.2.2:49343/Music/2005968.mp3

then nothing happens...

Marcel

[John Gateley]

How is the denon getting that URL? If I remember right, the server is careful to match URLs with interfaces so mismatches like that don't happen. Localhost + control point is different.

j

[mhwlng]

I'm not sure what you mean exactly

I don't get these at the same time :

http://169.254.2.2:49343/Music/2005968.mp3

http://127.0.0.1:49343/Music/2005968.mp3

I rebooted my pc (vista 64) and suddenly I got a different IP address in the xml data (see first post for code and reply)

one time I see this :

<res protocolInfo="http-get:*:audio/mpeg:*" duration="0:03:37" size="5223362">http://169.254.2.2:49343/Music/2005968.mp3</res>

another time I see this (after reboot)

<res protocolInfo="http-get:*:audio/mpeg:*" duration="0:03:37" size="5223362">http://127.0.0.1:49343/Music/2005968.mp3</res>

neither value is the correct value (which is 192.168.1.34)

there was no difference in any application configuration
the Operating System just decided to use a different network interface
or the PDA was unplugged, or something

Marcel

[JimH]

Two thoughts that may or may not be useful.

1.  169 something is the address that Windows shows if no IP address could be obtained.

2.  Windows gets confused sometimes about which network interface to use.  I've had to remove one a few times in order to get a machine to connect.

[mhwlng]

Hi Jim,

1) the 169 something ip address range is also used by the dhcp server built into activesync that gives out ip addresses to windows mobile devices connected via usb...

2) the problem is very specific to the fact that I don't use the control point (i.e. the user interface on the tv) built into the DENON, only the renderer (i.e. the music player)

in this particular case, the DENON does NOT connect directly to MC.
another program (that I made), tells the DENON what song to play, by sending the DENON an XML string, that it just received from MC (containing the URL of the song, see above).

a program on the SAME pc as jrmc connects to jrmc via upnp (without using IP addresses, this works via broadcasts sent by the microsoft upnp api, outside my control)
apparently sending/receiving broadcasts on the same pc are problematic (see above)

my application receives an XML packet from MC, that it simply passes on the the DENON, but the ip address inside the xml string that MC sends, is unreachable by the denon)

So that is why I have asked John for an option to 'lock' the network interface, so that I can influence what IP address ends up in the song's URL inside the XML packet.




Marcel

[John Gateley]

Hi Marcel,

I'll take a look at the code tomorrow, see what I can figure out.
I really don't understand how the 169 address is coming in...

j

[John Gateley]

I checked - I think the server is doing the right thing. When a request comes in, the server grabs the IP address of the interface it came in on. It uses this to build URLs in the response, both in requests for device descriptions and requests for metadata about tracks.

It should use the interface address, otherwise the IP address in the URL may correspond to the wrong interface, which may not be reachable at all from the UPnP device.

UPnP does not route well (you have to configure the multicast routing by hand). So the Server, Renderer and Control Point all should be on the same network segment. This means, modulo localhost, that using the interface IP address should provide the correct behavior.

What control point are you using? Did you write it yourself or did it come from somewhere else?

I don't understand how the control point is communicating with the server on the 169 address.

I still think that either the control point should be configurable to specify the network interface to use, or at worst that I should disable localhost on the server.

j

[mhwlng]

In the 'normal' situation the control point and renderer have the same IP address, then you would never have a problem.

in my situation, the control point and renderer have different ip addresses

and to make things more complicated, the control point is on the SAME pc as MC, which makes it hard to predict on what network interface the broadcast will be sent/received

control point+jrmc 192.168.1.34
renderer              192.168.1.254

the flow goes like this :

control point uses microsoft upnp api, which does NOT allow any selection of network interface or ip address :

this function call to the microsoft control point api (this is a COM DLL, see above for msdn link)  :

local deviceFinder = luacom.CreateObject("UPNP.UPnPDeviceFinder");
local deviceObj = deviceFinder:FindByUDN("uuid:31406D27-9330-4999-A8AB-8D39B48D657C")

this call results in a UPNP broadcast, which MC, on the SAME pc as where the broadcast packets originates, picks up and MC then figures out the ip address that it will use in the song URL.

later on in the process, the control point asks MC for information about a certain track.

MC returns an xml packet as in the first post with the IP address that it figured out when it received that UDL broadcast packet.

the control point connects to the renderer (different IP address) in exactly the same way as to the server :

local deviceObj = deviceFinder:FindByUDN( "uuid:5F9EC1B3-ED59-79BB-4530-0005CD161DF5" )

and it then passes the xml packet (see first post) from MC on to the renderer unchanged :

local args = {0,URI,XML}
AVTransport:InvokeAction("SetAVTransportURI", args)


the renderer then receives this xml packet, parses it, and then tries to contact http://127.0.0.1 or http://169.254.whatever to start streaming the mp3 song and obviously can't connect.... the only way it can connect is if the URL contains http://192.168.1.34


I believe that my earlier suggestion, is the only way to reliably fix this particular problem : where the UPNP server is on the SAME pc as the application calling the upnp control point api functions.

Marcel

[John Gateley]

control point uses microsoft upnp api, which does NOT allow any selection of network interface or ip address :

I believe this is a bug, specifically because of the trouble you are having now. A server can realistically be expected to reply on all interfaces, but not the control point - it should use a specific interface. Can you report this as a bug to Microsoft?

I believe that my earlier suggestion, is the only way to reliably fix this particular problem : where the UPNP server is on the SAME pc as the application calling the upnp control point api functions.

What I'll do is add a registry entry for interfaces to ignore - this is more in keeping with a Server than restricting it to a single interface.
But I still think this is a bug with the control point...

j