RickyGee

BTW - I also tried the reset button, which is supposed to reset the camera to factory default settings and it must not be working either, since it is not resetting the IP address of the camera to the factory default of 192.168.1.108. It still pings at it's assigned address which was changed to 192.168.1.11

Got a new firmware file from the supplier and it bricked my HFW3300C camera. Did the update because I could no longer get a video picture through the web interface for aiming/focusing. The camera still pings at its assigned IP address, but I cannot login to upload the original .bin file. Tried all the login options, and port 3800, no joy. Config tool can't find the camera automatically, even though it pings. Any trick to get the camera to take a new upload, or to login? Thanks guys.

No joy...tried the ONVIF manager, and it can't see the camera either. The camera still pings at the previously assigned IP, the IR radiators are on, so it's not totally dead. But the port scanner is now not detecting ANY ports open. Anyone have a link to a good procedure to follow for serial access via terminal? Or is that wishful thinking on my part....?

Thanks for the tips. Neither PSS nor SmartPSS could find the camera on the network, yet the camera will ping properly at its IP address. I now have no open ports reporting from the camera, so using port 3800 for the upgrade doesn't work either. I'll check out the other tools you suggested, and thanks again. For all the hours I've spent already on this camera I probably could have bought a new one.... but I want to learn how to fix my mistake, if I made one. With all the people complaining about firmware upgrades on Dahua products, I might need to fix others in the future.

BTW, I've read the tips and tricks for unbricking a Dahua camera and found it very helpful and informative, but the procedures offered don't work in my case. The port scanner showed only port 23 still open, and I tried logging in, or upgrading using that port address, and now port 23 wont show up on the scanner....sigh...heading backwards. I may be toast, since using some of the other tools is probably beyond my capability. I can still ping, though, so I haven't lost all hope yet.

Perhaps in my virginal blissful ignorance and trial and error school of hard knocks, I inadvertently and unknowingly set up a series of configurations between the cameras, the NVRs and the PSS that made this work....? I'm grateful either way, because without it, the project was toast. "...life is soooo complicated." The Kinks - 1971

First, thanks to all who guided me (a virgin) in my design for an IP camera system for my friend (see “more than 4 cameras on Dahua NVR” for description). The system ended up with 11 cameras and 3 NVRs in 3 zones connected by wireless bridges using Engenious ENH202. The first zone is his store/restaurant with cameras inside and outside, the second zone is a remote parking area and the third zone is his office separate from the other zones. I had many issues getting everything to work well together, but thanks to all the help, I came up with solutions for every problem and the system is up and running and it’s REALLY COOL! Everything is recording at 1.2-2MP and 30fps continuous and VBR with highest quality setting and 8.2Mbps, only an occasional frame drop. Total equipment cost for EVERYTHING was $6k. I wanted to post this because I accidently discovered something amazing and I wanted to share it with the forum; Buellwinkle you’ll love this. After a suggestion from Buellwinkle and a bunch of research, I selected the Engenious ENH202 800mw bridge devices but was warned that I needed “line-of-sight; even a tree branch will disrupt the bridge”. So I was VERY careful to locate the ENH202s where I would have direct line-of-sight; one on the back side of the restaurant and the other on the outside wall of the office. Everything worked great…then the HVAC guys showed up and added a unit and a duct right in front of the antenna, with foil facing just inches from the ENH202!!! I thought it might have burned out the unit with that much energy reflecting back into the unit…so I logged onto the system from my laptop to check the damage and…IT STILL WORKED!!!! Right through the friggin foil faced duct! So, hat’s off to Engenious. I can definitely recommend the units for anyone needing remote access to their camera(s). But be advised that they are layer 2.5 devices by default and must be set up for transparent layer 2 only (WDS Bridge, both xmtr and rcvr). IP cameras and VOIP won’t work over normal client bridge setup. Engenious has a technical paper on the subject that explains why, but setting up the units as WDS Bridge (with MAC tables) works. I did move the antenna to the other side of the new duct. Now my buddy is talking about expanding the system to several other remote areas. He’s gonna owe me a lot of steak dinners…. -Rick

One thing I noted; the toggle from substream low res in the multipane view to single pane main stream HD and 30fps only works if you double click the image to toggle back and forth (PSS). If you use any other method (like the pane view icons at the bottom of the screen) it will not automatically go to HD or back to low res. You will instead simply blow up the sub stream image, or reduce the main stream back into the multipane view. It drove my buddy crazy until I showed him. He kept using the icons and would have several small main stream images loaded in the multipane view bogging his CPU.

