Dahua NVR Reboots during the day

You dont want a T processor for your load.....you also dont want a micro tower, they only hold 2.5 drives...
problem with dell is the tower will only hold a single 3.5 drive with room for a 2.5..
That is the same as an HP SFF...the hp elitedesk tower can hold 1x2.5 and 2x 3.5...
Have you tried/compared the "T" and sans "T" versions at the same clock speed on the same generation processor to report the BI % cpu difference. I am not implying that you are wrong, just curious if you have done the comparison? Intel makes a lot of internal choices on up and down clock and core usage, and i suspect the different bin classes get different micro code selection to achieve TDP, but nothing beasts a Toms HW sort of comparison. :)
 
Have you tried/compared the "T" and sans "T" versions at the same clock speed on the same generation processor to report the BI % cpu difference. I am not implying that you are wrong, just curious if you have done the comparison? Intel makes a lot of internal choices on up and down clock and core usage, and i suspect the different bin classes get different micro code selection to achieve TDP, but nothing beasts a Toms HW sort of comparison. :)
You cannot compare both. at the same clock speed because T processors by definition operate at a lower clock speed. The performance will be worse...the user will be running 32 2mp cameras...
also as noted the T processors are generally installed on slim systems that dont have room for a 3.5 drive...
 
To those waiting to hear what 0x06 means; here's what I have learned:
From Andy:
1.设备是否联网,是否使用P2P等功能。
Please check if you use the P2P function
2.重启间隔是多少?几天?几小时?是否有规律?
Reset any fixed time? How many times per day?
3.0x60是设备解码异常导致的重启。所以客户是否有接第三方摄像头?
0x60 is thedecodingfunction not good make the device restart, please check if you connect other cams?
4.本地界面是否有任何其他的提示?
Any more hints the nvr shows when the nvr booting?
5.如果重启频繁如几分钟就重启的,是否能够让客户讲摄像头断开,defualt之后看是否还会出现同样的问题
If too frequency, please take all cams off and make a default and check if still the same problem?

I don't use the P2P functionality, and I the reboots are not happening at the scheduled reboot time setup on the NVR. I have a single Hikvision DS-2CD2032-I camera attached to my NVR in addition to all the Dahuas. I'll have to try disconnecting the Hikvision from the NVR and see if that helps things out. I don't have any more hints to share about what the NVR, however I have an RS232 cable on order so I will continually monitor the console of the NVR to see if there is more information that I can glean.

Lol, and 0x60 being an image decoding failure causing reboot. Sounds like someone has some crappy error handling:
public class Nvr {
public static void main(String [] args) {
try {
beAnNvr();
} catch (Exception e) {
reboot();
}
}
}
 
So here's some things this tells me:
1. Its probably NOT the power supply; oh well doesn't hurt.
2. If a software decoding error can cause the NVR to reboot, then it seems plausible that ANY glitches caused by the cameras sending potentially erroneous data could cause the NVR to reboot. So it sounds like camera firmware changes could indeed impact the NVR.
3. If you have mixed manufacturers on the NVR, despite it being supported it seems its not a good idea.

I'm hoping they'll fix this bug; from an engineering standpoint it IS lame to bring down the entire device for an error like that. In the meantime I'm going to forge ahead with a Blue Iris setup which will operate in parallel. Its probably not a bad idea to have a backup anyways since its equally probably that Blue Iris could end up losing video due to random crashes in the same manner.
 
But in the mean time Cams and memory cards sound hard to beat, Thanks for the idea. i know within usually 12 hrs max if there's been a incident and if there is ill just power down the who system, yank cards and start sorting till i find the footage i nee, though i was hoping with some warning i might get a heads up and be able to catch the theives red handed. still waiting on security systems to be installed and thats just another thing im not ready to start doing just yet.

No need to "yank cards". These are POE cams, so you will have network cable ran to each for power anyway. So, it's simply a matter of using SmartPSS (free) or the cameras WebUI to get the video from the SD cards. No yanking required.
 
  • Like
Reactions: HMS
I don't use the P2P functionality, and I the reboots are not happening at the scheduled reboot time setup on the NVR. I have a single Hikvision DS-2CD2032-I camera attached to my NVR in addition to all the Dahuas. I'll have to try disconnecting the Hikvision from the NVR and see if that helps things out.
I use the P2P functionality now, but when I first got the NVR and had a reboot streak, it wasn't enabled.
My NVR is not setup to do any maintenance reboots.
I also have a single Hik camera connected -- DS-2CD2132F-I.

For my NVR, I think I've identified a condition that may cause it to 0x06f.

Apr 02 - Apr 25: no 0x06f reboots
Apr 26 - Apr 30: 22 0x06f reboots (after making a change)
Apr 30 - today: no 0x06f reboots (after removing the change)

The change that started the reboots on my NVR again was reconfiguring the Hik (and two of my 5231s) from 24/7 recording (with IVS) to Motion Detection recording (with IVS).

Undoing that change stopped the 0x06f reboots.

I'll try reconfiguring the Hik back to Motion Detection recording when I get home from work and see if that causes more 0x06fs.
 
I use the P2P functionality now, but when I first got the NVR and had a reboot streak, it wasn't enabled.
My NVR is not setup to do any maintenance reboots.
I also have a single Hik camera connected -- DS-2CD2132F-I.

For my NVR, I think I've identified a condition that may cause it to 0x06f.

Apr 02 - Apr 25: no 0x06f reboots
Apr 26 - Apr 30: 22 0x06f reboots (after making a change)
Apr 30 - today: no 0x06f reboots (after removing the change)

The change that started the reboots on my NVR again was reconfiguring the Hik (and two of my 5231s) from 24/7 recording (with IVS) to Motion Detection recording (with IVS).

Undoing that change stopped the 0x06f reboots.

I'll try reconfiguring the Hik back to Motion Detection recording when I get home from work and see if that causes more 0x06fs.

My Hik has always recorded 24/7. I only more recently activated the motion events on it. I'll see if turning it back to 24/7 is enough. OR just remove it entirely and have it only record to blue iris.
 
  • Like
Reactions: aristobrat
To those waiting to hear what 0x06 means; here's what I have learned:
From Andy:
1.设备是否联网,是否使用P2P等功能。
Please check if you use the P2P function
2.重启间隔是多少?几天?几小时?是否有规律?
Reset any fixed time? How many times per day?
3.0x60是设备解码异常导致的重启。所以客户是否有接第三方摄像头?
0x60 is thedecodingfunction not good make the device restart, please check if you connect other cams?
4.本地界面是否有任何其他的提示?
Any more hints the nvr shows when the nvr booting?
5.如果重启频繁如几分钟就重启的,是否能够让客户讲摄像头断开,defualt之后看是否还会出现同样的问题
If too frequency, please take all cams off and make a default and check if still the same problem?

I don't use the P2P functionality, and I the reboots are not happening at the scheduled reboot time setup on the NVR. I have a single Hikvision DS-2CD2032-I camera attached to my NVR in addition to all the Dahuas. I'll have to try disconnecting the Hikvision from the NVR and see if that helps things out. I don't have any more hints to share about what the NVR, however I have an RS232 cable on order so I will continually monitor the console of the NVR to see if there is more information that I can glean.

Lol, and 0x60 being an image decoding failure causing reboot. Sounds like someone has some crappy error handling:
public class Nvr {
public static void main(String [] args) {
try {
beAnNvr();
} catch (Exception e) {
reboot();
}
}
}

Stupid question but are we talking 0x06 or 0x60? Guessing they'll be two different error codes....
 
Stupid question but are we talking 0x06 or 0x60? Guessing they'll be two different error codes....

I had reported 0x06 to Andy originally; I presume it was just a transposition error in the email.
 
Stupid question but are we talking 0x06 or 0x60? Guessing they'll be two different error codes....
You're so literal.... lol, jk ... very good point. I assumed it was a typo, but def. worth clarifying!
 
No need to "yank cards". These are POE cams, so you will have network cable ran to each for power anyway. So, it's simply a matter of using SmartPSS (free) or the cameras WebUI to get the video from the SD cards. No yanking required.

Yea when i thought of it, was the trailer load of power bricks i got, set them up on the ground, hook a laptop to them and start plugging them in. (building im putting these in has power almost everywhere inside in and out.

But yea your right...

Funny thing to note though, owner from another site had me come over to do a estmate for repairs they, hit his buisness for over 20k in damages, as im walking with him i asked if he had any luck getting a estimate on a camera set up, his reply was no , but i got it covered for now. OK, i ask what you do hit sams or cosco? his reply nope, gander mountain. :blankstare: huh? Yup he had bought every trailcam they had in they place. i have no idea how many diffrent brands. when i walked into the building i could count over 50 in the 100ft i had walked. i asked him do you hunt, he replied yup. i asked, around here? Nope Ohio he replied. I said well, thats good. he asked why, i replied well if your hunting the whole state of Ohio you just might have enough trail cams.

He didn't think i was funny....
 
  • Like
Reactions: aristobrat
@mmdb do you have any idea how often your NVR is rebooting and what error coades it showing, and what brand cameras do you have running on it and how many? With MMDB having a POE powered NVR and still having crashed maybe its been a coincidence that everyone else is NON POE ported NVR and its a camera brand issue causing errors that crashing. @Tygunn Did you get that new power brick in yet and if yes, any luck? Though if mmdb is running non dahua cams it goes with your train of thought of cam errors instead of power...
 
@mmdb do you have any idea how often your NVR is rebooting and what error coades it showing, and what brand cameras do you have running on it and how many? With MMDB having a POE powered NVR and still having crashed maybe its been a coincidence that everyone else is NON POE ported NVR and its a camera brand issue causing errors that crashing. @Tygunn Did you get that new power brick in yet and if yes, any luck? Though if mmdb is running non dahua cams it goes with your train of thought of cam errors instead of power...

My new power brick was supposed to arrive last night but it appears my Amazon order has been delayed. <gasp> :) I'm going to see if I can force a reboot by causing lots of motion triggers on the Hikvision camera. Its in the garage where there is almost never motion. However, now as summer approaches the angle of the sun causes lots of shadows through the garage window which is causing plenty of false motion triggers in the garage.
 
My new power brick was supposed to arrive last night but it appears my Amazon order has been delayed. <gasp> :) I'm going to see if I can force a reboot by causing lots of motion triggers on the Hikvision camera. Its in the garage where there is almost never motion. However, now as summer approaches the angle of the sun causes lots of shadows through the garage window which is causing plenty of false motion triggers in the garage.

im curious if is just non Dahua cams. if you can get it to start rebooting multiple times, id try and unhook the HIK cam all together, set up a bunch of IVS/motions triggers on the dahuas and then go nuts tripping them and see if it errors. we got other members running the same firmware on dahua cams and on there NVR but there ONLY running Dahua cams with no reboots... Path of elimination..
 
So here's some things this tells me:
1. Its probably NOT the power supply; oh well doesn't hurt.
2. If a software decoding error can cause the NVR to reboot, then it seems plausible that ANY glitches caused by the cameras sending potentially erroneous data could cause the NVR to reboot. So it sounds like camera firmware changes could indeed impact the NVR.
3. If you have mixed manufacturers on the NVR, despite it being supported it seems its not a good idea.

I'm hoping they'll fix this bug; from an engineering standpoint it IS lame to bring down the entire device for an error like that. In the meantime I'm going to forge ahead with a Blue Iris setup which will operate in parallel. Its probably not a bad idea to have a backup anyways since its equally probably that Blue Iris could end up losing video due to random crashes in the same manner.

my BI setup is pretty rock solid. Only time I have an issue if if I do an update and it causes an issue.
 
If my Hikvision is causing the problem, I think it might be the motion events. For some reason they're not triggering on the NVR any more and I only get the continual recording. It looks like its enabled in the NVR settings now but I can't for the life of me get it to work again. I'll have to see if I Can get it it working again and see if that causes crashes.
 
Okay, I seem to be recording motion events on the Hik again. We will see if I get magical instability now.
 
I find it pretty hard to believe this is an image decoding error. Yesterday, on my front door cam (all cams, too) timeline I counted 9 reboots with the error. ALL were caused when an IVS trigger was tripped. I do use 24/7 recording, no P2P, and only tripwires for triggers on all 4 cams. I do not have any other brands of camera. Everything is Dahua, all bought through Andy.
One question I do have is, when a trigger is tripped, does the NVR record a separate clip for this, or just put 'markers' on the existing 24/7 stream it's already recording?

I also will be setting up a BI machine, as this POS is way too unreliable.
 
I was seriously looking at getting one of these to replace my BI system but after reading all this I'll be sticking with BI. It's solid and reliable. Definite case of the grass not being greener.....
 
I was seriously looking at getting one of these to replace my BI system but after reading all this I'll be sticking with BI. It's solid and reliable. Definite case of the grass not being greener.....

Smart move. Seriously thinking of sending mine back to Andy for a refund. If a new firmware update shows soon that resolves this for the rest of you, great. Otherwise, back to China this goes.