Clients taking ages to start(30sec)

[imilne]

Just tried it on a freshly installed (Windows and NPVR) desktop that's on gigabit wired and startup was near instant. I'll double check with a wired connection on my laptop, but that suggests it might be a plugin issue, and the only ones on that laptop are my own :eek:

Iain

[jpsa]

Just a quick note to say that I'm seeing slow client startup too, but in my case it wasn't 2.6.2 which caused it, it was upgrading both client & server to W7 from XP. I'd assumed it was probably firewall related, but haven't got round to investigating further yet.

[jpsa]

I'd assumed it was probably firewall related, but haven't got round to investigating further yet.

OK, I've done a little investigation, and I'm still puzzled! Here's an extract from the client logs from a slow startup

Code:

:
2013-04-09 11:13:00.994    [DEBUG][1]    Load@7
2013-04-09 11:13:05.527    [INFO][3]    Checking online for updated versions...
2013-04-09 11:13:05.527    [INFO][3]    Web@1
2013-04-09 11:13:05.895    [INFO][3]    Online check reports version info:
<version><component name="NextPVR" version="2.6.2" display="NextPVR 2.6.2"><url>http://forums.nextpvr.com/showthread.php?53816-2-6-2-available-(March-24th)</url></component></version>
2013-04-09 11:13:05.896    [INFO][3]    current online version: 2.6.2
2013-04-09 11:13:05.896    [INFO][3]    last notified version: 2.6.2
2013-04-09 11:13:22.009    [DEBUG][1]    Load@8
:

I can confirm that turning off the Windows firewall on the server cures the problem. However, the firewall is already configured to allow NRecord.exe full access. In addition, turning on firewall logging apparently shows no rejected connection attempts.

Code:

2013-04-09 10:58:29 ALLOW UDP 192.168.0.4 255.255.255.255 138 138 0 - - - - - - - RECEIVE
2013-04-09 10:58:30 ALLOW UDP fe80::95c5:4952:2041:efdd ff02::1:3 62988 5355 0 - - - - - - - RECEIVE
2013-04-09 10:58:30 ALLOW UDP 192.168.0.2 224.0.0.252 63011 5355 0 - - - - - - - RECEIVE
2013-04-09 10:58:30 ALLOW UDP fe80::1ce4:15c9:9fcd:aa81 fe80::95c5:4952:2041:efdd 5355 62988 0 - - - - - - - SEND
2013-04-09 10:58:30 ALLOW UDP 192.168.0.5 192.168.0.2 5355 63011 0 - - - - - - - SEND
2013-04-09 10:58:30 ALLOW UDP fe80::1ce4:15c9:9fcd:aa81 fe80::95c5:4952:2041:efdd 5355 64307 0 - - - - - - - SEND
2013-04-09 10:58:30 ALLOW UDP fe80::1ce4:15c9:9fcd:aa81 fe80::95c5:4952:2041:efdd 5355 60299 0 - - - - - - - SEND
2013-04-09 10:58:30 ALLOW UDP 192.168.0.5 192.168.0.2 5355 61765 0 - - - - - - - SEND
2013-04-09 10:58:30 ALLOW UDP fe80::1ce4:15c9:9fcd:aa81 fe80::95c5:4952:2041:efdd 5355 51171 0 - - - - - - - SEND
2013-04-09 10:58:30 ALLOW TCP fe80::95c5:4952:2041:efdd fe80::1ce4:15c9:9fcd:aa81 51566 445 0 - 0 0 0 - - - RECEIVE
2013-04-09 10:58:30 ALLOW UDP fe80::1ce4:15c9:9fcd:aa81 fe80::95c5:4952:2041:efdd 5355 57523 0 - - - - - - - SEND
2013-04-09 10:58:30 ALLOW UDP 192.168.0.5 192.168.0.2 5355 61337 0 - - - - - - - SEND
2013-04-09 10:58:30 ALLOW UDP fe80::1ce4:15c9:9fcd:aa81 fe80::95c5:4952:2041:efdd 5355 60802 0 - - - - - - - SEND
2013-04-09 10:58:38 ALLOW UDP 192.168.0.1 239.255.255.250 1900 1900 0 - - - - - - - RECEIVE
2013-04-09 10:58:47 ALLOW UDP 127.0.0.1 239.255.255.250 1900 1900 0 - - - - - - - SEND
2013-04-09 10:58:47 ALLOW UDP 192.168.0.5 239.255.255.250 1900 1900 0 - - - - - - - SEND
2013-04-09 10:58:47 ALLOW UDP ::1 ff02::c 1900 1900 0 - - - - - - - SEND
2013-04-09 10:58:47 ALLOW UDP fe80::1ce4:15c9:9fcd:aa81 ff02::c 1900 1900 0 - - - - - - - SEND
2013-04-09 10:58:51 ALLOW TCP 192.168.0.2 192.168.0.5 51569 8968 0 - 0 0 0 - - - RECEIVE

(this firewall log from a different session to the client log above).

Can anyone knowledgeable give me any clues about what NPVR does just prior to the Load@8 log entry, so I have some idea where to look next?

[sub]

Can anyone knowledgeable give me any clues about what NPVR does just prior to the Load@8 log entry, so I have some idea where to look next?

Between "Load@7" and "Load@8", the client makes it's first network request to the server, making a simple call to ask what the list of available record directories are configured on the server. Its not passing a lot of data, just a simple string of text.

[jpsa]

Between "Load@7" and "Load@8", the client makes it's first network request to the server...

Thanks!

I have a bit more information: as you suggested near the top of this thread, I tried replacing the server name ("laphroaig") with an ip address ("192.168.0.5") and that was enough to cure the problem here, even though the firewall was still active. I note this differs from stustunz's reported experience.

I'm still not sure why there's a problem, though: executing "ping laphroaig" on the client works instantly, so there's no general delay in resolving names.

[Zeb]

Just tried it on a freshly installed (Windows and NPVR) desktop that's on gigabit wired and startup was near instant.

@imilne: I notice that this problem is as un-American as h.264. Did you update Windows (including the infamous platform update) before installing NPVR (or at least before Patch 2), or did you patch first and update Windows later on your freshly-installed desktop?

@jpsa: Same question with respect to your upgrade to Windows 7: Did you update Windows 7 first or install Patch 2 first? Granted, this very likely has nothing to do with the problem.

[imilne]

@imilne: I notice that this problem is as un-American as h.264. Did you update Windows (including the infamous platform update) before installing NPVR (or at least before Patch 2), or did you patch first and update Windows later on your freshly-installed desktop?

Windows got all its updates before NPVR went on.

I still haven't had time to do further testing on this...maybe this weekend...

Iain

[jpsa]

@jpsa: Same question with respect to your upgrade to Windows 7: Did you update Windows 7 first or install Patch 2 first? Granted, this very likely has nothing to do with the problem.

I performed a clean installation of Windows 7 together with all online updates, around September last year. I then installed the then current NPVR, together with the current patches rollup, and AFAIR this problem was immediately apparent (but not annoying enough for me to do anything about it!)

[stustunz]

Yeah Microsoft has f@&$ed the firewall and admin rights

[jpsa]

I have a bit more information: disabling IPV6 on the client via

Control Panel -> Network and Internet -> Network and Sharing Center
Local Area Connection -> Properties

seems to cure the slow startup for me. I've actually disabled it on both client and server, but I think it was the client which made the difference. If anyone else suffering from this problem doesn't need IPV6, this could be a suitable workround for them.

Unfortunately I still don't know *why* disabling IPV6 helps...