Serviio not running after sleep mode

[DenyAll]

Hi npuser - did this work for you (I'm not experiencing the problem so cannot test)? Can anyone else confirm?

The reason I ask is that my understanding of the sleep problem is that Serviio's DiscoverySSDPMessageListener service doesn't survive Windows Sleep and needs to be re-started. The way Serviio restarts this service is either by the user restarting it (either manually or using the process above to restart the whole Serviio service) or by detecting a loss in the IP address - from my log file (server is on 198.168.0.2):

  Code:

2013-05-10 15:30:43,726 WARN  [DiscoveryAdvertisementNotifier] Cannot acquire NIC for current bound IP address 192.168.0.2, will re-acquire new IP
2013-05-10 15:30:43,726 INFO  [EventDispatcher] Leaving EventDispatcher
2013-05-10 15:30:43,726 INFO  [DiscoverySSDPMessageListener] Leaving DiscoverySSDPMessageListener
2013-05-10 15:30:43,726 INFO  [EventSubscriptionExpirationChecker] Leaving EventSubscriptionExpirationChecker, removing all event subscriptions
2013-05-10 15:30:43,773 WARN  [MultiCastUtils] Could not find NIC with name 'eth6-0'
2013-05-10 15:30:43,773 WARN  [LocalAddressResolverStrategy] Haven't found IP address for NIC eth6-0, will try again 9 times
2013-05-10 15:30:43,835 WARN  [MultiCastUtils] Could not find NIC with name 'eth6-0'
2013-05-10 15:30:43,835 WARN  [LocalAddressResolverStrategy] Haven't found IP address for NIC eth6-0, will try again 8 times
2013-05-10 15:30:48,515 INFO  [RendererExpirationChecker] Leaving RendererExpirationChecker
2013-05-10 15:30:48,889 WARN  [MultiCastUtils] Could not find NIC with name 'eth6-0'
2013-05-10 15:30:48,999 WARN  [LocalAddressResolverStrategy] Haven't found IP address for NIC eth6-0, will try again 7 times
2013-05-10 15:30:54,100 WARN  [MultiCastUtils] Could not find NIC with name 'eth6-0'
2013-05-10 15:30:54,100 WARN  [LocalAddressResolverStrategy] Haven't found IP address for NIC eth6-0, will try again 6 times
2013-05-10 15:30:59,184 WARN  [MultiCastUtils] Could not find NIC with name 'eth6-0'
2013-05-10 15:30:59,184 WARN  [LocalAddressResolverStrategy] Haven't found IP address for NIC eth6-0, will try again 5 times
2013-05-10 15:31:04,322 INFO  [Device] Updated bound IP address of Device with UUID: c41c5514-0d79-3774-967b-023b9e31d01f, bound address: 192.168.0.2
2013-05-10 15:31:04,322 INFO  [EventSubscriptionExpirationChecker] Starting EventSubscriptionExpirationChecker
2013-05-10 15:31:04,322 INFO  [DiscoveryAdvertisementNotifier] Starting DiscoveryAdvertisementNotifier
2013-05-10 15:31:04,322 INFO  [EventDispatcher] Starting EventDispatcher
2013-05-10 15:31:04,413 INFO  [DiscoverySSDPMessageListener] Starting DiscoverySSDPMessageListener using interface eth6 (Intel(R) 82566DM-2 Gigabit Network Connection) and address 192.168.0.2, timeout = 0

You can see in Line 1 that Serviio detects that it loses the address of the server (after awakening from sleep). It then goes through a process to shut its Listener and Event Subscription services down, re-acquire the address for the NIC, and then re-start the Listener and Event Services. It is the Listener service I believe that listens for messages from your TV or other DNLA device, and responds to say "I am here" - this then shows on your TV as the Serviio Server. If this process is not working there is a secondary process that advertises Serviio every three minutes (but by that time most TV's have either timed-out or the user gives up).

Does your registry hack mean that the IP address is never lost? If that is the case then wouldn't it mean that the above recovery by Serviio would never be triggered (as it doesn't lose its address, which is the trigger for this process)? Can you see if this process is triggered in your log?

ps. I have come across the problem of acquiring a dummy address - see viewtopic.php?f=5&t=10336&p=68829#p68829 - but Serviio would soon work out that the dummy address wasnt valid and then retrigger the recovery process again. There is a bitbucket for Serviio to ignore these (and other) dummy addresses.

[npuser]

I am running ubuntu 13x so i can't test.

This addresses the exact scenario you are describing. It tells system to retain IP address if the lease period is still valid even if computer is rebooted or wake up from suspended or hibernation mode. This tells system to not to use default APIPA rule (Automatic Private IP Addressing) instead retain or force to use previous ip hence DiscoverySSDPMessageLinsterner service will not restart as it see a valid IP still.

Read about it here http://support.microsoft.com/kb/958336

NPuser

[DenyAll]

Thanks npuser. Unfortunately we need the DiscoverySSDPMessageListener service to restart in this case.