gb5102

I use lots of ZyXEL equipment, good stuff

more info would help if analog camera, then I would use an RF modulator and distribute signal via catv/antenna wiring(can also use diplexer with SAT, but there are some exceptions) or direct composite video feed to each tv

Did you ever figure this out? If the live view in GV software looks ok but the recordings are green then its likely a software issue not hardware.

I've never used a 3rd party fisheye cam, so my suggestions are straight out of the manual. check out section 3.22.2 in the 8.5.8 User Manual http://www.usavisionsys.com/forums/download/file.php?id=698

Can you access Camera Lens setting in Camera Configure menu (hot-key F9)

When you mention 8.5.3, I do remember 1 version that did seem to have extremely sensitive motion detection, it just might have been 8.5.3, it was ~2 years ago so GV version would have been roughly 8.5.3 or 8.5.4 I remember discovering the problem when I was 'qualifying' that particular version, and ended up waiting for the next release on advice of Geovision Taiwan I would upgrade to 8.5.7, I bet it fixes your issue

You said many analog cams are exhibiting this behavior as well as IP, so it would seem to me that the issue is with the GV-NVR software. Excuse what might be a stupid question, but are you SURE the cams are not set up for round-the-clock? Maybe in the schedule or the day-night mode setup? What version of GV software are you running? (8.5.7 has been rock-solid for us) How high is your CPU usage? I have seen some strange issues crop up when the CPU can't keep up, although not this issue specifically. Otherwise, I have never run into this and we use strictly GV-IP cams/GV-NVR, have quite a few out there including hybrid systems, but I admit I have not used the CB120/220's. We have used the CA120/220's without issues. Another thing, there is a lot of improvements in the latest 2.09 IP firmware, although I don't think this is the issue since you said analog cams are also recording constantly.

