hardwired

This Hikvision PTZ might fit what you're looking for. http://www.hikvision.com/us/Products_1_10561_i19088.html

Is the image of the plate blurred, washed out, or too dark? Those are all different problems, with different solutions; most common is a blurred image from a low shutter speed. If that's the case, (or a washed out image), turn up the minimum shutter speed to 1/250 or so, gain up if adjustable, and see what you get (usually a somewhat dark and grainy image, but readable). Dark is just going to require more illumination.

Try here, instead. http://tech.hikvisionusa.com/2-uncategorised/22-vms-2

I don't think there is anything that works quite the same way for HTTP request (the brute script for HTTP is more about authentication than streaming options). You may have to rely on Wireshark to look at the raw packet information. Keep in mind that even if it is using the same port, it may not be a normal HTTP formatted stream, it could be TFTP or other protocols you need to look into. If you can post a chunk of .pcap file somewhere, we could look at it and see what it's doing (if you are looking at filtered results just by source or destination, you might be missing information, if it's using multicast addresses or other protocols). Make sure you cut out other personal info, though, using Wireshark was how I found out my E-mail login used to go out in plaintext...

One other thing worth mentioning- The URL snooper or Wireshark needs to be running on the same machine as the old software, or you will need to configure a managed switch with a monitor port to allow the network traffic to go to a separate PC, to be able capture the traffic between the camera and viewing software.

There is a way that's worked for me, but it has a learning curve. Using the application NMAP https://nmap.org/ along with a script called rtsp-url-brute https://nmap.org/nsedoc/scripts/rtsp-url-brute.html will check most known RTSP URL's against a selected device (I've used it to discover correct URL's in a number of cases). Using the windows version with the Zenmap GUI makes it a little easier, but it still takes a little google-fu and experimenting to learn. Another way that you may be able to discover a valid URL is to use Wireshark https://www.wireshark.org/ to capture packet data while connecting the camera using the original supplied software. (Also requires a bit of learning, though).

I've had that issue. I don't remember seeing anything in the changelogs about that being issue being fixed at a particular version, does anyone know if it's fixed?

I recently discovered what I find to be a significant problem with Hikvision PTZ's when using motion detection recording (I'm using a DS-2DF8223I-AEL, an otherwise really impressive camera). When actively using the PTZ while tracking a subject, motion detection events are not sent to the VMS, resulting in large gaps in recording while following a subject. I made contact with Hikvision support over this issue, and their response was that this was the correct method of operation. Needless to say, I disagree, and may have to rethink use of their PTZ's in the future. Anyway, this is something to watch out for when using Hikvision PTZ's, as the only option to have recording during PTZ operation is to have continuous recording selected. You may at least want to extend pre/post buffering, if that's an available option in your VMS.

As jeromephone noted above, you'll need a way to get power for the microphone from PoE. I've also ordered from ETS, and found them easy to work with. PoE power interface would be http://www.etsnm.com/interface.html#smea-1 , and they have lots of different microphone styles on the same site.

The distributor ADI is also selling Hikvision, OEM'ed under the "W-Box" line name.

A lot of manufacturers state that they are "ONVIF compatible", etc. However, ONVIF is a standards organization, and they maintain a list of products that have actually been tested, and confirmed to work, here - http://www.onvif.org/ConformantProducts/ProfileProducts.aspx Otherwise, you may be chasing your tail with products that don't actually work the way they should.

To clarify: I made two contacts with Hikvision. The first was with tech support, where a tier 2 tech made the comment that this was expected behavior. The second contact was to my regional rep, who I haven't heard back from yet. I'll update when/if I get more information.

I have sent out some questions to my contact at Hikvision. I don't necessarily think that making this change would be "Easy", but considering the complexity of other features they have added in recent updates (Face detection, etc.), I don't think it would be that difficult, either, if they felt it was worthwhile. Unfortunately, until then, I may not be able to continue using what is otherwise one of the best PTZ's I've ever come across, and that's a shame.

I think the bigger problem is that Hikvision has their own ideas regarding what should be considered a "false" motion event. I would agree with suppressing motion events during jumps between PTZ preset calls, but there is no use case that I can imagine where you wouldn't want to record during manual PTZ operation (and what would be the use of running a tour without recording it? all you would be doing is wearing out the PTZ components...) Let's take my use case for an example. This particular camera is at a community center where the motion activity is under 25% overall, and the manual PTZ operation is probably less than 5% per day. That means if I enable continuous recording on this particular camera, I will be wasting 70% of storage space, simply to catch events during PTZ operation. That seems far more wasteful than recording a small percentage of "False" events.

Oh, I understand the manufacturer position: I don't think it's a well thought out approach, though. I can't imagine a single instance where you wouldn't want recording of an event when you are operating the PTZ. I certainly wouldn't mind the camera outputting motion detection events at any time while either auto-tracking or manual PTZ events are occurring, though. All it would take from the manufacturer side would be a check box to select for not suppressing motion detection events under any circumstances.

If you need to connect more cameras on the same cable, add a network switch at the camera end of the cable, then a gigabit network connection could support dozens of cameras.

The web client might be a decent choice, it does do transcoding on the streams for better frame rates.

I use Ubiquiti equipment (with their proprietary PoE injectors) connected to PoE switches all the time. The switch doesn't see the device connected as PoE capable, so never tries to provide power on the line. Also, the Ubiquiti injector cuts the standard PoE power lines (brown and blue pairs) between the device and switch.

Ok, who's going this year?

The VSPlayer software here will open the files, and gives thumbnails of each clip, but not the full timeline- http://www.hikvision.com/europe/download_more.asp?id=1382 There is a Linux version at that site, as well.

If he really has to have a transfer contact, this might be a better option, just have to check the current draw of his existing maglock- http://www.securitron.com/en/site/securitron/Products/Power-Transfer-Devices/ICPT-Inductive-Coupling-Power-Transfer/

I think he means that he has a man door with a maglock that is in the center of a large sliding barn door. I think the best option for that would be to use a coiled cord to connect it. If the door travels 10 feet, putting it offset so it will travel 5 feet each way will let him use a fairly short cord.

Appears to be the same chassis, at least all of the specs match. Not sure if it would be any better than an Intel NUC, etc, though.

Pretty sure the Genetec is this one- http://www.fit-pc.com/wiki/index.php/Fit-PC_Product_Line:_fit-PC3/3i

Some Dahua DVR's can be used as an encoder, it's possible their HD-SDI DVR could be used in the same way.