Dahua NVR Reboots during the day
- Thread starter Tygunn
- Start date
HMS
Young grasshopper
Key phrase in bold "going to be doing" as in future tense.
I was just getting in the process of ordering cameras and a DVR when this all started to go to hell you guys. My only personal complication is that I'm going to be running right around 32 cameras so I was going to have two DVRs so twice the fun. I've also sense look at going to Blue Iris like you and still will most likely if nothing else just to broaden my availables though I do hope the DVR issue is fixed.
I was just getting in the process of ordering cameras and a DVR when this all started to go to hell you guys. My only personal complication is that I'm going to be running right around 32 cameras so I was going to have two DVRs so twice the fun. I've also sense look at going to Blue Iris like you and still will most likely if nothing else just to broaden my availables though I do hope the DVR issue is fixed.
@Tygunn - Can you confirm reboots have stopped after applying the new firmware? I also, just have Dahua cameras. 7 reboots today, already.
- Dec 24, 2016
- 409
- 320
I have not had any reboots so far since upgrading while running 9 Dahua cameras. So it seems to have helped.
When you upgrade, reset everything to defaults and reconfigure it all. It sounds like a pain (and it is), but I worry the firmware upgrades don't migrate well so you could get something into a bad state.
- Dec 24, 2016
- 409
- 320
I upgraded and then reset. I don't think it makes a difference though.
Right but didn't they stop for you a week or so before you updated the firmware on the NVR?
I have only 3 Dahua cameras recording... But at one point I had a HOSAFE camera also recording. Naturally, when i told the nvr to record general (24/7) and IVS alarms.... I told it to apply to all 4 channels. But, I haven't had the HOSAFE hooked into the network for a while, so it was just a black screen.
Just to see what happened, yesterday i told that channel to only record general and no ivs. Today i had 4 reboots. Still on the old firmware.
HMS
Young grasshopper
So, any new updates to share? new crashes? everything working as intended? meteors falling from the sky? Mind you i don't think the firmware would be the cause of that, But...
HMS
Young grasshopper
I've given up on this NVR.
The reboots aren't an issue on mine anymore, but I don't see much hope for Dahua resolving the issue where they don't wait for a full frame before they start a recording. And because they don't, the first second or two of all new recordings can be lost.
For my use, that makes this NVR only good for 24/7 recording w/o Motion Detection or IVS recordings.
The reboots aren't an issue on mine anymore, but I don't see much hope for Dahua resolving the issue where they don't wait for a full frame before they start a recording. And because they don't, the first second or two of all new recordings can be lost.
For my use, that makes this NVR only good for 24/7 recording w/o Motion Detection or IVS recordings.
That's exactly the situation I was in with a rebranded Hikvision NVR. Even with this issue the 5216-4ks2 is "less bad" for me and my use. Pretty sad situation with both companies. At least SmartPSS doesn't crash for me, which wasn't the case with a whole bunch of different versions of the Hik PC client.
I just did the update. Too soon to tell if reboots are resolved. I only have 5 Dahua cameras, with a 6th I just received that will be installed this weekend.
So far, all I needed to do was reinstall the plugin in Firefox and no problem accessing the WebGUI for the NVR. Looked at Events and I can now set up IVS rules right on the NVR.
Will monitor over the next few days, and report findings.
Oh, no Chinese text found anwhere. Only real problem is the S/N of the NVR is not readable. It's been this way since receiving it.
Update: It looks like ANR (Automatic Network Replenishment) is working! I see no gaps in the camera timelines. May be premature, will keep an eye on it. This is based on the reboot after doing the upgrade.
Last edited:
If you have an SD card or something and the nvr looses connection, when it comes back online it will pull from the sd card and replace any missing data. I believe that is how it works.
Taken from Dahua Spec sheet:
ANR (Automatic Network Replenishment Technology)
Video record in SD card in IP cameras when the network breaks down, and after the network recovered, the video will be transferred to NVR and then recorded in it.
HMS
Young grasshopper
Well, it nice to know thats working. if they can get the glitches with the IVS and motion capture people are having fixed this might be a viable option again.
Any more reports of the revised firmware on this NVR?
@Crazykiller posted a 'workaround' here, which whilst not ideal may still be good enough until dahua finally fix it (if they ever do)
Dahua NVR5216-4KS2 / NVR5216-16P-4KS2
@Crazykiller posted a 'workaround' here, which whilst not ideal may still be good enough until dahua finally fix it (if they ever do)
Dahua NVR5216-4KS2 / NVR5216-16P-4KS2
Exactly the same issue here. NVR5216-4KS2 and 4 cams purchased from Andy back in March. NVR just got setup on Saturday with a new WD Purple 4 TB drive. Already had one 5231R-Z camera that I had updated the f/w on, so that is all that is connected. I first saw a lockup on Saturday afternoon a couple of hours after I created a single IVS 'zig zag' tripwire to watch the street as an experiment - camera is two stories up. I noticed that objects with lower contrast against the light grey road would not trigger the rule. Small black dogs, yes ... small white dogs, no. Same with people and some cars. It missed a lot of people, bikes and cars rolling by without triggering. I even tried a 'sawtooth' pattern to see if it worked better with objects crossing more at a 90 deg. angle ... no change.
All my reboots are preceded by multiple, sequential Tripwire events in the log (multiple due to the zig zag detection line) except the '0x01' which had two tripwire events then a 'DEFAULT' event (whatever that means) entry preceding it. I have set iframe and fps to the same and still get the one or two second dropout after an IVS event (if not a crash). The 'crash' manifests as a total lockup - I can't see the mouse, let alone move it, click on it, etc. while connected directly to the NVR with VGA monitor. The NVR watchdog reboots itself a couple of minutes after a lockup. Total outage each cycle is about 5 minutes. Had 6 reboots with flag '0x6f' and one with flag '0x01' yesterday.
The IVR rule was turned off yesterday afternoon and no more reboots as of this morning. I'll setup one of the other new 5231R-Z cams without the f/w update tonight with a tripwire on it to test for a day. Can't say yet whether the camera with new f/w is a contributor or not. Will update here after my experiments.
BTW - Fan working OK, no detectable heat coming out of vent. Power brick barely warm to the touch.
Looking forward to see if the latest published f/w at least fixes the crashes. It's fugly for a security video system to drop 1-2 seconds of video when it detects an event, and useless if it crashes for 5 minutes several times a day. If not fixed, then I'll move on to Blue Iris for now.
I can't recall checking on my system, but the dropped frame issue only happens on the separate IVS event file correct? Or does it happen on the continuous recording file as well?
For example if you have continuous recoding set at 30 minute intervals and have an IVS event happen 20 minutes in, yes you lose the frame on that IVS file but if you download the full 30 minute continuous recording does it still have the dropped frame in that file?
For example if you have continuous recoding set at 30 minute intervals and have an IVS event happen 20 minutes in, yes you lose the frame on that IVS file but if you download the full 30 minute continuous recording does it still have the dropped frame in that file?