I have personally had issues with webcam server in both 8.5.6 and 8.5.8. The issue we had with 8.5.6 sounds identical to yours, Geovision Support fixed it manually installing the 8.5.7 webcam server components(before 8.5.7 was officially released). I also recently did some testing with 8.5.8 and found that the 'GV Mobile Server Service' uses 100% cpu time when webcam server is started(tried on both Windows Server 2008 R2 and Windows 8 Pro x64), I have not yet contacted Geovision mainly because v8.5.7 has been solid for us and I am not too concerned with 8.5.8 at the moment... Personally, I would uninstall 8.5.6 and install v8.5.7. (can get it from ezcctv if you don't have a copy) If you still have issues with 8.5.7, try running 'Fast Backup and Restore' and use the 'Restore Defaults' option. If it works after restoring defaults, restart the PC at least once just to make sure it continues to work. Then go ahead and configure any settings you had before. Try to restart again. If it fails after configuring your settings, perhaps there is a conflict with something you have set. At that point I would go back to defaults and set your settings 1 by 1 to determine where the problem lies. If restoring defaults does not work, uninstall the GV software again, then delete or re-name the original GV install folder, usually located on root of drive C:\ unless you specified different during installation. After delete/rename install folder, go in to your 'C:\Windows' directory and delete any remaining Geovision files/folders. Look for names like: geo*, gv*. After deleting these files, go ahead and re-install, ensuring the target folder you specify during installation is EMPTY so it does not retain any previous settings. If none of this works, I would contact Geovision support (support_AT_geovision.com.tw), the Taiwan support is VERY good in my experience.

Motion detection on the cam is used for built-in IO/alerts/local SD card recording features, afaik the GV system always analyzes the video at the NVR, so setting up the on-cam motion detection is not going to save any cpu cycles. For bandwidth: -The new 'region-of-interest' feature in the latest 2.09 firmware allows you to set different quality levels for specific portions of the image. For example, a portion of a scene with 'wasted pixels', such as area above a doorway, or the sky outdoors, could be set to a low quality level to save bandwidth and disk space. -the new firmware seems to have a more efficient H264 codec, noticed ~18mbps decrease at the NVR after upgrading a system with 28 cams(mostly 1.3MP) from 2.01 to 2.09. -GV IP cams are set at 30fps by default, IMO 10-15fps is enough for most general indoor surveillance. Lower FPS will also help CPU usage. For CPU usage: -'GPU decoding' feature(Sandy Bridge or Ivy Bridge CPUs) considerably cuts down CPU usage, but its requirements are very specific- see User's Manual. -NVR setting 'Live View Key Frame Only' saves a lot of CPU time, but be aware this also limits frame rate for Webcam/DMMultiview clients. -Dual-streaming with 'On Demand Display' setting allows the NVR to use the lower resolution sub-stream for live view. Caveat with dual-streaming is it will increase your bandwidth usage if you are currently using only single-stream, but 'On Demand' does save a lot of CPU time.

In the 8.5.7.0 manual under Hardware Specifications it lists the H61 chipset, which does work with the newer pci-express 'B' cards, but it does NOT work with older PCI cards. Their current specs don't seem to consider compatibility with older cards(which I can understand). For new systems there is no problem. However a common scenario for me is for older analog customers which are transitioning to IP, its nice to be able to integrate the old analog card into a new, more powerful NVR. Another is if there's a hardware failure but the capture card is still functional, it saves the customer a lot of money to use the old card in a 'modern' replacement system. For many of my customers, $500-$1000+ for a new capture card is a big expense.(if its only a 4 channel GV600 for example, no big deal, but the GV800/1240/1480, etc can get quite pricey). If it can be re-used vs replaced, why not?

^^^YES^^^ The B75 chipset has built-in PCI so it does not use a bridge chip. Working perfectly for me as well. I have not tried the B85 chipset yet, but I noticed that it does NOT have built-in/native PCI support. Again I have not personally tried this chipset so can't comment on it.

I have seen issues on 2 different systems running v8.5.8(both 'hybrid' analog+IP): -NVR-A = Win8Pro x64 on Gigabyte EP43-UD3L -NVR-B = Server2008-R2 on Asus P8H61-M LE/CSM When you run the 'webcam server', the "gv-mobile-server" service uses 100% cpu time. Tried many different settings, finally 'fixed' by rolling back to v8.5.7 which had been rock solid. I know your CPU usage is low, wanted to mention this because I think there is some issues with v8.5.8. -what AHCI drivers are you using? I have had lockup/BSOD issues with Intel Rapid Storage drivers and certain SSDs, standard MSAHCI drivers are much more stable IMO -Set Windows to never turn off the hard drives (in the past I have seen some SSDs lock up when the OS power mgmt kicks in) -run a hardware stress test(prime95) for at least 8 hours, if it locks up, your problem is hardware: motherboard/power supply/memory/cpu/possibly SSD... -uninstall v8.5.8 and install v8.5.7, maybe it is a GV bug...I have 8.5.7 running on ~10 systems and no issues with it, but the two I upgraded to 8.5.8 both had issue described above...

Had some time to compare with and without gpu decoding- only had 4 cams but it still shows a noticeable difference. GPU Decoding- sandy bridge celeron IGP: 5-15% CPU (10min. avg: 8.79%) PCI-E Radeon HD4350 1GB, IGP disabled: 25-35% CPU (10min. avg: 28.48%) CPU usage measured in full-screen mode with cams set to single-stream, max resolution, H264 codec. Geovision panel size/monitor resolution is 1600x1200, DirectDraw Overlay and De-interlace Render options selected. System Specs: GV-NVR v8.5.4 Celeron G530 2x 4GB DDR3-1066 RAM P8H61-M LE/CSM motherboard Win7 Pro x64- Aero, UAC disabled Cams: BX140DW - 1MP VD122D - 1.3MP VD120D - 1.3MP MFD110 - 1.3MP

I agree- the external cards are definitely much more powerful. Sandy Bridge must have been the easiest starting point, but I think this feature is going to become a requirement as resolutions climb higher and higher so I would imagine they will add support for other GPU platforms in the future. We'll just have to wait and see what the future brings

Its the chipset/CPU. Has to be a Intel HD Graphics GPU/IGP(Integrated Graphics Processor- inside LGA1155 CPU). LGA1155 motherboard must have on-board video output.(some boards do not have video ports- these won't work because the IGP will be disabled) Also be aware that not all Sandy Bridge CPUs have integrated GPU- example the i5-2550k cpu does not- so it would not be useful for GPU Decoding feature. I would be interested to see a side by side as well. I will be putting an analog dvr together in the next week or so, if I get some time before installing GV800B card I will set it up as NVR and do some testing. I will measure CPU first while using Sandy Bridge IGP(Celeron G530), then swap in a HD6450 and disable the Intel IGP.

I don't think they will add support for older chipsets since the new CPU-integrated graphics processors are so much faster, also the new GPUs support OpenCL programing language which I think is what is allowing Geo to tap into the gpu. The bit in the user guide about connecting a monitor to the onboard vga when using an external card is a bit confusing, but the reason is if you install a external vga and do not connect a monitor to the onboard vga it will shut the onboard off, making it unavailable to the Geo software.(can use "dummy monitor"- connect 75-ohm resistors between onboard vga pins: 1-6, 2-7, and 3- There is no setting to enable(unless i'm totally forgetting...). Tried a celeron g530 in a h61 system with (5) 1.3M and (3) 2M cams- in 8ch live view with 1920x1080 monitor and cams set to single-stream h264 max resolution- Geo was using maybe 20% cpu.

Hello Everyone, First post here- found this site about a year ago and it has been a great source of information/opinion on multiple subjects; there is definitely a lot of very knowledgeable people hanging out here and I appreciate your generosity. Brief intro- I am in the USA- Wisconsin to be exact, and I got into CCTV ~6 years ago working for an audio/video company that went under. After they collapsed, I thought that since CCTV and electronics in general are very interesting to me, and I knew that there are a lot of 'hack' companies around here, I thought I could do better on my own. I am mainly a one man operation, but have a couple of reliable people to help me out on bigger jobs. I try to set myself apart from the rest by always doing quality work(even if it means cleaning up someone else's mess) and standing behind it no matter what(within reason of course, some people are just crazy...) and this philosophy has worked out well for me- all my business is word of mouth and I have plenty to keep me busy. Well, on to my question then- As the title states, I somehow lost 13 cameras on a system I was working on today, only 2 survived. I'm not exactly sure what happened, which I why I thought I should post, to see if any of the experts here can help me understand what went wrong.... Basically, I upgraded the old DVR with a new Geovision system, and re-used the existing(6-year old) Altronix ALTV1224DC2 which looked to be in good health(clean, no bulging capacitors etc). I checked the output, and it was running @ ~13.5V. Existing cams were also reused, they were basic el-cheapo 12v black plastic domes(no brand or other markings of any kind), 7 were IR, 6 were non-ir. They definitely fried, you could smell the magic smoke. The 2 that survived were one(the only) existing Honeywell 12v fixed dome, and a new Everfocus dual-voltage IR dome that I installed. The first thing I thought was that I somehow reversed the polarity, but I triple-checked everything and I am sure that was not the case. I initially gave a bit of thought to the voltage output being a bit higher on the altronix, but I never really gave it much thought since everything was running that way for the last 6 years or so, plus there was some longer runs of 18awg so I figured it was to compensate for voltage drop when the IR kicked on. The only change to the power that I can think of is I relocated the altronix(same circuit) and in the process, removed a tangled mess of splices and extensions(~15feet of cat3 cross-connect wire) that were added to the cables coming from the cameras by the last installer. Do you think removing the extensions caused enough of a voltage gain to fry the cameras?(never checked the before and after voltages at the cams) One thing odd that I did notice during my troubleshooting, was that I could feel a bit of voltage 'tingling' if I touched the metal altronix enclosure with the more sensitive skin on the underside of my arm. Like there was some type of 'stray' voltage. Not sure what to think of that. Another thing to note, is that the enclosure was never grounded, it had a 2-prong power cord. So now, I have to try to explain what happened, and of course this is a big customer with lots of properties, so I will likely end up replacing them all on my dime just to keep them happy. Luckily they weren't $500 cameras, but then I'm thinking I would probably not be in this situation if that were the case... So all in all, I'm not quite sure what to think, and its really bothering me not knowing what was the problem....Maybe someone here can help me to understand. Sorry for the long post -GB

If you are looking to export video from a fully operational DVR, your answer should be in the manual(page 33 for single events, page 80 for multiple events.) http://www.specotech.com/DVR/DVR4TL/DVRTLmanual.pdf Sounds like to do the multiple events method, you need to format the external storage device with ext3 filesystem. Depending on your technical level, this can be done relatively easily using a gparted live-cd. If you are looking to recover video from a dead DVR- I've revived a few DVRs just by replacing their external power adapter(match all specs...)- many times the power supplies are low-quality and just burn out or get 'weak' after a few years. If thats not the issue, then- depending on you technical level- I would remove the hard drive and connect it to your pc, then use a driver such as ext2read to allow windows to read the files on the hard drive. http://sourceforge.net/projects/ext2read/ -GB

I regularly use the WD Green drives for the video storage drives on Geovision DVR/NVR with no issues. I always use a Blue or Black drive for the OS though, and I try not to assign more than 8 cams per disk(less with PTZs/MP cams). I think WD's claims for the AV drives are mostly bloated...the only time I've run into problems was when trying to do too much on a single slow(green) disk. For me, they work good for cheap storage but they can't take too much multitasking. Also, on any of the disks assigned for video playback you should disable indexing, System Restore, and automatic defragmentation. If SysRestore writes a shadow copy or auto-defrag runs on its default schedule, these processes will definitely slow your disks to a crawl. Also, don't put your pagefile on any of the disks which are used for video storage. I know I've read alot of people complaining about the Green disks, but using the basic guidelines above i've had satisfactory results using them, I guess YMMV.

As far as I can tell from the manual, you move the cursor down to the 'password' field then hit 'Select' button to bring up an on-screen keypad. Then you use up/down/left/right to select each character of the password... CH1 button is UP CH2 is DOWN CH3 is LEFT CH4 is RIGHT Otherwise try plugging in a PS/2 mouse(might have to reboot dvr)...or call the manufacturer

Like hardwired said, on 12vdc cameras(at least most cheapos) the video shield is generally tied to the negative power wire- creating an attractive secondary path for current to flow. Creates 2 paths to ground- 1 thru power wire, 1 thru video wire=ground loop

Jack- I agree with you 100% on distrust for the switchers- too much that can go wrong. When I need 12vdc I like the MG Electronics DPS-12DC-16UL- uses good ol' transformers and its individually regulated. This is one reason I prefer 24v AC systems- the main power supply is essentially a simple step-down transformer, and although there is a few more parts inside the camera there is less chance of a single component taking out the whole system...plus less worry about voltage drop with higher-powered cams(IR/heaters). At least the cameras that got fried here were the '$25 specials'- client had no problem paying the difference to upgrade them to better 24vac cams.

I forgot to mention that, i did test between the power supply chassis and earth ground, and I ended up with about 55VAC. The current was about 40mA. So yeah i agree, i got really unlucky. Would have expected something like this from the generic no-name 12v supplies that I come across quite frequently. Those are the ones that have scared me up until this point, most are not even UL or FCC approved, but the worst I've seen from the no-names(so far...) is picture quality issues from the noisy output. At least altronix has a lifetime warranty, we'll see how that goes, but I don't think I would trust this model anymore personally...

Sorry for the delayed response, been crazy around here... I'm positive I didn't flip it to 24V, but I'm pretty sure there is something majorly wrong with the electronics in the power supply. Was doing some testing on it, and I noticed that it is putting out a spike sometimes when first powered up. Randomly, maybe every 5-10 times turning it on, my dmm is reading a brief(maybe 500ms) spike of ~100V AC between the '+' and '-' outputs. Also, anytime it is powered on(with no load), there is ~170mA @ ~60VAC between the '-' output and earth ground. So I'm guessing that some component in the switching power supply failed...and the cheap 12v cams went with it. Has anyone else run into a situation like this, or is it just my luck?