gb5102

Just to update my earlier comment- We've been deploying GV-VMS v15 on new systems for about 4 months now and it is definitely much more stable than v14. Have not had any issues that I can attribute to a bug. And just to give Geovision some credit, we do have a few v14 systems out there that started off quite 'rough' but Geovision was able to log into and patch them up and they have been rock solid for close to a year now. (they are v14 but 'patched' to run a few v15 components). If anyone is having issues, email support@geovision.com.tw, the support is VERY good, better than most company's I've dealt with.

Do you have a VMS dongle now? Your previous post stated you had an NVR dongle, they are 2 different things. If you have a 3rd-party license dongle for VMS, you just need to plug in the dongle then install the 'GV-USB Device Driver' from here: http://www.geovision.com.tw/english/5_8_ACC.asp After the driver is installed you may need to reboot in order for it to be recognized by the VMS software

Suggestion: On all of the systems I setup, I remove the permission 'Monitor Stop' from the 'Webcam' permissions for the user account which is used to login to the system remotely. This way you cannot accidentally stop the recording via the remote apps.

^^^^100x THIS!!! OP says the cameras will still turn on with only the +pos power wire connected so it obviously has another path back to ground either via the video line OR via the building itself(OP said it is stucco/metal building) I think you are going to have to electrically isolate the cameras from the building(mount to wood blocks or something) but even then you may very well still have problems if the electrical design of the cams themselves is sh*tty... Also I'm sure the CCA cable is not helping anything but at this point i think it is the least of your worries

I know if you initiate a 'normal' shutdown, it will hang for 15 minutes(Windows default 'hung process' timeout), this has been a problem for quite some time INCLUDING the latest 8.6.2.0 so upgrading will not help you there I always use the command shutdown -r -t 20 from the cli or from within a scheduled task if needed. The -r parameter means 'restart and the -t 20 parameter causes it to 'force' shutdown of all processes after 20 a second wait. BUT is there a reason you can't use the restart feature built into the software? (System Configuration menu > Auto-Reboot Setup)

IMO the latest GV-VMS 14.10.1.0 is beta-quality AT BEST. The interface is great compared to the old GV-NVR and I'm sure in a year or so it will be fine but let me tell you it is not there yet...

The DNS settings in the router do not matter since you have public DNS server(s) configured on the NVR(8.8.8.8 and 8.8.4.4). For gmail settings: SMTP Server: smtp.gmail.com Port: 587 (or 465 for SSL) User Name: your full email address (including @gmail.com) Password: (email password) Receiver (email address to send the alerts to) Sender your full email address (including @gmail.com) Subject: (whatever you want in the subject line...) Encrypt Type: TLS/STARTTLS(if using port 587), or SSL(if using port 465)

It sounds like the main complaint here is related to a defective single cam. You didn't mention anything about rolling bars or other 'normal' ground loop related artifacts, but since all cams are being affected by this, it makes me think ground loop. Most(all?) 12vdc cams internally connect the power ground and video ground(ground loop). I am curious if disabling the cams in the software would have any effect, I don't think it will if my theory is correct and this is an electrical issue. I have definitely inherited a couple of bad installs with horrible ground loop issues where the only way to fix was to isolate the power. This can be done by using individual wall-warts; or by replacing the central 12vdc supply with 24vac supply and either using 24vac-12vdc converters at the cams OR replace cams with dual voltage models. Obviously the individual wall-wart option is cheapest but yes you will have a few outlet strips full of power supplies...and much better picture quality/no more ground loop issues... Keep us posted, I'm interested to hear what you determine.

^I agree. Use isolated power supply(or individual wall-warts...yuck) if using 12vdc cams, or better yet use dual-voltage 12vdc/24vac cams. Dual-volt cams have their power section isolated from video section internally, which also makes them much more resistant to ground loop issues. To be absolutely sure, you will need to go onsite and connect 1 camera at a time and see if the problem appears only when the 'bad' cam is connected, but I would bet that is your issue.

Leaf blower also works great for blowing a bag(with string attached...) thru larger conduit

The answer to your mystery is Address Resolution Protocol http://en.wikipedia.org/wiki/Address_Resolution_Protocol

No idea what you are talking about here... Altronix is my favorite brand for power supplies, this one should work for you: http://www.altronix.com/products/product.php?name=T2428175C With that amount of power you will need some pretty heavy wire to overcome voltage drop depending on the distance. http://www.supercircuits.com/resources/tools/voltage-drop-calculator

^ these I'm thinking your issue is either caused by low-quality cable, or it is miswired. With hi-quality, properly terminated cat5e cable you should have no issues at this distance.