Quote - "I've yet to see this feature work on my dahua NVR with built in POE. It follows main stream settings only and does not change with motion detection. Not sure if it's an nvr problem or the cameras problem. Using all dahua 2mp mini domes and one 2mp auto focus dome with audio." **************** I had to drop using the Dahua internal POE because I could not disable the fact that the NVR would override my static IP addresses I assigned the cameras and reassign class 1 IPs to all the connected cameras. I finally bought an 8 port ZyXel PoE switch and used just the LAN port on the NVR and then everything fell into place. I could load the individual cameras as well as the NVR in the PSS "Device List". Then highlight the pane you want the camera image displayed in and right-click on the camera name in the device list. A pop-up window will give the option to load the primary or seconday stream. I set up my secondary streams by direct access to the cameras via the Webservice to D1, 5fps and highest quality setting. I'm using PSS 4.06.06 Edit - I just reread your comment and may have misunderstood. If so please forgive me wasting your time.

I've yet to see this feature work on my dahua NVR with built in POE. It follows main stream settings only and does not change with motion detection. Not sure if it's an nvr problem or the cameras problem. Using all dahua 2mp mini domes and one 2mp auto focus dome with audio. I see this can be done in NVR web interface, logging on with WAN correct? We only use the remote LAN access to the cameras and NVRs as we have no monitor connected directly to the NVRs in the finished installation. LAN only, no WAN no Internet. Loading a low res second stream into the multipane view within PSS on the remote PC allowed viewing all the cameras at once without saturating the CPU, yet HD 30fps when you doubleclick an image to bring it to full view (or whatever your primary stream setting is...). PSS will remember your configuration settings when you log off, if you select that option. I did not notice this same feature if you access the NVR via Webservice tool, but I wasn't looking so it might be there.

All excellent points and true. Every one of them had to have a solution in our design. I used multiple 3204 NVRs so that I could record all cameras at 2MP resolution and 30fps and 8.2Mbps. The NVRs have single 2TB drives that provide about 4 days recording and the spec called for 3 days so that was met. The CPU usage on the remote computer running PSS was the killer and almost killed the project until I discovered that I could load second stream thumbnails at D1 and 5fps into the multipanel view and then doubleclick an image to change to single panel HD and 30fps, and back. Just 2 camera images displaying at 1080p and 30fps saturated the CPU on both laptops and nearly so on the desktop. That feature saved this project. We can display and watch all 11 cameras at once and only use 50% CPU on some pretty wimpy PCs, until the need arises to focus on one image and blow it up. So, the equipment I chose is recording all cameras in HD and 30fps, highest quality setting with only an occasional frame drop, and that's acceptable. But one limitation we had to accept is that we can play back only one HD track at a time on the PCs due to the CPU limitation; 2 tracks really bogs the desktop down and the laptops gag on the load. Remember, we are accessing the system via the camera net and not direct connection to the NVRs. For anyone designing an IP camera system, your points are vital to consider. Fast action needs high frame rates, even if the cameras don't move. The game changed a year ago and now we have the DISH Hopper, the DirectTV Genie and inexpensive NVRs that will record multiple HD programs simultaneously and you can play them back on your 60" HDTV. Or you could just record your favorite shows on your VCR and play back the tape on your 13" crt TV. They're the same shows, right?..... Who needs 30fps? Jurys do. They've all got HDTV at home...

Reminds me of the sign "Slow children playing"...I suppose if you are only capturing slow children 15fps or 7.5 is fine. Seriously, we are experimenting with 15fps on a couple of the cameras to see if it will be acceptable and we can gain some recording time. 30fps simply gives more images from which to capture a face, or see what someone is doing with their hands. If the equipment will do it, why not?

Certainly an option for some applications. I chose the Moen 18" Stainless Steel bars because they will never rust, can't be bumped out of alignment, came with SS hardware and only cost $20 incl shipping. I also thought they made a clean appearing installation. 12" would work as well and might be even cheaper. Neither would work on an angled mount like a roof but I only have wall mount locations. So how about if I told you they were Industrial antenna mounts, built to commercial standards to withstand F5 tornadoes and Cat5 hurricanes and winds in excess of 300mph, made of solid Stainless Steel, will never rust, corrode or need paint, will last forever and come with a lifetime guarantee, and I paid $200 apiece for them? Still look like a bathroom?

Thanks, Dex. From your comment, it looks like I have the cameras set for normal recording with motion detection activated. I'm honestly not sure if I did that directly in the camera (Webservice) or through the NVR firmware or perhaps a combination of both, since I played with both extensively. But I know I didn't set it up through the PSS since it was already working like I wanted once I got the PSS installed and accessed the NVRs over the net. We don't have a monitor connected directly to the NVR in the final installation configuration.

You have to be careful with that one though because it can break up recordings and make critical seconds of an incident lost. Motion files break up continuous files on playback and even though it's mostly seamless, it can lose a second or two and that can make all the difference in a critical situation. With the dahua I installed for a daycare center, I have found that continuous/motion scheduling is best set for off hours when no one could easily pinpoint the time when something wrong happened. That makes it easy to find specific events the next day if needed. And even then, it's best to support that camera with another one just set to continuous, for full file continuity. But any time people are around to be able to report an approximate time an incident occurred, such as during normal business hours, it's best to keep motion detection out of the equation and just stick with continuous recording. It not only helps for complete and easy continuity for the file backup for authorities, but it can help prevent a precious second or two lost between continuous and motion file continuity. That's something I thankfully learned not from anything critical, but just by observing playback behavior. Food for thought when setting those schedules. Thanks. I'll need to play more with the recordings. Since I have the NVRs set to record all cameras 7x24x365 continuous, I didn't see any anomalies in the recorded video as it transitioned from a section with no "motion" to a section where the MD was triggered and the track changed color (continuous is green and MD is orange). The only change I could detect was the actual pixel changes in the image and the color of the track; the recording was continuous and smooth otherwise, even when it transitioned back to just continuous as reflected by the color of the track. But I honestly only played with that setting for an hour or so, so thanks again for the tip and I'll go back and make sure the MD settings are not interferring with the continuous record.

Here's a pic from the parking area with the other bridge antenna.

Probably a HUGE one, but it still worked! I logged in from my laptop through the Buffalo Airstation in the office and could watch all 11 cameras in real time, and view any single camera from the restaurant in 2MP 30fps. I did move the antenna to the other side of the duct after the HVAC guy finished so that he wouldn't mess up my wiring job again...

How many cameras on each NVR? Do you mean 8.2kbps for the bit stream? The Dahua 3216 NVR maxes out at 32000kbps with the bit rate, so if you had more than 4 cameras on one NVR, you shouldn't have been able to set them at 8.2. Are you running PSS on a server or just recording onto each NVR? Otherwise, congrats on your wireless bridge. I'm using 3204s with 4 on two of them and 3 on the other. Using just the network jack and POE switches, they are all networked together and I can use the Webservice tool provided by Dahua to access each camera and NVR individually for adjustment. I'm using Dahua PSS on the office desktop, my laptop and an additional old XP laptop for normal access and use. By setting up the second stream from every camera to D1 and 5fps, I can load thumbnails for all 11 cameras using the second stream. When you double click on the thumbnail, it expands to single view, 2MP 30fps. Doubleclicking again will return to low res thumbnail. Neat feature which saved this project. The NVR3204 also maxes out at 32Mbps. Recording on the 2TB HD in each 4 channel NVR only, with 2TB NAS for backup in the office. The PSS makes it all seamless.

Yeah, I did move the antenna to the other side of the new duct. The sloppy wire was from the HVAC guys moving it, not my work. I didn't check how much signal loss occured from the duct. I was simply amazed that it worked at all with the foil faced duct completely blocking the view! The antenna mounts are Moen Stainless Steel 18" grab bars; cheap, strong and permanent. 8.2mbps. I'm using 4 channel Dahua NVRs networked together with POE switches and 2TB HDs which gives about 4 days of continuous recording. Another neat feature of the Dahua NVR that is not in the manual is that if you record continuously, but also set up MD, you get markers on the tracks when the camera senses motion which can help in finding "interesting" records.

This project is described in the thread “more than 4 cameras on Dahua NVR” below. All the equipment has arrived and I have it set up on my kitchen table while I configure everything. The cameras connected easily to the NVR and the internal firmware drives the locally connected 20” CRT computer monitor, providing nice images but limited control of the cameras. The included mouse and remote work well. The NVRs came with a CD loaded with a ConfigTool, PSS software, user guides and other utilities. Almost none of the included software works… After several days of screwing with it, I finally got the WEBREC.cab plugin installed in IE and was able to open the WEBSERVICE through the ConfigTool. When I add more than one camera image into the GUI, the processor goes to 100% and stays there, even though I can add all 4 cameras. The same happens with the PSS software (V4.06 and V4.06.6) but I had to add Rory’s DPIfix patch to get the PSS to work. Thanks, Rory. Here’s the test setup: 4ea Dahua HF3300 cameras recording at 1080P, 30fps, 8192Mbps VBR to a Dahua NVR3204V-P with 2TB 7200rpm Seagate HDD. The NVR records and displays these cameras on the local monitor just fine with about ½ second latency. My laptop is an HP Pavilion D7 Entertainment PC with 2.2Ghz dual core 64bit processor and 4GB RAM. I’m running Win7 64bit and IE9 64bit with a 17” local display at 1440x900 resolution. It plays Blu-Ray HD movies through its HDMI port to my 56” TV without breathing hard. It has an ATI Radeon HD 3200 graphics card with shared memory. Memory usage never gets past 46%. Has anyone else experienced this CPU saturation with network access? Is the Dahua software incompatible with 64bit systems? I would think that the laptop display through the network connection should equal the local display on the attached monitor. Is that unrealistic? Thanks. -Rick

Thanks, Dex for correcting my mistake. You are right. I tested my system as well and the load on the CPU seems split almost equally between the 2 cores with only about a 10% difference and near symetry, so it must be multithreading. That is good news.

THE SOLUTION: In thanks to this community and to all who helped me figure this out, I want to end this thread with the solution so that others who may find their way here might be helped. It turns out that the root of all my difficulties was the built-in POE switch in the 3204V-P NVR. Despite many hours and all my attempts, the NVR would automatically assign Class One IPs (10.1.1.x) to the cameras attached, even though I had assigned static IPs in the Class Three (192.168.x.x) range to the cameras and turned off DHCP on both the cameras and the recorder. That made accessing the cameras directly after they were connected impossible. All attempts to assign a Class Three IP in the switch configuration tool (under the Advanced Network settings directly in the NVR firmware) were rejected, even though the manual shows an example with a Class Three address in the figure. Deselecting the conf_net.cfg_switch feature also would not take. When the NVR was restarted, the feature was turned back on automatically. So, I shut off, deselected or disabled nearly every advanced network setting in the NVR via the internal firmware (attached monitor and mouse). I then used the ConfigTool (fixed by the explanation above) to individually assign static Class Three IPs to the cameras per my system design. Then I connected all 4 cameras and the NVR to the ports on the Zyxel POE switch, using only the network port on the NVR. I also assigned a static IP in the same range to my laptop LAN port adaptor, leaving the WiFi port adaptor set for DHCP to connect to my router and the Internet, and connected the laptop via the LAN port to the switch. At this point, everything became easy; after connecting everything I could still directly access each camera and the NVR individually via the ConfigTool, the WEBSERVICE GUI, and could find and load them into the NVR firmware and the PSS software, all from the laptop. After loading and testing the cameras individually into the PSS, I realized that by right clicking on the camera ID in the device block, a pop up menu (not in the manual…) would give the option of loading the extra stream rather than the main stream (not an option in the WEBSERVICE GUI). So I went into all the cameras and set the extra stream to D1, max quality (6) and max bitrate (768) and 5 fps. Back in the PSS, I could now load all 4 cameras extra stream into the 4x4 view and the CPU is running at only 25%. By double clicking any one image it goes to single view and automatically changes to the main stream (1080P, 8192kbps, max quality (6) and 30fps) for full resolution view and the CPU goes to about 80%. Double clicking the single view returns the screen to multipane D1 and the CPU goes back to 25%. The D1 resolution is perfectly fine for viewing 4x4 thumbnails and is visually indistinguishable from the main stream unless you zoom the image within the 4x4 view. Meanwhile, the NVR is recording all 4 channels continuously at 1080p, 30fps and displaying them on the attached monitor, with about a 1 to 1-1/2 second latency (I don’t have PTZ so the latency is not an issue). So, I am happy I have a solution I can work with. I will need to acquire another Zyxel POE switch for the other zone and will avoid using Dahua NVRs with built-in POE switches for future builds. I am very happy with the NVR otherwise.

Whether the AMD 8 core and Intel i7 chips give as much extra as their benchmarks imply depends on whether the software can use all 8 cores or 8 threads, respectively. The AMD chips blow away the Intel chips on a synthetic benchmark/dollar basis, but if you check the real-life benchmarks, comparing things like games, office apps, video encoding, etc, there's a huge dependence on whether the software uses all the cores. Single to 4 thread tasks tend to favor Intel's more efficient architecture. The other issue some people worry about is power usage, as you mentioned, which is related to CPU usage. AMD chips typically have a higher total power design (roughly 30% higher in the current high-end chips, I think), so if the systems run at the same CPU %, the AMD chip will consume more power. If the AMD chip runs less CPU % for the same camera setup, the total system may use less power, even though the AMD chip has a higher max power usage. Yeah, it looks like the Dahua Firmware/Software does not use muti threading and runs in just a single core, despite the multiple cores available, either physical or virtual. I've always used Intel chips until this laptop, my first, came along. My last desktop build (10 yrs ago) had a crack baby hybrid Gigabyte MB that died (my only, ever, MB failure...) and I was looking at a full out new build with peripherals, or this laptop which turned out to be a good deal and pretty versatile.

It appears that the Dahua firmware and software does not utilize hyperthreading and is running in only a single core. That would explain the requirement for a 32bit architechture for it to run. It would also explain why my dual core processor is saturated so easily; rather than use the graphics card, the software is using 1/2 of my CPU to do all the decoding and rendering. It is incapable of using multicore processors. While I'm amazed at this poor software engineering approach taken by Dahua, it is what it is, and I'm stuck with it. But your comment about the Intel chip having HD4000 video built in caught my attention. Did you mean that the Intel motherboard has the video built in, or is the i7-3770 built to handle this single core video load by itself? I have an old desktop I built with as ASUS P4C 32 bit motherboard and a P5 3.2Ghz single core CPU that I retired years ago that I'm thinking may run this dahua stuff better that the new gear. Edit: My comments here are totally wrong. See the posts below. I owe an apology to the Dahua software engineers for this error. They have much work to do to improve their product in other areas (like the Dpi fix), but they do utilize multi-core technology. And the fact that they included an automatic toggle between extra stream and main (without mentioning it...) is actually really cool, and saved this project.

FINALLY!! I have one problem resolved. The Dahua ConfigTool stopped working and wouldn’t display any video with a camera directly connected (via POE switch) to the laptop. It also crashed and hung with a webrec.ocx failure APPCRASH notice. After much fussing, I got a clean install of IE9 V9.0.8112.16421 native 32bit browser. Then I had to install not one, not two, not three, but FOUR activeX controls. SurveillanceCtrl was installed into the Webrec/Single folder and DHsurveillanceCtrl, RealVideoCtrl, and PlayBackCtrl were installed into the Webrec/Torch folder. Then, even though I am the only user on this PC and have admin rights to everything, I had to open the browser by right clicking and choosing “Run as administrator”. After jumping through all these hoops, the ConfigTool is working perfectly and I can see and adjust the camera settings, and aim the thing during install. Now I need to figure out why the Veracity Pinpoint adaptor I bought so that I could use by laptop to aim and adjust the cameras at install isn’t working… It would be nice if at least ONE thing would work right out of the box… it appears the Pinpoint adopts a crossover technique and I’ll have to make a crossover patch cable to undue that, in order for it to work. Now, on to the network setup. Thanks to everyone for the good discussion, the helpful tips and information. Hopefully this thread will help others. -Rick Update - I had to install yet another, #5, ActiveX control ComDlg into the Webrec/Torch folder. I'm glad this system will never be connected to the internet. That's a lot of hacker vulnerability. Also, the Veracity Pinpoint required a crossover patch cable, to reverse the built-in crossover. So now that's working.... Now I have to find a fix for the fact that the IP setting I set the camera to (and deselect DHCP) is overridden by the NVR once I hook it up to the NVR. I assigned a class 3 IP (192.168.1.xx) but the NVR automatically overrides this setting and assigns a class 1 IP (10.1.1.xx). It does not appear to be any way to turn off the DHCP function in the NVR, as I have already deselected DHCP and given the NVR a static IP in the class 3 range (192.168.1.xx). I used the configTool to assign a static IP to all the cameras before connecting them to the NVR and that turned out to be a waste of time...