Thomas

Generally you will take one end of the cable and connect it to a BNC in. Now some will have a pigtail connector, some will have hard point connectors. It's going to vary by the DVR. The power lines on the cable would be run to the power supply. Generally we don't flame much here, so feel free to ask what every questions you want.

Get a Y cable for the monitors. Monitor Monitor \ / \ / \ / \ / \ / \ / | | PC

You could also try getting the dongles off of e-bay...probley not enough but you might be able to find a few.

http://news.zdnet.com/2100-1009_22-5499725.html Hopefully the upgrade you applied will be the one to prevent this.

So far it looks like about 39,000 sites have been hit. Nasty little worm, it uses google to find vunerable sites then overwrites the files on them.

Network aware just means thats that DVR can be configured to play nicely on a network. Things like being able to change ports, ip addresses, support for DHCP, ect...just the little things that make it easy to intergrate a system onto a network.

Two cameras max, but I don't think it's a problem.

The only thing to watch for in .Net is that it caches the page and saves the cache to machine and it can make it a bear to upgrade. One thing to keep in mind. The people pushing for I.P. cameras tend to be IT staff. IT staff are more likely to be using a browser that isn't IE.

*coughs* In the US at least you can generally send an sms message just by sending an e-mail to the phonenumber@provider.com

You using the .Net stuff?

Active X is dying. Even MS is starting to acknowage that it's a massive security hole. The FBI, Homeland Security, Cern..How many govermental departments need to recomend against using it for you to see other wise ?

Active X is dying. Weither or not Firefox or Opera or your browser choice becomes the worlds primary browser, ActiveX is dying. It's a massive security hole that is built in to the OS. Building a program around it just means you'll have to rebuild that app later.

The arguement being made is doing it right the first time vs doing it the fastest way/cheapest way. I'd rather see something done right the first time rather then having to put up with poor support. But there can be other compelling reasons to not lean on certain features that are limited to one browser. If you depend on a certain feature there is always the potential that tha feature can be changed at whim. Look at SP2. It locks down ActiveX. This is an excellent thing for the web as a whole, but bad for people who's apps depend on it.

Not really worried about it, he's in a rural area and it's the center of a golf course. But I did some research on price and passed it along. I think he'll blanche at the price.

Which licence are you thinking of? BSD, GPL, MPL?

Customer asked. Under the circumstances I would use an IP camera but running ethernet or coax out there isn't going to happen. (Golf course).

Naw, with open source you have to think differantly. It's not about getting the money up front. It's the steady stream of income you get from supporting it. RedHat makes a nice amount of money, so do the MySQL people. It's the same mode of thinking that the monitoring people use.

Rory have you looked at the PC's that Shuttle builds? They aren't as small as the Cappuccino, but they are pretty tiny. They are ment for music types who want to play MP3s on a system that looks like it belongs with Stero equipment.

We are listening. Now please listen to us. 1. I won't speak to Geovision but I will speak to our product. We are a network based app. We were designed to be a network based app. Multiple units connect to each other, SQL runs to store and transfer info. IIS handles web page (and if you want SMTP and FTP). What more does one need to have a network based app? 2. The example you cite is an NVR system. 3. The tech will be there one day. The question is, how is what an NVR does differant then a well designed DVR? Every proposal I've seen has just been moving it to a black box on a network.

Anything you can do on your NVR is already implimented in DVR software. 1. PTZ protocols are pretty easy to get. With the exception Kalatel, they all have been eager to give out thier protocols. The Bosch auto-track works with any DVR's, just a matter of turning it on. Again, you're citing propritary stuff but so far you haven't managed a single example.

There are a couple of things about IP cameras that still need to be worked out in my mind. 1. Standard API/Port/stream access. Software can capture and record the streams from IP cameras but you're reinventing the wheel. Ideally the camera should be putting out a stream that resembles the RAW format used by high end digital cameras but until a realistic bandwith infratructure is in place that simply isn't feasable. Any IP montioring software is at the mercy of the manufacturers. A single firmware change can lock out someones software. I'm not talking about single manufacturer but all IP cameras. 2. Maintance. IP cameras are like any embeded device, and embeded devices get firmware updates from time to time. Managing that isn't going to be fun. Ideally the monitoring software should be able to push the updates but that's not going to happen anytime soon. 3. Redunancy. I can take an analogue camera and put a T-end on the end of the co-ax and split the signal off to a DVR and a tape back up. In an ideal world, no DVR would ever crash weither it be embeded or not. We don't live in that world. A multi-million dollar location is going to want redunancy. IP cameras don't offer that yet. 4. Networks. In a perfect world a network would never have issues. So far the only corprate network I have never seen get infected is ours and I'm sure it will happen once we add staff beyond a certain point. Network traffic can and is slowly becomming a limiting factor in networks. Access to gigabit systems will help but most of the IP cameras I've seen don't support that speed. Nor do they support IPv6. 5. Staff. I'm a tech guy, I cut my teeth on a C64, learned Unix by logging into the UConn mainframes from home. (The admins were pretty nice to those of us wanting to explore.) I know quite a bit about computers in general, but as many of the people in this forum can confirm, I'm still learning about cameras. Most of the staff that will have to deal with and maintan the IP cameras will be IT staff who aren't dumb people but have no idea what f-stop to use for what. Or how lens size affects field of view. There are a few other points but they are minor and I expect they will be cleared up soon. My main point is that analogue cameras are a mature techonolgy. All of thier warts are well known by now. IP cameras is a tech that is still in it's infancy. I'm sure they will be the future but I see alot more enthusasm for them from tech guys then I do security staff. Honestly I see mixed groupings of analogue systems and digital systems probley being the future for a while, and then it all becoming transparent.

Networks fail. Slammer proved that a network can be taken out with great ease. I don't grasp what you mean by proprietary system. Are you implying that your software is less proprietary by intergreating with other companies software well? Are you implying that all IP cameras interface well?

Rory, your problem is Kaaza. DVR: An input of a read only file should not ever cause a problem with a program. This is a rule of programing. If a read only input takes out your software, you have a bug.

Which we do. The near term future is probley in mixed systems, but it's much more cost effective to use analogue for smaller installs. And big companies have X thousands of dollars of equipment already invested. Most of the mixed solutions are just moving the capture card to the camera rather then the PC.

Geovision gets discussed quite a bit because they have a big chunk of market share. But other companies do come up, and quite a few of the embeded market is mention. And all you stated is IP Camera software. Most of the people here are working in analogue cameras rather then IP Cameras. From what I gather, most of the industry views IP cameras Price/Quaility ratio to not be high enough.