Use your ddns address 'mario.ddns.net' in your mobile app instead of your IP address '78.xxxxxxx'. Thats the main point of having a ddns address is so you don't have to keep track of changing IP address

Geovision DVR/NVR can do this. Pull up a manual and read up on the 'Digital Matrix' feature

You could physically install a Geovision card in the chassis and install the Windows drivers for it, but the Pelco DVR software would not recognize a Geovision card. You MAY be able to remove the Pelco software and install the Geovision DVR software but I would say at that point you would be much better off just building or buying a brand-new DVR(s). So in simplest terms: don't do it.

Are you using Task Manager to monitor CPU usage? If so, this is a bug, not sure if its a Windows issue or a GV issue(or a combination...) but I've noticed after installing GV on Win8 that the Task Manager will read constant 100%. If you check with a different utility such as Windows' perfmon or 3rd party tool CoreTemp you will see the CPU is not actually maxed. Here is a pic from a DVR showing the difference between what Task Manager reports and what Perfmon reports:

CPU usage is read via Windows Task Manager or Perfmon. I really like ZyXEL switches(and firewalls)- they are relatively cheap, well-built and have proven to be reliable. This is a favorite for smaller installs: http://www.newegg.com/Product/Product.aspx?Item=N82E16833181164 A 10/100 PoE switch would likely be fine(and save a few bucks) for 8 cams depending on the frame-rate you plan on running. At full 30fps you'd be at about 10mbps per cam which would be pushing it on a 100mb switch, but if you drop down to 15fps you will be at ~5mbps per cam in which case 10/100 would be fine... http://www.geovision.com.tw/english/Bandwidth.asp Managed switches are nice for troubleshooting purposes and required if you need the capability to run VLANs or remotely power-cycle cams, probably not needed on a small/home install

I really don't think you will have an issue running 8 cams on an i3, but as stated by jazzar - "better to have MORE instead of LESS" With IP cams, recording actually has the LEAST impact on CPU since the camera is doing all the 'work' encoding the stream, the NVR just has to write the already-encoded stream to disc. However, motion detection and other 'video analytics' DOES require some CPU power at the NVR. The biggest loads are: -DEcoding to display the cameras on the NVR's local monitor, which is where the Intel GPU's H.264 decoding feature makes a big difference -REencoding the video to a different size/format/codec to send out to remote-view clients On the 26-cam system with an i3 mentioned in my last post, the CPU is able to keep up no problem UNTIL you get remote user(s) logged into MultiView, then it spikes to 100% and start to drop frames.(the recorded video is OK, but the remote viewing gets very 'laggy')

I highly recommend using the CPU-integrated graphics. Geovision system supports GPU-Decoding feature which will use the h.264 decoding capabilities of the Intel cpu-integrated GPU to decode the video streams. This will actually result in MUCH LOWER CPU usage compared to using dedicated graphics card which DOES NOT support accelerated h.264 decoding. Details are in the Geovision Technical manual, also see below thread where I posted some side-by-side test results: viewtopic.php?f=36&t=31552 EDIT: forgot to mention, a dual-core i3 will have plenty of power for [8] 1mp cams. I currently maintain a GV-NVR with an i3-2100 which expanded far beyond what was originally anticipated, it's running a mix of [26] 1mp and 2mp cams. CPU is a constant ~65% but spikes up to 100% when there is a few LAN users logged into Multicam. Its handling it OK but I will be upgrading it to an i7-3770S at some point in the next few months.

GV-AView requires port 4550(command port) even though it is not documented in the manual... Also, did you change the HTTP port in the GV-DVR software or ar you just using port forwarding to 'translate' the port? (for example: external port 1080 translated to internal port 80) You need to change the port on the DVR so the software is 'aware' of the alternate port

Both of the ones you linked to have a power brick. I can say the ES1100-8P recommended by buellwinkle is a solid switch, I've used a bunch of them. A benefit of 100mb switches is the ethernet ports seem to be 'tougher' when it comes to withstanding power surges/esd when compared to gigabit switches. I've lost a quite few gigabit ports after storms over the years, never had a problem with a 100mb switch though.

CCA is garbage. Very brittle as you have found and MUCH higher resistance than standards-compliant solid-copper cat5...I've ripped out and replaced probably miles of that crap installed by others.

Most hi-quality cams will have a menu option or dip-switch to disable the IR LEDs. Otherwise, you can probably just unplug the power connector on the IR board. covering the LEDs may cause internal reflections/heat buildup

Avoid using Copper-Clad Aluminum(CCA) cable, it is garbage