Subscriber Discussion

Network And NVR Problems/Questions

Avatar
Greg M. Ray
Nov 26, 2013

I have had an ongoing issue of one GeoVision IP box camera running for 3-4 day's then loosing connection on network or "connection loss" on NVR since installation. This install is at my boat storage unit 100 miles south of Houston and no remote viewing hard to examine. I thought I had it fixed and I posted a reply (why are my cameras falling off line)thinking I was helping of course fix didn't as instructed by GeoVision. I needed to get video of domestic dispute for clients lawyer after wife took 100k boat.

As I started to review the recorded video the NVR software it became so corrupted machine would reboot every time I entered search mode (files were ok on drive thank God). Brought machine to office and the DVR card in machine failed on repeated start up's then power supply within minutes of each other. I pulled video card reinstall on another machine it failed so mother board was ok. I have since purchased new capture card and power supply uninstalled NVR software and reinstalled newest version. Then repaired recorded data based because I had lost IP cameras completely in drop down menu so that fixed it.

Nevertheless it was brought to my attention (network engineer) my subnet address need to all match or this could attribute to my problems. I have no router or internet connection he stated gateway mismatch would not drop signal GeoVision disagreed said third octave needs to match gateway factory setting 192.168.0.1 I need more opinions on my situation.

Network card IP on machine is: 192.168.88.100 Subnet mask: 255.255.255.0 Gateway: 192.198.88.1

I am using Avalan 5.8 MHz radios set at 192.168.88.10 and .12 for pair. I spoke with Avalan technician Tuesday before failures as we measured bandwidth signal strength, etc. I have 3-IP cameras not a problem with very good frame rates on recordings and live view. I mention this prior to failure IE or Google direct login showed live video as NVR said "no connection" .

Sunday with repaired machine I looked at both radio's and subnet mask was 255.255.0.0 on both radios never checked it. I changed it to match network card on machine.

I then checked subnet and set the gateway as 192.168.88.1 on cameras it was 192.168.0.1 despite what he said figuring it couldn't hurt. Does this have any relevance (gateway settings across the board) to my networking if not using a router and just a switch? All suggestions welcome will return after Thanksgiving on Friday to see if this theory has any merit hopefully connection stays up. Not sure what video streams other than H.264 camera is sending system says 2 Codec sreams in querry when adding cams to software. I'm guessing with corrupted software viewable on IE and not NVR there are different video streams H.264 and JPEG and if so how is that possible when the NVR says "connection loss" and still viewable through browser?

MI
Matt Ion
Nov 28, 2013

The gateway setting shouldn't make any difference as all communications within a subnet should occur directly - any device on 192.168.88.xxx/255.255.255.0 should be able to directly communicate with any other 192.168.88.xxx device (assuming they're both on the same physical network, of course).

The "default gateway" (also called "default route") exists solely to tell the device where to send packets NOT destined for its own subnet. In fact, it should work just as well with no gateway set at all (some devices allow the field to be blank, some don't).

The 255.255.0.0 mask SHOULDN'T cause a problem, but should be 255.255.255.0 just to be "proper".

I have seen problems with H.264 streams dropping out when the network gets saturated, caused by simply too much data. If you're pulling JPEG streams from the cameras, that will put a lot more traffic on the network and could cause problems particularly over a wireless link, where bandwidth is limited and can be greatly affected by signal quality. You could try reducing the bitrate of the cameras and see if that helps - I've had to do that on sites that had low-cost 10/100 switches.

JH
John Honovich
Nov 28, 2013
IPVM

Greg, I am really confused by your description. What's wrong currently? You mention a corrupted machine. Is that still an issue? You all say, "corrupted software viewable on IE and not NVR".

MI
Matt Ion
Nov 28, 2013

I get the sense he means the H.264 video stream being recorded was corrupt, while the live JPEG stream viewed in the browser looked fine. This would correspond with a twitchy or overloaded network causing dropped packets and thus dropped I-frames.

Avatar
Greg M. Ray
Dec 04, 2013

Thanks for the input this problem has gone away temporarily and I gathered a lot of information. I have changed all the Network settings as told by GeoVision in which Matt's comments don't apply themselves at all in this scenario. However none of the physical network i.e.: poe switch, radio's, nic card all the physical parts remained the same and now everything is working ok for 10 days...it only use to only run for 4 and start the signal loss.

So I'm told my network was not properly configured. I could have been having conflict between HTP and UTP protocol's and their software shows "signal loss" from that event. I was also told other users that experience "signal loss" setup the network wrong that the third octet was my issue. Any comments to suggest for my benefit ? This is in direct conflict of what your telling me to a point.

I still say since I unplugged the network jumper from the failing machine and put it on my laptop when all this started instantly the connect loss signal went away on the NVR (same software)and ran for 3 hours before I had to leave. It's has to be a software/NVR issue doesn't it ?...besides how reckless of me is it to expect or think having a failing power supply to see a good result with a PC?

CD
Chris Dearing
Dec 05, 2013

Greg, excuse me for interjecting, but Matt's comments were all accurate and reasonable...

He is to be commended for trying to address what direct questions he could find from your original, often incoherent statement, which I might add was also sorely deficient in use of the word 'the' .

Although it didn't help you apparently, i doubt he thought he had really 'nailed it', and was waiting for a clearer picture to emerge.

Nor do i see the 'direct conflict to a point' that you mention, unless for instance you have your setup working now, configured where the third octets are different between nvr and cameras, using only a switch with no router.

Then you are right.

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions