Dahua NVRs motion record with scheduled record skips frames

[TechBill]

I exported w/SmartPSS.. and I'm still running the 4216, the 5216 is in the mail, might be here monday.

I am watching this thread now, I have a 5216 too but it not hooked up yet. I will be hooking it up very soon, and plan to do 24/7 with event detection

 

[Moto32]

somehow missed this thread, but I have never seen the behavior you guys are describing.. so I went and checked all my cameras and all the General/Motion/Alarm settings were identical across the board.. I guess that's something thats something I've been setting up all along and didnt even think about.

great work figuring it out, I think this is some often unused feature where you can configure events to crank the quality/framerate up higher than normal in response to activity.. it appears that doing this could result in dropped frames as the encoder is changing its configuration on the fly.. I wonder if VBR config for both Continuous and Events with different bitrates also has the problem.. It makes a little sense that a CBR stream changing its bitrate on the fly could cause some dropped frames while the decoders adjust to the unexpected change.

props to Nelly's for pointing you guys to the right answer.. pretty much every problem I've ever had with my Dahua's has been due to a bad config and tweaking things and resetting em to defaults on occasion resolved my issues.. so the issues were always PEBCAK, even when I was convinced it was a firmware bug.. just recently I had an issue where I was loosing motion/alarm/ivs events on timeline after NVR reboot, after banging my head against the wall forever I reset the EVENT and STORAGE settings on NVR to default and reconfigured em again and the problem went away entirely.. Its seems the NVR will gladly take a bad configuration and then make your hair turn grey with weird problems until you figure out what it was that was messed up all along.

I joined just to Thank You SO MUCH for this post. I have been dealing with this for three years... GREAT FIND!!!!!

 

[Bramboo]

I recently purchased an NVR 4108-P-4KS2 and encountered the issue with the missing video when an IVS event is triggered. The latest firmware seems to have addressed the different stream encoding: when you select an encoding method in "Continuous" it copies this setting to "MD" and "Alarms" and you cannot choose a different setting here. However, often I miss a couple of seconds (sometimes >10 seconds) on every IVS trigger...

I've been trying different settings in the cams (recording on IVS trigger on/off, snapshot on/off, etc.) but it doesn't help. I'm recording all streams 24/7, but it would be great to see the IVS marks in the timeline, so you can easily jump to the interesting parts of the recording.

 

[Zachi Gigi]

I recently purchased an NVR 4108-P-4KS2 and encountered the issue with the missing video when an IVS event is triggered. The latest firmware seems to have addressed the different stream encoding: when you select an encoding method in "Continuous" it copies this setting to "MD" and "Alarms" and you cannot choose a different setting here. However, often I miss a couple of seconds (sometimes >10 seconds) on every IVS trigger...

I've been trying different settings in the cams (recording on IVS trigger on/off, snapshot on/off, etc.) but it doesn't help. I'm recording all streams 24/7, but it would be great to see the IVS marks in the timeline, so you can easily jump to the interesting parts of the recording.

Hi,

I'm encoutering a similar problem on my NVR4104-P-4KS2. Whenever an IVS Tripwire event is triggered, I'm missing 2-3 minutes (!!!) of recorded video after the event clears/ends.
So my 24/7 recorded stream have -3 minutes long MISSING Video Chunks/Blocks :-(

Did you solve your issue? Is that a known firmware bug?

 

[Bramboo]

I am still playing with various settings. What I noticed is that when you playback an event, you get different results when you choose 'All' or 'Normal'.
With 'Normal' (I find this the easiest way to find events) I sometimes get a missing part in the stream, with 'All' this seems not to be an issue.

It's not consistent, so I don't have the answer you're looking for.

 

[Zachi Gigi]

I am still playing with various settings. What I noticed is that when you playback an event, you get different results when you choose 'All' or 'Normal'.
With 'Normal' (I find this the easiest way to find events) I sometimes get a missing part in the stream, with 'All' this seems not to be an issue.

It's not consistent, so I don't have the answer you're looking for.

Ok. Thanks anyway. I’m also playing with the different settings. I think I got it this time. I’ve just added ‘IVS’ to the ‘Schedule’ recording, in addition to the ‘IVS Tripwire’ record settings and it seems the problem is solved so far. I’ll keep an eye on it, of course.

 

[tigerwillow1]

I have several posts earlier in this thread about lost frames on event triggers and see that I never reported on this thread that the problem was solved (for me) with nvr firmware version 3.210.0003.0 on the 5216-4ks2. I never had more than a few seconds at a time lost, so a gap of minutes might well be a totally different problem. With a gap like that I'd wonder if something might be causing the camera to reboot.

 

[Zachi Gigi]

I have several posts earlier in this thread about lost frames on event triggers and see that I never reported on this thread that the problem was solved (for me) with nvr firmware version 3.210.0003.0 on the 5216-4ks2. I never had more than a few seconds at a time lost, so a gap of minutes might well be a totally different problem. With a gap like that I'd wonder if something might be causing the camera to reboot.

Thanks for your detailed answer. Since the lost data gaps are big (2-3 min.) I was also suspecting the camera/nvr reboots.
Tweaking a bit this evening with some ‘IVS’ settings, I’ve added ‘IVS’ recording to the ‘Schedule’, in addition to the ‘IVS Tripwire Event’ recording, which was already enabled.
Surprisingly, this caused two GOOD things:
First of all, it seems that the problem I’ve reported before is gone. In addition, I now see the ‘IVS Events’ marked on the Recording Playback Scroll, which I didn’t see before.
So, I assume it was related to some wrong IVS settings. Of course, I’ll keep an eye on it. In addition, I might check as well that my NVR Firmware is up-to-date.
Thanks again,
Zachi.

 

[Blake1122]

I have installed now around 16-17 Dahua systems with NVRs 4108 and 4116, couple with 5276 NVRs too.

Normally I set them to record all channels 24/7 plus motion detection to record the channel where motion is detected.
That way I can see continuous green timeline with yellow marks where there has been motion. This is useful when you can spot the
motion and easily play all the video before and after - because motion detection does not detect everything.

The problem seems to be, however, that when NVR starts recording motion over normal record, it sometimes skips frames, even
1-2 seconds may be off.

Anybody found a cure for this or do I have to switch off motion record and just search "blind" over the timeline?

Example video, skipping 06:12:10

I'm having this exact issue, has there been an answer to solve this, I'm going crazy trying to work it out...

 

[Fastb]

I was involved early in this thread. I still have the problem.
I've never heard of a solution or workaround....

 

[Flintstone61]

i ported my Amcrest 4108 ( dahua OEM) in Blue Iris. So i can't help.
I wonder if there is a common thread in which type of Drive is recording on the systems. Like a Skyhawk or a WD Purple, or a Hitachi Deskstar, and if there is latency or Lag in the drives

 

[Fastb]

if there is a common thread in which type of Drive is recording

Interesting theory! My drive is an conventional HD, specifically,
Vivotek WD20PURX 2TB Surveillance SATA Hard Drive - 2TB, 5400RPM, 64MB Cache

An SSD, which is faster than a conventional HD, may have less lag. My theory is the lag is due to the NVR closing a file and starting a new post-IVS file to capture that event. So the lag may be due to:
1) an NVR processing lag (my initial theory), or
2) an HD lag (your hunch) to close and open a file.

I've never seen a thread on culprit #2....

Fastb

 

[garycrist]

With 64 M of cache, #2 is note the problem. I cut and pasted this.
Part-07: Data Transfer Rate-



Number of rotations in one second

= (3600 / 60) rotations/sec

= 60 rotations/sec



Now, Data transfer rate

= Number of heads x Capacity of one track x Number of rotations in one second

= 16 x (256 x 512 bytes) x 60

= 24 x 28 x 29 x 60 bytes/sec

= 60 x 221 bytes/sec

= 120 MBps

I have had fun with the MATH of disc drive transfer now in and out simultaneously hence the fast spin and excessive amount
of cache.

With predictive read ahead (the hd controller on disc) knows where the next read sector is so, it caches it in case the
next request to read is there.

Does that help?

Gary...

 

[Flintstone61]

Drive performance between drives varies. Esp when I took out the WD Blue drive out and put inthe WD Surveilance drive. The Blue drive was one of the SMR technology drives. a lot of waiting.

WD Red SMR vs CMR Tested Avoid Red SMR

We tested WD Red SMR v CMR drives to see if there was indeed a significant impact with the change. We found SMR can put data at risk 13-16x longer than CMR

www.servethehome.com

 

[bigredfish]

I’ve seen the problem on playback via NVR GUI as well as Smarpss, but the actual downloaded file is fine.

something I learned long ago was to make sure Bitrate, FPS, and Iframe are all identical on both General and Motion/smart recording . There’s a drop down menu on that screen at top that many overlook.

 

[bigredfish]

Ya know, now that I look at what I wrote above, it dawns in me this is for my analog XVR’s . They allow you to set those parameters for each type of recording.

UPDATE
I see it does apply to the NVR 3.0 and 4.0 interface as well though! Under Encode.

Whew, momentary senior moment.

 

[Blake1122]

I have lowed the bit rate on both of the cameras on two different nvr's that I was having the issue with. That fixed the issue for me.

I also noticed it doesn't happen with newer model cameras eg series 7.

Hope this helps someone else

 

[Pseudoreal]

I have the NVR5208 4kS2 (non POE) edition with 5 Dahua 5442 Cams and have noticed this behaviour too. However, I cannot have in sync the settings in each camera. I have as Encoding strategy general. When I switch it, it changes automatically to VBR with 4352kb/s. If I change it there, then my General encoding strategy is different.
I am having up to 8s loss looking it via the WebIf. Did not check SmartPSS or even directly with the NVR.

Edit: with the settings below - the smartPSS does not drop a frame, so it must be the browser (in this case google chrome)

 

[ipcflow]

I have the NVR5208 4kS2

same here.

it do no change if you use direct HDMI output from NVR or if you use SmartPSS or Web. This is a Firmware/Software Problem on NVR/IPC. (i would like to have the Firmware open source to fix it.. or see the bugs)

The problem is:

Event: VideoMotion is trigged every time in all cases (you need detection area), this cause a record - after this, SMD will trigger and than IVS rules are triggered and also start "Snapshot" ... the problem: IVS events and Motion/SMD are recorded in seperate files.

usualy it works fine if you have one IVS not overlapping with a other that triggers in a short time distance. otherwise this would cause problem in encoding split up the data streams to sepearte files and cause frames drop. (this is my thereoie ... i can not see sourcecode)

also its recomend to reboot every week the ipc one time. i am not sure why but if you run them too long it also cause lag and short stucks.

the problem is not the record speed of your drive, the nvr has cache/ram and hdd also has. and i use very fast SSD... so its not the drive it's software.

the problem also goes on lower resolution, i do not use 4k (8MP) records, i lowered them to 5MP - thats good enough.

 

[ipcflow]

it changes automatically to VBR with 4352kb/s

do not use VBR, i tryed a lot arround this make problems. Use CBR. Also i do not use any of the "SmartCodec" this makes quality bad. (but anyway has nothing to to with our problem of lag and droped frames) but just to help you

i also disabled the secound substream, only take cpu load and is not realy need for me.