Soundy

It's nothing to do with the camera power supply, the cameras simply don't like the load presented by splitting the signal that way. What model DVR and MUX are you using? Most will have a set "daisy-chain" outputs along with the inputs that will load the cameras properly. If not, you may need some sort of proper signal splitter.

Vigil will do the trick - I have one site with 13 IQ-511s, all at full res (1280x1024), though lower framerates. And yes, it can recompress for WAN viewing. They have a very nice client software that will let you view multiple sites within one window (only drawback is, it's Windows only). What resolutions are you actually planning on running these cameras at? The big thing with 22 cams at 15fps will be storage space, if retention time is a concern...

It's unlikely, but possible, if the power supply is marginal and one camera (through manufacturing defect or other cause) is more sensitive than the other to power fluctuations or lower power.

Welcome, from Vancouver, BC!

A light tint/smoke shouldn't adversely affect the image, really. Look at most dome cameras with tinted dome, the light loss on those is usually negligible. Another idea for you for a camera location, BTW... I believe a couple manufacturers make cameras that look like your standard door peephole, if you want something really covert, that may be the way to go (have to be careful with the wiring, but it's not a big deal). There's even a site documenting the use of a typical door peephole as a fisheye lens for a variety of different cameras... with this concept, a board camera could potentially even be mounted to an existing peephole.

