1 camera, endless problems

[wilderbee]

My setup is in the attached image.

When I am on the computer attached to the Netgear router, I can access the wireless camera web gui fine. When I try to connect to the NVR web gui, it is VERY slow, Live View doesn't work. Can't seem to setup any smart events due to no video preview displayed.

Any idea why the connection to the NVR is so bad? There is only 1 camera in this setup! (wireless is the only option unfortunately).

I thought the D-Link 5 port switch might be overloaded, but there isn't much else on it. Also, I can hit the camera live view over Hik-Connect no problem... I have turned down the resolution, played with bitrate etc. of the camera, but I think the fact that the web gui of the NVR is so slow, something else is wrong here.

Anyone have an idea? My next step is to move the NVR to the office, where the Netgear router is, which eliminates the D-Link switch altogether.

Thanks!

 

[wilderbee]

If this helps.... ping test from the PC to the NVR. Fast, but with drops?

 

[NoloC]

Problem is the WiFi. If you really can't run a wire, can you use powerline?
WiFi sucks for cams. UBNT does make solutions for point to point such as the Nanostation series stuff that works well.

 

[wilderbee]

Problem is the WiFi. If you really can't run a wire, can you use powerline?
WiFi sucks for cams. UBNT does make solutions for point to point such as the Nanostation series stuff that works well.

I agree. But surprisingly the WiFi camera works great on its own. I am just having issues hitting the NVR. Or the camera THROUGH the NVR.
I can watch the live feed over LTE from the camera no problem. So it's a strange one...

 

[NoloC]

Not really valid unless you test with something like vlc. Assume the NVR is rtsp and that is less tolerant of dropped packets.

 

[bp2008]

It could be as simple as a bad network cable or network port somewhere on the path between the Netgear router and the NVR.

A long-running ping test (more than just the 4 pings that is default for Windows' ping command) against the NVR could reveal if there is packet loss. This program is a really easy way to find out: Releases · bp2008/pingtracer · GitHub Crank it up to 10 pings per second and then try to access the NVR's web interface and see if the ping graph goes nuts.

 

[Trax95008]

My first thought was a bad cable as well. When you view the cam over the web, is the connection directly to the camera, or to the NVR? If your connecting to the camera, then your bypassing the NVR and that would suggest that the issue is either the NVR or the cable from the NVR to the switch. If your connecting to the NVR, then the cable must be good based on your diagram

 

[wilderbee]

The connection over the web is directly to the camera. (set it up that way because the NVR was such a slob)
Interesting. Thanks for the replies. I will try and swap out that cable, and see what happens. Also thinking that D-Link might be at it's knees with traffic? If the cable swap doesn't work, may try adding another switch in the mix.

 

[NoloC]

If the distance to the camera is only 15 feet from the switch as drawn, run a temporary cat5 cable and see what happens. I still suspect the WiFi. But wouldn't hurt to swap cables as suggested.

When you connect to the camera directly with a browser, that is different than the nvr connection which uses rtsp. You can emulate this by connecting to the camera with vlc which also uses rtsp. RTSP is tcp based in most cases (not udp), and therefore will not tolerate packet losses well. WiFi can be very unreliable and cause many such packet losses.

 

[bp2008]

TCP slows down as a result of packet loss. UDP loses data as a result of packet loss, but does not slow down.