Soundy

I see you've been asking about this on the Ubuntu forums as well Been a long time since I actually looked into the transaction details of an FTP transfer, but I'm wondering if the server is requesting some kind of system-type identifier from the DVR, and not getting a response? Here's a thought: log in from your working client and then check the logfiles to see what entries are created for it... then do the same with the DVR and check the entries for that. Knowing at what point in the handshake the DVR kacks while the PC login is successful might help determine what's missing or incorrect. Post the log results here if you want, and I'll see if I can make sense of them (urgh, gonna hafta browse those ancient RFDs again!) I'm not at home, or I'd check how various clients work connecting to my own FTP server, and what log entries they generate...

What make and model of camera is this? Most IP cameras are also megapixel... if this one isn't, then you're looking at going to megapixel to improve your resolution, and in today's market, that means IP. Analog cameras are limited to 525 lines of resolution by NTSC video spec (more if you're in a location that uses PAL). Analog capture devices (DVR cards and the like) are generally limited to a max of 640x480 up to 720x480, depending on the exact design. Vigil and Video Insight are two PC-based DVRs that will do all this. Both also handle IP cameras. Those are questions only you can answer, as it will depend on the specific installation and its requirements. Ahh, now that's a question sure to start a holy war. CMOS or CCD? Canon or Nikon? Mac or PC? Ford or GM? Each has their benefits and drawbacks, and again, each will depend on the specific needs of the installation, but in general, either will do you just fine. Yes... see this thread: http://www.cctvforum.com/viewtopic.php?t=16507&highlight= Yes - look up "siamese cable". Another option is to use twisted-pair cable (Cat5, Cat6, even Cat3 or two-pair station wire) along with video baluns, allowing you to send video over one pair, power over two more pairs (doubled-up to reduce losses), and a pair free for PTZ, a second video feed, or whatever you may find a use for. There are loads of wireless options for both analog and IP. WiFi megapixel IP cameras are certainly available too. What works best will, yet again, depend on the circumstances of the specific installation, balancing cost vs. distance and reliability. That's a great big "it depends". There's a PTZ control spec called "Coaxitron" that feeds the signal over the coax. However, it requires that the DVR/controller and camera both support it, or it needs separate encoder/decoder boxes at each end. If, as noted above, you use four-pair UTP cable (Cat-3/5/6) for video and power, you'll have a pair left over that you can use for serial control. But then, if you require megapixel resolution, that means IP cameras, in which case the control signal is just carried over the network along with the video.

SDI itself has been around for a long time - we had broadcast tape decks with SDI at the tech school I worked at some 10 years ago. The problem with this concept, unless the spec is extended, is that it's still limited to 1080p video; at standard 16:9 format, that gives you 1920x1080 resolution, or just a hair over 2MP. That's your MAX resolution with current HDTV spec. 2MP is pretty minimal for megapixel IP cameras, 3-5MP cameras are already common, and the theoretical limit is far beyond that... meaning "HDTV"-based CCTV cameras are obsolete before they're out the door. Yes, they can use existing coax... but so can IP cameras, with the use of HiWire adapters. The adapters themselves are a little pricey, but they ARE readily available. Add that, as new technology, SDI cameras and DVR cards will have a ways to go before their prices can benefit from the economy of scale... by the time they're ready for mainstream, at the rate IP camera technology is improving and the cost dropping, IP will have left them far in the dust.

I wouldn't think standard wireless would be sufficiently reliable for this. It's not clear, do the booths already have LAN connectivity to the central office? If not, do they have phones? Would DSL be an option in that case?

Hmmm, I already replied to this one... looks like the board has swallowed a post again. So why RAID? Well... how do you fit 20 3.5" drives into a machine, let alone connect all of them? Or are you using externals (eSATA, USB or Firewire)? Externals are going to take up a lot of desk/shelf space, nevermind the powerbars needed to plug in all their power supplies... plus power supplies for USB hubs, if applicable. Sure it could work, but it's a pretty bulky, inelegant solution. Rather then risking ANY data, RAID 5 or 6 allow you to simply swap out a failed drive (assuming they're in a hot-swap enclosure), and the system will automatically rebuild the array - no need to take anything offline, no need for downtime on any cameras. But as with the "VPN-vs-port-forwarding" thread, a lot will depend on the individual situation and the needs of the client.

Yup, your problem is definitely caused by splitting the signal. It may also be complicated by iffy BNC connections or cheap/dirty T-cons causing additional signal loss. I haven't actually seen any cameras that let you change the output level or at least, have never had the need to look for the capability), but it's something you could look into. Double-check that none of your connectors are dirty, and possibly re-terminate the coax runs.

The OP's question was, "I need to know if there is any CCTV testing device that can measure the resolution or TVL of the camera, due to some exageration from some suppliers about their cameras' resolution and picture quality. " This arises from the fact that cheaper cameras' sensors have a lower resolution than is claimed by their vendors. You claimed this information can be obtained by viewing the camera via VLC. I state unequivocally that it cannot. VLC will show you the digitizing resolution of your capture device. It won't even tell you the TVL output of the camera itself (which, BTW, is *always* 525 lines for NTSC color, per NTSC spec), let alone the physical resolution of the sensor. Whether the sensor is 520TVL or 280TVL, the camera will still output 525 lines, and the capture device will still digitize that signal at its intended resolution. Until you're prepared to PROVE otherwise, with a video rather than nonsensical rambling, the debate is over.

I don't know about AverMedia specifically, but in my experience, it will depend on the POS system to a large degree. I've run into some that don't have serial output, which precludes the standard method of capturing text data from a serial port, and most I've seen use some minor variations on ASCII formatting codes that may confuse some DVRs or TVS inserters. All the Squirrel POS systems I've dealt with do have an option to output for a "pole display", which makes a more "generic" ASCII output that's worked well with most systems I've tried it on.

Are they all the same make/model camera? Where are the T-connectors (at the DVR or the MUX)? If you run the camera through the T, but don't connect the T to device, do those cameras still work fine?

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.