GeoVision shouldn't know the difference. Disk failure handling is taken care of entirely by the RAID controller and its subsystem. The array itself just appears to most software as just another drive letter on the system. I'm not quite sure why you'd split the array up into multiple partitions, unless it's to separately control the retention time for groups of cameras (for example, you don't want your high-framerate cameras "stealing" space from the others). I'm not that familiar with GeoVision, but I've done something like this for several Vigil systems on multiple sites for one client. In their main site, I have three 1TB drives in the machine, and 8x1TB drives in a RAID5 array using an Enhance R8IP rack unit. The DVR simply connects to the array via iSCSI, and appears as a drive letter with about 6.5TB available. Vigil handles disks as a "pool" - each additional drive letter is just added to the pool, and the system cycles through them as space is needed. I did have a disk failure in that first array, too... as long as your array supports hot-swapping, you simply pop the disk out, and pop a new one in, all without shutting down the system. The RAID controller should then automatically rebuild the array. And again, your software should never even know the difference.

Fair'nuff

Not necessarily. Some use flash media or optical drives. The question is too vague. What sort of characteristics are you looking for? As the name implies, the record video digitally... that's the only thing ALL of them have in common.

Pot, meet kettle. Like I said, until you provide the video proof to back up your claims, I'm out of the discussion.

Does the laptop have the same malware protection? What are you using? Good luck - keep us posted!

No you didn't. Tell me where in my instructions did I say to use a card like your old hicap, nor did I say to use an adapter with it's own software.... At the top of this page: ak357: "Can i ask u for model number, brand name of your USB adpter please" you: "Yeah let me pull a USB adapter out of my ass. We're not dealing with specialized gear here. It may be a security camera, but its only a camara. Any bnc-usb, and rca-usb, and cat5-usb will do the trick." Again, the GameBridge is not "an adapter with it's own software". It's an S-video/composite/audio-to-USB capture adapter marketed for a specific use. The only "software" that's specific to it are its own drivers, which conform to DirectShow spec, which is what VLC uses to talk to it. This one was funny too: In this case minimizing and "demaximizing" are the same thing...cpt redundant strikes again. Uhh... what? Minimizing - clears the window from the screen, generally removes it to the taskbar, but leaves the program running. Maximizing - enlarges the window to fill the screen. De-maximizing - reduces the window to its previous size and position, as it was before maximizing. Umm... alt-f4 will CLOSE THE PROGRAM. That is NOT minimizing. [much more nonsensical rambling trimmed.... seriously, get back to the brilliance you've shown in some other posts, leave this BS behind] ARE YOU SERIOUS? YOU ARE ARENT YOU? Lets deal with the trivial first - If vlc media player opened up at 740*480, a resolution was specified. It didn't just make that number up. Well, I would assume it got that resolution from the adapter. All I'm saying is *I* did not specify the resolution. The adapter is spitting out the signal it wants to spit out, VLC is grabbing that and displaying it at the resolution it's provided at. The only time I need to tell the media player what resolution to use is if I don't want to use the adapter's native resolution. And even then, the video signal isn't changed, it's just displayed scaled-down. I came to this thread trying to help. You turned this into some sort of test...not me. That's because you made some BS claims that I felt it necessary to dispute. This is what it comes down to: you've stated that any media-player software - using VLC as an example - should be capable of providing at least an approximation of the true TVL output of a CCTV camera, using any readily-available capture device. I maintain that this is simply not possible. Since I'm obviously too stupid to figure out how to make it work, it's back to you to demonstrate it for us. A video camera and screen recorder will make quick work of putting together a little video for the rest of the gang. If you're right, you get the joy of not only making me eat my words, but actually providing a useful resource for the rest of the CCTVFORUM community. So... have at it. (BTW, bet I can predict your next response.... you don't have the time to do this for all us ungrateful louts, if we can't figure out how to do it we don't deserve to be able to do it ourselves, any number of other condescending dismissive statements to get out of having to prove yourself... all boiling down to another cop-out) With that, *I'M* out of this discussion. All your arguing and baiting and insulting do nothing to prove your point, they're just more bafflegab. You can prove your statements 100% with a simple exercise, so do it. Until then...

Hmm, that interesting never ever had problem that NIC affect viewing How ? please explain would more concern about local domain rights,privileges and so on As far as the computers are concerned, it's not "viewing", it's just another kind of network traffic. It's rare, but I have seen glitchy NIC drivers and flaky NIC hardware, and even screwy network cabling, affect only certain network traffic. As an example: at the tech school where I was doing IT support, we had five machines on one wall of one classroom that had no end of very confusing, intermittent problems grabbing an address from the DHCP server. When we hard-coded them with IPs, everything seemed to work fine (no noticeable problems, anyway)... but on DHCP, there would regularly be issues with them renewing their leases. All the cable tests we ran (even borrowed a really pricey Fluke network certifier from the wiring supplier) came up clean. Having exhausted almost every other possibility, I finally looked at a point on the ceiling where the conduit for the network drops on that wall, crossed over a conduit for the lighting. It followed proper design, crossing at right angles, but just to be sure, I removed a couple of clamps from the network conduit and pulled it a couple inches away from the power feed. And with that, the DHCP problems vanished. So in this case, while it's a long-shot, I figure that since the workstations in a corporate environment are often all identical, and the one significant difference between them and the laptop would be the NIC - likely having different chipsets and drivers - it's possible that there's something there that's affecting just very specific network traffic. Again, it's a stretch, but still a possibility if nothing else works... and it's relatively easy to test by slapping a different PCI NIC into one workstation.

Kenzo's on the right track here - if it works fine on the laptop, then the problem likely isn't with the DVR. I assume all these workstations are built to a corporate spec or image, and the laptop is either a different image, or was installed specifically to test this issue? What I'm thinking is, there may be an oddball version of a common system file - a regular, everyday DLL or ActiveX file - that has become part of the standard workstation build you use, that's causing the problem. Perhaps a specific piece of software that's installed on all the machines that replaces some common file with a newer, older, or simply different version that's not getting along with the viewer's ActiveX control. Or it could be an anti-malware application that's on the workstations but not the laptop - ZoneAlarm, Norton 360, some other software firewall.... even a setting on the Windows firewall that's different. Or as Kenzo suggests, an ever-so-minor difference in the security settings between the laptop and the standard workstation build. What you could try, is starting from a clean slate with one of the workstations. Install your basic (Windows only!) build/image and test the DVR connection. Then start adding the usual complement of software used on the workstations - install one app, test the DVR... if it works, install the next app, and test the DVR... and so on until you either get the machine up to the regular workstation spec, or until you break the DVR connection. Dollars to donuts, it's some sort of malware protection that's the root of your problem. The other possibility is a difference in the NIC hardware and/or driver. Chances are very good that all the affected workstations are built on the same or similar hardware (or at least the same NIC chipset - Intel network chipsets are common on desktop boards) with the same drivers, while the laptop probably has a different chipset (Broadcom is a very common one here). It's a stretch, but there's another possibility to look into: if the theory fits, try equipping one of the workstations with an off-brand PCI NIC (specifically, something using a different chipset than the onboard NICs), and see if that clears up the problem. Good luck, and do keep us posted!

Next time I call my rep I will ask. Sweet, thanks... maybe ask if it'll work with an older V60 card too (that's the only spare we've got around here, I think). Whatever happened to our resident VI rep Thomas, anyway?

ajtbone has pretty much nailed it - I find the same thing all the time in fuel services: site blueprints generally have little more than vague locations for the cameras on a plan view, and a rough indication of what they're supposed to view, but there's usually little accounting for the mounting height. Exact position, more often than not, is dictated by other obstacles - HVAC, lighting fixtures, sprinkler pipes and heads, ceiling layout (particularly with T-bar), ceiling supports, etc. With T-bar grid, the locations of the lights and vents are generally fixed, so we have to work around that. The more recent sites we've been doing have open ceilings in the C-stores, right up to the roof's Q-deck, with everything from about 10-12' and up just spray-painted flat black (yay for new designers at Petro Canada... NOT). That limits most of our placements to perimeter walls and bulkheads. On all these sites, it's spec'd that the electricians provide the conduit for us, which in itself can add a whole other challenge (you want me to run *9* cameras through a single 1" EMT? uh... okay... Cat-5-and-balun time... extra cost to the client for THAT little design brilliance). And yes, we always get people wanting things changed - or worse, added - after everything is completed *to the plans*. Fortunately, fuel services (especially inside the stores) don't require the same level of detail as gaming, so most times we can just spec 2.8-12mm lenses and adjust them when the time comes for the coverage they want... more often than not we end up at the wide end of that scale, just giving broad overviews of the product floor.

Just plug your VCR directly into your computer with (almost) any available USB adapter, and align the heads using VLC.

Does VI have a demo of the 4.1 analog server? Last time I looked, 4.x appeared to only be an IP server...

So, are you saying that the adapter translates the information passed to it into a format usuable by your computer, or are you going to try and tell me that the adapter changes the information in some other way, as ak did. I'm saying the adapter has no way of knowing the TVL capabilities of the sensor. That's the standard Windows key combination to close the current window. No kidding. Did you know this before hand or did you find it out by trial while reading the post or by googling it? Not suprisingly it's a combination you'd have to press if the resolution you're trying to view is higher than your desktop resolution...effectively making it very difficult to close the window any other way. I've actually known that since about Windows 3.0 and OS/2 2.0. So no, I didn't have to try it or google it. How is closing the window supposed to help me if it's displaying video at a higher resolution than my desktop? Minimizing it maybe, or de-maximizing it, might help. Closing it won't, unless those keys are given a different function on some specific software. will you be shutting up now...or am I right in expecting even this wont be good enough for you It would, if it worked. It doesn't. You couldn't get it to work, so it doesn't work at all. Good arguement. Well, I followed your instructions to the letter. VLC doesn't do what you claim it does. If you know how to get it to do what you say it should, then either provide better instructions, or better yet, use a screen-recorder utility to make a video showing how it's done (with the TVL display). I thought the idea was to do it using a signal other than the one recorded by the DVR software. You say this should work with any hardware, so why not the DVR capture card? Or does it only work with single-input USB adapters? And BTW... what other signal am I supposed to be using here, if not the one provided by the camera? I want to know the TVL of that camera, is it not required to then use the video coming out of that camera? I do? What additional software would that be? This is not a gaming adapter; this is a USB-connected video-input-and-tuner adapter that's marketed specifically for playing and capturing video games via your PC display. The "game" component of it is a marketing term only. Yet more proof you're talking out your arse - you claim this process is entirely dependent on the software and should work the same with any hardware, but then you tell me all the hardware I'm using is wrong, when you obviously don't even know what the hardware is. What HD signals am I trying it with? This NLC5700 doesn't output HD, it outputs NTSC SD video. And again, I never specified any resolution for it to use. Wow... that's a great cop-out. "Hey, this will work if you follow these instructions"... "Okay, you followed the instructions I gave you and it doesn't work, so obviously YOU screwed up... but hey, I haven't actually used it for a long time... but it's still YOUR fault." Hey, I was just quoting what VLC told me. My bad for not including a screenshot. And BTW, 30fps is only accurate for black-and-white NTSC video. 29.97 is the commonly-accepted approximation for 30fps drop-frame for NTSC color video. No, it's based on your claim that VLC could easily reveal at least an approximation of the TVL resolution of the camera sensor. Umm, sorry... the whole point of the thread was to determine the "actual" TVL resolution of a CCTV camera sensor. You claim it's possible to do , at least approximately, with VLC. So far, you've been unable to prove that theory. THAT is where the waste of time comes in. I followed YOUR step by step instructions in an effort to substantiate YOUR claims. If I do it by my own methods, that doesn't do anything for your claims. Thus, I use YOUR method. The GameBridge requires no specific software. VLC accesses it via its own DirectShow drivers. The burden of proof is still on you to substantiate your own claims. I tried a method you said would work, and then within the same response you dismiss the attempts as me not knowing what I'm doing, stated I'm not using the correct hardware, and then berated me for using YOUR procedure. You've contradicted yourself repeatedly throughout this discourse and seem to be operating by the theory, "If you can't dazzle them with brilliance, baffle them with bull$#!t." Well sorry, I'm neither dazzled nor baffled. You want to be useful? Fire up a screen recorder, load up your VLC, and put a video up on YouTube for us showing exactly how this will work. Until then, it's just smoke and mirrors. Oh, but I forgot, you're done with this thread. So we'll see no proof of your claims, and you can sit back and back in your superiority. Well, enjoy that.

With a powerful enough system, it will handle it. But this is true with any PC-based DVR: there's a lot of throughput and data processing involved with those kinds of framerates, so you need to ensure your hardware is sufficient.

That doesn't preclude the use of a Windows-based (or Linux-based, or any other sort of PC-based) DVR/NVR... it just means you build a dedicated machine for that purpose. We install plenty of Windows-based DVRs that are highly reliable (in fact, 99% of our installs are Windows-based systems)... as long as people aren't using them for web surfing, IM chatting, email, etc. Most Windows instability comes from user-induced faults; prevent the users from f*cking things up, and your DVR will run very happily on a PC.

That depends on the actual capacity of the UPS, and the wattage of the lamp (what wattage is "normal"?). Given those two numbers, you could calculate the time fairly easily. Keep in mind that a UPS is designed to always supply its load when the power is on, and keep supplying it when the power goes out... emergency lights are typically designed to only go on when the power goes off. If you want this sort of functionality, you'd need to rig a relay circuit of some sort. Actually, most of your readily-available emergency lights are 12VDC bulbs that run straight off a 12V lead-acid battery, very similar to the one that's inside your UPS. It's far more efficient, since you're not needing to convert the 12VDC back up to 120VAC, a fairly wasteful process in itself. A standard emergency light is very simple: a charging circuit that consists of a step-down transformer, rectifier, ripple filter and usually some form of current limiting; the battery; the lights; and a relay between the lights and the battery that stays open as long as AC power is supplied. Lose the AC feed, the relay closes, and powers the lights straight off the battery.

That funny That's like that old joke, little Johnny walking around the house banging on a pot with a wooden spoon. His mom stops him and asks him why he's making all the noise, little Johnny says, "Mom, that's to keep the alligators away!" Mom says, "But Johnny, there are no alligators where we live!" "Well you see then, it's working!"

Hmm, I would tend to suspect the camera anyway... quick way to test is to swap the two of them and see if the problem moves with it.

See, there's where your assumptions fall down: the camera isn't connected to the computer. It's connected to the adapter. The software has to communicate with that adapter, not with the camera. That adapter has no way of knowing the TVL of the camera's sensor, it's just reading the NTSC output of it, 525 lines, 30 times per second (substitute appropriate numbers for PAL, if that's what you're using). For that matter, the assumption also trips over the fact that the sensor itself - which is where your relevant TVL number comes from - doesn't connect directly to the adapter or computer, but to the camera's internals, which generate the 525-line NTSC-standard output. That's correct... in my tests, according to your instructions above, it displays a 740x480 pixel window (plus frame, toolbar, etc.), and states the video resolution as 740x480. I didn't tell it what resolution to use; I didn't give it any configuration other than what adapter to use, and what input pin to use on that adapter. That's the standard Windows key combination to close the current window. will you be shutting up now...or am I right in expecting even this wont be good enough for you It would, if it worked. It doesn't. I have?? Where?? What software?? You've never suggested someone look into a software developement kit? ....hmmm http://www.cctvforum.com/viewtopic.php?p=101972&highlight=#101972heres a clueP: That's got nothing to do with this thread. How is this "the point of stupidity"? You claimed true TVL of a camera could be approximately determined using simple software such as VLC, regardless of the intermediate hardware used. I claimed it wasn't possible, you insisted it was, so I asked for the details. What you've provided so far doesn't support your claims, and I still say you're out to lunch. Or would be, if this idea worked, but it doesn't. That's the one thing I agree with.

Well, so far I've found that VLC doesn't view my Vigil ComArt HICAP50B as a "supported device"... so using it on the actual DVR is out. Version 1.0.0-rc3 of VLC on my laptop just locks up when I try to open my Adaptec GameBridge. 0.9.9 just crashes. Version 0.8.6 of VLC sees my GameBridge and shows me the camera video, but information is very limited: View -> Stream and Media Info -> Advanced Information shows me only the Codec (UYVY), the type of stream (video), the capture resolution (740x480), and the frame rate (29.970000). Switching to the Statistics tab, I get the amount of data demuxed, and a stream bitrate that changes with the actual movement in the image. Sorry, but the only relevant data here is actual capture resolution of the capture device, as I stated - nothing that would serve to indicate or even hint at the TVL of the camera itself.