Results 1 to 3 of 3

Thread: MVP server binds to 127.0.0.1 after resume from standby

  1. #1
    Join Date
    Apr 2005
    Posts
    976

    MVP server binds to 127.0.0.1 after resume from standby

    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

  2. #2
    Join Date
    May 2006
    Location
    Canada
    Posts
    28,510
    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

  3. #3
    Join Date
    Apr 2005
    Posts
    976
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •