Dahua NVRs motion record with scheduled record skips frames
- Thread starter oh6hfx
- Start date
Yea, I have not experienced that yet, but one Dahua re seller told me it was not the NVR's but certain model cameras. I know I do not have the issue with the tribyrd dvr's and this does not happen on all 4k's either. I do know syncing the clocks does resolve it for me until they get out of sync again. This is what I found works. For a wile
To Do what I did you will need a PC or laptop side by side with your nvr.
1. Go direct to your nvr, go to settings then your time..leave it open and watch your clock
2 .Using a laptop or PC, log on to your NVR through the webgui, go to settings and time.
You might be surprised to see the times are running a few seconds apart as I was.
In my case the times were different and I was thinking they should be the same but they were not. So where is the webgui time setting pulling from?
I first thought it might be network lag but the web gui was like 4 seconds ahead of the NVR clock. I also logged in to one of my cameras and it was syncing with the clock time of the webgui and not the clock on the nvr. I synced them all with the pc and saved all the changes. I did a quick test with motion and came back and tested it and lost no time on the transition. Fixed right..Nope, Turns out the clock on the webgui was gaining time again vs what I was seeing on the NVR.
I cannot explain that but I saw it on 2 different 4K NVR's so I know there is a bug or two different clocks working somehow in that NVR. I tested that many times and it seems after syncing the clocks, the clock on the web gui was gaining a few seconds over the DVR clock. Now If I view footage through the NVr directly it is usually ok, but when using the web gui or smart pss I would get skipped frames. I realize the the webgui is just a virtual program but for whatever reason it is not in time with the NVR and causing issues. I usually leave it one or the other but usually not both because of this issue. i posted a link to that thread above.
Last edited:
hmjgriffon
Known around here
In Linux you just have to edit the ntpd config to allow other machines to sync to it, I run it on my firewall, I have noticed my dahua starlight turret seems to be about 5 seconds behind my hikvision cameras, they all sync to the firewall, in the hiks there is a test button, the dahua doesn't have that just save and refresh, it's set to sync every 10 minutes so I'm not sure why it's off, might change them all to sync every minute like @nayr, dunno if it will help though. Maybe the firmware is buggy, I might try syncing to PC then go back to NTP, at least then it will be closer to correct lol
Sent from my Nexus 6P using Tapatalk
Sent from my Nexus 6P using Tapatalk
I sync'd the nvr and camera clocks and now I lose a full minute of video on the event trigger. The worst ever!
I gave up on the LTS nvr because it won't let you access the event info from the web interface. The Dahua nvr lets you access the event info, but loses the video at the most critical time. Isn't continuous recording with events noted a basic function of these nvrs? So far I'm 2-for-2 on them being close to worthless.
As far as blaming the camera vs. the nvr goes, there are 2 things that have me leaning toward blaming the nvr: (1) Others in this thread have concluded that it's the nvr, and (2) I also have a Hikvision camera connected via ONVIF and it exhibits skipped frames, too. Nayr, my Dahua camera is a 4431M. I think you ran one of those for a while. Would you have noticed if frames were skipped with it?
I gave up on the LTS nvr because it won't let you access the event info from the web interface. The Dahua nvr lets you access the event info, but loses the video at the most critical time. Isn't continuous recording with events noted a basic function of these nvrs? So far I'm 2-for-2 on them being close to worthless.
As far as blaming the camera vs. the nvr goes, there are 2 things that have me leaning toward blaming the nvr: (1) Others in this thread have concluded that it's the nvr, and (2) I also have a Hikvision camera connected via ONVIF and it exhibits skipped frames, too. Nayr, my Dahua camera is a 4431M. I think you ran one of those for a while. Would you have noticed if frames were skipped with it?
nayr
IPCT Contributor
I have a 4431M-AS, but it was only up for a couple weeks and I dont think I ran motion detection on it.. might be that Chinese crap to blame.. I wasent really satisfied with that camera for the location I put it and it seemed underpowered and easy to overload.
I have the camera apart right now and a 25mm lens is coming tomorrow, I can check it later this week and see how it behaves.. was gonna try to use it for a backup LPR
Did you try SmartCodec?
I have the camera apart right now and a 25mm lens is coming tomorrow, I can check it later this week and see how it behaves.. was gonna try to use it for a backup LPR
Did you try SmartCodec?
I never paid attention to smart codec. I'm using IVS, not motion detection, and the manual says IVS doesn't work if smart codec is on. But I went to try it anyway, selected smart codec on, camera rebooted, and the page says smart codec is still off. So either the interface is lying to me or it won't turn smart codec on. It did however shut off the IVS detection. It would be great if you could check the frame dropping out with your 4431M (mine isn't the -AS, which I assume doesn't matter). I can read plates with the 4431M pretty well during the day. In the meantime I'll keep fiddling. Maybe there's something like 13 FPS with I-frame of 22 that will work ok.
I brought the camera into the house today and spent a few hours gathering details and devising a "mickey mouse" workaround.
First, I could find no combination of camera or NVR settings to eliminate the frame skipping problem. In the large majority of cases, between 1 and 3 seconds of video is lost. I had one case where over a minute was lost, a one-time outlier. The amount of lost video appears to be frame count related rather than time related. When running at a lower FPS, more video is lost, time-wise, and vice-versa. The 1 to 3 second typical loss is at 10 FPS.
Another finding is that the pre-record time setting is not used when running continuous+event recording. The change from the old to new video file is at the time of the event trigger. When running event recording only, the pre-record time is applied and the video file begins earlier than the event trigger. In this case, there aren't any skipped frames in the video.
When advancing in single frame mode, the video looks like this: The frames advance normally until they don't. Then the same frame is displayed for several single steps (usually 3 times at 10 FPS). On the next single step, the proper next frame is displayed. The next single step is when the frame skipping occurs. I'm thinking the number of frames skipped is the same number that were repeated (i.e 3 frames), but that's just a guess.
The workaround: I'm fairly confident of this information from testing inside, but it needs to be confirmed with the camera back outside for a day or two. I believe that this also constitutes proof that the problem lies in the NVR as opposed to the camera. Just sacrifice a channel of the NVR to collect event triggers, say for example channel 8. It has to have a camera hooked to it of course. Configure the other channels for continuous+event recording. For the event "record channel" settings, specify channel 8 only. Events from all of the cameras will be shown on the channel 8 timeline and file list. You have to manually use the trigger times to view the other cameras, but there won't be any lost frames in what you look at.
It's of course a nasty bug that needs to be fixed. Nayr, I'm eagerly waiting to find out how works on your 4216-4k.
First, I could find no combination of camera or NVR settings to eliminate the frame skipping problem. In the large majority of cases, between 1 and 3 seconds of video is lost. I had one case where over a minute was lost, a one-time outlier. The amount of lost video appears to be frame count related rather than time related. When running at a lower FPS, more video is lost, time-wise, and vice-versa. The 1 to 3 second typical loss is at 10 FPS.
Another finding is that the pre-record time setting is not used when running continuous+event recording. The change from the old to new video file is at the time of the event trigger. When running event recording only, the pre-record time is applied and the video file begins earlier than the event trigger. In this case, there aren't any skipped frames in the video.
When advancing in single frame mode, the video looks like this: The frames advance normally until they don't. Then the same frame is displayed for several single steps (usually 3 times at 10 FPS). On the next single step, the proper next frame is displayed. The next single step is when the frame skipping occurs. I'm thinking the number of frames skipped is the same number that were repeated (i.e 3 frames), but that's just a guess.
The workaround: I'm fairly confident of this information from testing inside, but it needs to be confirmed with the camera back outside for a day or two. I believe that this also constitutes proof that the problem lies in the NVR as opposed to the camera. Just sacrifice a channel of the NVR to collect event triggers, say for example channel 8. It has to have a camera hooked to it of course. Configure the other channels for continuous+event recording. For the event "record channel" settings, specify channel 8 only. Events from all of the cameras will be shown on the channel 8 timeline and file list. You have to manually use the trigger times to view the other cameras, but there won't be any lost frames in what you look at.
It's of course a nasty bug that needs to be fixed. Nayr, I'm eagerly waiting to find out how works on your 4216-4k.
I went on site today to check one of the 4k's, this one is 8 channel poe. I hit it with smart pss first, still a one or two second delay or skip and a few lost frames. I logged on to the webgui, same issue, I then went direct to the NVR, ZERO problems. All events were smooth with no lost frames. So viewing through the NVR is not a issue in this case. Viewing remotely is.
nayr
IPCT Contributor
if you export the clip outside the boundries do you get dropped frames? if not you have no problem, its just the apps pulling a new file and a lil pause is expected over IP
if no data is lost then who gives a fuck.
if no data is lost then who gives a fuck.
What format do you export the files in, and what do you use for a viewer? My stock windows won't decode either of the formats.
nayr
IPCT Contributor
cant help yeh with windows.. for OSX I made this bundle of tools that can handle the files fine: Dahua Video (*.DAV) Playback in Mac OSX
might see if SmartPlayer for Windows.. If from the WebUI it should give you a MP4, SmartPSS will give yeh DAV's
might see if SmartPlayer for Windows.. If from the WebUI it should give you a MP4, SmartPSS will give yeh DAV's
That seems to be a different issue, All file clips skip whether taken remotely, or at the nvr. So here is the bottom line, yes it is faulty, For right now Im done jerkin off with this issues because for mission critical issues I have 24/7 enabled and in a few places have two cams. I can definitely work around this for now and hope a firmware upgrade will fix this but I doubt it.
Opposite result for me. I just looked at yesterday's clips on the NVR interface and have the exact same lost frame behavior as seen on the web interface and Smart PSS.
I have some new info and am posting it in case somebody recognizes what's going on.
When all is quiet, the camera's time is usually one minute ahead of the NVR's time (camera time updates are shut off). Immediately after the skipped frames, the camera's clock loses 58 seconds and is sync'd with the nvr. Approximately 3 minutes later, the camera's clock jumps ahead exactly one minute, and is a minute ahead of the NVR again. At any random time when the camera clock is a minute ahead, if I go to the NVR's date/time setup page, then go back to live view, the camera time is again sync'd with the NVR time. A couple of minutes later the camera jumps ahead a minute. Pretty weird. Maybe connected to the skipped frames, maybe not.
When all is quiet, the camera's time is usually one minute ahead of the NVR's time (camera time updates are shut off). Immediately after the skipped frames, the camera's clock loses 58 seconds and is sync'd with the nvr. Approximately 3 minutes later, the camera's clock jumps ahead exactly one minute, and is a minute ahead of the NVR again. At any random time when the camera clock is a minute ahead, if I go to the NVR's date/time setup page, then go back to live view, the camera time is again sync'd with the NVR time. A couple of minutes later the camera jumps ahead a minute. Pretty weird. Maybe connected to the skipped frames, maybe not.
nayr
IPCT Contributor
I hope I'm understanding the question correctly. It's a Dahua camera and Dahua NVR, the camera manufacturer in the NVR device setup is "private". On the camera "Synchronize with NTP" is unchecked, and as a backup setting the time server name is bogus. I don't have a clue how the camera is getting its time set. I watched an event trigger on the camera's live view while disconnected from the NVR, and there weren't any skipped frames and the time didn't change, once again pointing the finger at the NVR.
nayr
IPCT Contributor
My 4431M menus are a bit different. Since it's in this screen shot I'll mention that I tried ntsc vs. pal already. Thanks for all the help, and I'm going to continue trying to find a way around this problem.
nayr
IPCT Contributor
