MVP server binds to 127.0.0.1 after resume from standby

[alibert]

Hi,

I've upgraded my server, and it looks that an autostarted MVP server no longer binds to the server's external IP address after resuming from S3, but to the local loopback address 127.0.0.1 only, and my PCH won't connect. The following is logged in nrecord.log / mvp.log when resuming from standby:

Code:

2016-03-20 13:09:29.781    [DEBUG][18]    Resuming...
2016-03-20 13:09:29.825    [DEBUG][21]    Resuming...
2016-03-20 13:09:30.257    [DEBUG][6]    cycling MVP servers
2016-03-20 13:09:30.257    [DEBUG][6]    Starting MVP server 0
2016-03-20 13:09:38.924    [DEBUG][9]    Recording service noted the system was resuming...
2016-03-20 13:09:38.924    [DEBUG][9]    No C:\Users\Public\NPVR\Scripts\Wakeup.bat

Code:

[...startup]
2016-03-20 13:09:30.551    [DEBUG][1]    -mvpmode
2016-03-20 13:09:30.560    [DEBUG][1]    PluginResolveEventHandler: System.ResolveEventArgs
2016-03-20 13:09:30.560    [DEBUG][1]    Known plugin directories:
2016-03-20 13:09:30.560    [DEBUG][1]    Looking for assembly in (2) C:\Users\Public\NPVR\Plugins\common\NextPVR.resources.dll
2016-03-20 13:09:30.842    [DEBUG][1]    Looking for assembly in (3) C:\Program Files (x86)\NPVR\Plugins\common\NextPVR.resources.dll
2016-03-20 13:09:30.842    [DEBUG][1]    PluginResolveEventHandler: System.ResolveEventArgs
2016-03-20 13:09:30.842    [DEBUG][1]    Known plugin directories:
2016-03-20 13:09:30.842    [DEBUG][1]    Looking for assembly in (2) C:\Users\Public\NPVR\Plugins\common\NextPVR.resources.dll
2016-03-20 13:09:30.858    [DEBUG][1]    Looking for assembly in (3) C:\Program Files (x86)\NPVR\Plugins\common\NextPVR.resources.dll
2016-03-20 13:09:30.873    [DEBUG][1]    PluginResolveEventHandler: System.ResolveEventArgs
2016-03-20 13:09:30.873    [DEBUG][1]    Known plugin directories:
2016-03-20 13:09:30.873    [DEBUG][1]    Looking for assembly in (2) C:\Users\Public\NPVR\Plugins\common\NextPVR.resources.dll
2016-03-20 13:09:30.873    [DEBUG][1]    Looking for assembly in (3) C:\Program Files (x86)\NPVR\Plugins\common\NextPVR.resources.dll
2016-03-20 13:09:30.873    [DEBUG][1]    PluginResolveEventHandler: System.ResolveEventArgs
2016-03-20 13:09:30.873    [DEBUG][1]    Known plugin directories:
2016-03-20 13:09:30.873    [DEBUG][1]    Looking for assembly in (2) C:\Users\Public\NPVR\Plugins\common\NextPVR.resources.dll
2016-03-20 13:09:30.873    [DEBUG][1]    Looking for assembly in (3) C:\Program Files (x86)\NPVR\Plugins\common\NextPVR.resources.dll
2016-03-20 13:09:30.889    [INFO][6]    BOOTPWorkerThread() Hostname:  Kruemelmonster
2016-03-20 13:09:30.889    [DEBUG][3]    MVP Service Locator will resolve media port: 6337
2016-03-20 13:09:30.889    [INFO][3]    MVP Control thread Listening on port: 5916
2016-03-20 13:09:30.889    [INFO][6]    BOOTPWorkerThread IP Address 127.0.0.1
2016-03-20 13:09:30.905    [INFO][7]    MVP Streaming thread Listening on port: 8337
2016-03-20 13:09:30.905    [DEBUG][7]    MVP Service Locator will resolve media port: 8337
2016-03-20 13:09:30.920    [INFO][4]    ServiceLocatorThread() Hostname:  Kruemelmonster
2016-03-20 13:09:30.920    [INFO][4]    IP Address 127.0.0.1

I've already tried to add an implicit mapping from the server's hostname ("Kruemelmonster") to the external IP address, 192.168.178.10, but apparently still 127.0.0.1 is used.

After a regular boot or a restart of the server, it picks the external IP address correctly, and the PCH is able to connect without problems. Is there a way to statically configure the address, or is there anything else I could do?

-alibert

[mvallevand]

I see mine does this too after sleep. It is ok when it wakes up for recordings and EPG update so it must be a timing thing. It is listening on 0.0.0.0 though so I will likely need to see if this is a problem with a PCH next time I can boot one.

Martin

[alibert]

It may also have something to do with the windows firewall and it's different rules for "private" and "public" networks - I've actually also seen occurrences of successful connections after 127.0.0.1 was selected by the service locator, so this should bot be a general problem. Going to observe this.

-alibert