-
Notifications
You must be signed in to change notification settings - Fork 93
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
Comments
SWYH 1.4 is on Windows 7 with VLC for iOS is on 192.168.0.20 UPnP Device Architecture Version 1.1 |
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. 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? |
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 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
|
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, |
I have multiple Ethernet interfaces. When I try to connect with a DLNA player, it uses the wrong IP address.
The text was updated successfully, but these errors were encountered: