Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DLNA uses wrong IP address #4

Closed
dogbertai opened this issue Oct 1, 2015 · 5 comments
Closed

DLNA uses wrong IP address #4

dogbertai opened this issue Oct 1, 2015 · 5 comments

Comments

@dogbertai
Copy link

I have multiple Ethernet interfaces. When I try to connect with a DLNA player, it uses the wrong IP address.

@sebastienwarin
Copy link
Member

The SWYH's DLNA server included for PCM and MP3 stream, one resource per network interface. So each stream is exposed on all your network interfaces of your machine.

For example, on my laptop I have 3 network interfaces (on 3 different networks), so each stream has 3 resources :
multiple ressource

It's the responsibility of your DLNA Media Renderer to choose the correct resource that is available to it (IP of the same network).

Otherwise, in the "HTTP Live Streaming" window, I display the first IP address, but you can use anyone !

@dogbertai
Copy link
Author

SWYH 1.4 is on Windows 7 with
eth0 192.168.0.5/255.255.255.0
eth1 172.16.0.5/255.255.255.0

VLC for iOS is on 192.168.0.20
Selecting "Music/Stream What You Hear MP3"
It tries to connect to 172.16.0.5:3727/stream/swyh.mp3
Connection fails

UPnP Device Architecture Version 1.1
"Multi-homed devices MUST send the search response using the same UPnP-enabled interface on which the search request was received. The URL specified in the LOCATION field value MUST specify an address that is reachable on that interface."

@sebastienwarin
Copy link
Member

Hi dogbertai,

I have check the code and I do test with network analyzer (Wireshark & Upnp Device sniffer) ! SWYH is compliant the UPnP Device Architecture, the Location field is correctly specify the remote address !

SWYH listens on UDP port 1900 (SSDP) and when it receives a M-SEARCH request, it's reply HTTP 200 with Location set to the local address of the interface on which the search request was received ! For example, my laptop is on 3 different networks with Ipv4 & v6, so when I send a multicast M-SEARCH request on each interfaces, SWYH reply his correct location for each.

swyh ip

So SWYH is detectable and any UPnP/DLNA client can connect to the SOAP service on the correct IP address to discover the contents of the Media Server.

Once connected to the SWYH's SOAP service, VLC can now "see" the "Music" folder containing the two media streams (PCM & MP3). The fact that VLC can discover the contents of the SWYH's Media Server proves that network connectivity between VLC and SWYH is working well.

Then the two media streams ("audioItem.audioBroadcast") exposed by SWYH contains various properties such as title, artist, genre .... and a resources list that describes the media format (bitrate, bit, channel) and especially the URI (contentUri) for all network interfaces.

So if VLC can discover SWYH on your network and connect to the Media Server to get the media streams I don't think this is a bug in the implementation of UPnP / SSDP in SWYH. I think that VLC doesn't selects the right contenUri in the resources list of the media.

Maybe because your two network interfaces have the same network mask?

@dogbertai
Copy link
Author

It's the responsibility of your DLNA Media Renderer to choose the correct resource that is available to it (IP of the same network).

Do you have a source for this?

I've been trying to search for more information.

One document I've seen states that most implementations only choose the first resource.
I've seen documents that refer to other attributes like protocol and bitrate, but I haven't seen anything that refer to discriminating based on IP address.
Are DLNA clients required to have a failover? If one resource fails, try the next?

I think the purpose of multiple resources is to provide content in different formats. I don't think it should be to list server-IPs other than the one the client already found and is talking to.

I understand these don't explicity say it, but here are more quotes with the same general idea from UPnP Device Architecture Version 1.1

However, as a general principle, related interactions between control points and devices (e.g. action control request and response messages, event subscription and event messages) MUST occur using the same pair of outgoing and incoming UPnP-enabled interfaces.

On a multi-homed device, all fully qualified URLs contained in response arguments that refer to resources on the device MUST be reachable on the UPnP-enabled interface on which the response message is sent.

On a multi-homed device, all fully-qualified URLs contained in event body that refer to resources on the device MUST be reachable on the UPnP-enabled interface on which the event message is sent.

@sebastienwarin
Copy link
Member

Hi,

I have released a new version to fixes this issue : https://github.com/StreamWhatYouHear/SWYH/releases/tag/1.4.15258.0

I don't have any problem with other client than VLC (tested with Windows Media Player and Intel Media renderer) so I think that the DLNA client should try all resources.

But as I know the receiver IP used to query the ContentDirectory service, I have updated my code to include only this IP, so the resources, and especially the Content URI, are different depending on the caller. So the DLNA client will get only one IP, the same as he used to query service.

Best,

sebastienwarin added a commit that referenced this issue Nov 12, 2015
Fixes #5 : regression by issue #4
Adding the Developer Tools for UPnP libs to the solution for easily debugging
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants