INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: herr_schneider on June 25, 2014, 02:15:22 pm
-
Hi there again,
while .145 seems to resolve the issue of DLNA after sleep, I now have figured that after several hours with no client accessing the DLNA server is lost again. This is reproducable behaviour and no client / controller will see the server until restart... I have tested the same procedure with other DLNA servers running exclusively and in parallel, but those did not get lost...
Your support is appreciated
Marcus
-
Hi there again,
while .145 seems to resolve the issue of DLNA after sleep, I now have figured that after several hours with no client accessing the DLNA server is lost again. This is reproducable behaviour and no client / controller will see the server until restart... I have tested the same procedure with other DLNA servers running exclusively and in parallel, but those did not get lost...
Your support is appreciated
Marcus
Running multiple servers in parallel on the same machine isn't a good idea since they all use the same port for SSDP discovery and this seems to cause lost packets.
In general we also recommend turning off the Windows Media Sharing service as well since it also uses that port.
-
Running multiple servers in parallel on the same machine isn't a good idea since they all use the same port for SSDP discovery and this seems to cause lost packets.
In general we also recommend turning off the Windows Media Sharing service as well since it also uses that port.
Bob, I haven't completely thought this through, so this quick comment may be completely off the mark, but do you set the SO_REUSE_ADDRESS attribute on your SSDP sockets? This allows multiple clents on the same machine to listen on the same port; otherwise a single client gets to steal the show.
-
Bob, I haven't completely thought this through, so this quick comment may be completely off the mark, but do you set the SO_REUSE_ADDRESS attribute on your SSDP sockets? This allows multiple clents on the same machine to listen on the same port; otherwise a single client gets to steal the show.
It looks like it's done unconditionally for our UDP sockets (of which there is only 1900)
Also, checking the multicast/broadcast issues.