5.4.9 - June 25, 2021

I also wanted to report on an issue I was having last week and figured out (CPU version). I noticed my DS analysis would always miss some random frames when I had the interval set to 500ms or lower. It would go 0ms, 500ms, 1000ms, 1500ms, 2500ms, for example, missing the 2000ms frame. I finally found that it was directly tied to the pre-trigger buffer. Decreasing it down to below 3 seconds totally solved the issue. I was only at 5s before, but now I keep it at 2.5s and don't get any missed frames. Might be worth checking out if anyone is having odd issues with DS.
 
Last edited:
  • Like
Reactions: Flintstone61, MaxBotev, looney2ns and 3 others
stev067 said:
I also wanted to report on an issue I was having last week and figured out (CPU version). I noticed my DS analysis would always miss some random frames when I had the interval set to 500ms or lower. It would go 0ms, 500ms, 1000ms, 15000ms, 25000ms, for example, missing the 2000ms frame. I finally found that it was directly tied to the pre-trigger buffer. Decreasing it down to below 3 seconds totally solved the issue. I was only at 5s before, but now I keep it at 2.5s and don't get any missed frames. Might be worth checking out if anyone is having odd issues with DS.
Click to expand...
I haven't had any issues caused by the pre-trigger buffer, I have mine set to 5 seconds, DS set to 6 images at 500ms intervals. When I check the DS analysis, it's showing the expected frames being processed by DS.

I did have random detection issues previously, but it was due to the CPU being bogged down by DS. I added a Quadro P400 and replaced the CPU version of DS with the GPU version. BI is using the i7-7700K for HA and DS is using the Quadro. Everything is working quite well now, DS detection is pretty consistent, even with custom (dark) model enabled. The only thing that's still inconsistent is face detection, but others have found that as well.
 
  • Like
Reactions: 105437, beepsilver, anijet and 1 other person
jaydeel said:
There was for awhile, but Ken considered it to be a bug and fixed it. :)

This is what the help pdf used to say…
View attachment 96748

Now it says this …
View attachment 96751


Let him know you’d like the hi-res image handling changed back to the previous behaviour. The more requests he gets the better.
Click to expand...

Looks like Ken add the bug/feature backinto .16 as I now have my confirmed alert images back :)
 
I see loads of people taking about Pre-trigger video buffer in this thread - I've personally got it disabled on all my cams as I 24/7 record the main streams. I was wondering if it could still add value, I did ask this in a dedicated post about a month ago but never got a response, could be the thread was overlook or maybe no one knows - My post was "Is there any value in enabling Pre-trigger video buffer if a camera(s) is setup to record 24/7 Continuous and there is only the main stream (one stream) - Could the Pre-trigger store frames in memory better for use with other elements such as motion detection/DeepStack AI etc?"
 
@CrazyAsYou - the prebuffer helps with at least two things:

  • If you are using the recording option continuous + triggered or continuous + alerts that records the substream until a trigger and then records the mainstream, then the pretrigger will start recording mainstream before the trigger happens. That may or may not be needed for your field of view.
  • The pretrigger allows you to get activity processing in between iframes. For people that have non-standard cameras, this may allow them to catch a motion that would be missed waiting for the next iframe after the trigger occurred. Even with a good camera, for something like using it for LPR, it is critical to have a prebuffer if you are looking to get high rez pics of the plate. The pretrigger has to be at least a little longer than the iframe/key frame interval. So if FPS and iframes match, then the pretrigger should be at least 1.1 seconds to catch the iframe prior to the motion.
I am sure there are other reasons as well, but these are the two primary reasons.
 
  • Like
Reactions: Flintstone61 and CrazyAsYou
CrazyAsYou said:
I see loads of people taking about Pre-trigger video buffer in this thread - I've personally got it disabled on all my cams as I 24/7 record the main streams. I was wondering if it could still add value, I did ask this in a dedicated post about a month ago but never got a response, could be the thread was overlook or maybe no one knows - My post was "Is there any value in enabling Pre-trigger video buffer if a camera(s) is setup to record 24/7 Continuous and there is only the main stream (one stream) - Could the Pre-trigger store frames in memory better for use with other elements such as motion detection/DeepStack AI etc?"
Click to expand...
In my case, I want to capture motion that happens outside of a motion zone. For example, the motion zone for my front path doesn't include the gate to cut down on shadows from people walking by on the sidewalk, so it only triggers when somebody walks down the path to my front door. The pretrigger allows me to capture when the person opens my front gate and starts down the path. It seems to help DS with people detection by providing more frames to analyze.
 
  • Like
Reactions: beepsilver and CrazyAsYou
@wittaj - I have 4 good cams FPS = iframes but also have two cheap cams with 0.25 iframes so I'll enable and adjust for based on the cheapo ones.

@kklee - I've got something simliar for my driveway and street pavement where I tend to detect only people legs on the leading images so will see if pre-buffer helps that
 
stev067 said:
I also wanted to report on an issue I was having last week and figured out (CPU version). I noticed my DS analysis would always miss some random frames when I had the interval set to 500ms or lower. It would go 0ms, 500ms, 1000ms, 15000ms, 25000ms, for example, missing the 2000ms frame. I finally found that it was directly tied to the pre-trigger buffer. Decreasing it down to below 3 seconds totally solved the issue. I was only at 5s before, but now I keep it at 2.5s and don't get any missed frames. Might be worth checking out if anyone is having odd issues with DS.
Click to expand...
I can confirm, this solution works just perfect. For some reason (did not install any updates or changed settings) my detection rate dropped drastically last week. I could literally stand in front of the camera waving my hands and DS would not detect anything. Pre-trigger buffer was set to 10 seconds. I changed it to 3 seconds and now everything is back to normal!
 
  • Like
Reactions: Flintstone61, beepsilver, looney2ns and 1 other person
MaxBotev said:
I could literally stand in front of the camera waving my hands and DS would not detect anything. Pre-trigger buffer was set to 10 seconds. I changed it to 3 seconds and now everything is back to normal!
Click to expand...
I hope someone can help with root cause of this. It could be a bug or I'm wondering if it could be a hardware (CPU / Memory) issue / limitation. I like having a long pre-trigger as I like seeing WHERE things come from, but want to only trigger once the object gets to a certain place. I like the 10 second pre-trigger as it really fits my needs, but I to have had to lower this to about 3-4 seconds to get my detection to work well.
 
MaxBotev said:
I can confirm, this solution works just perfect. For some reason (did not install any updates or changed settings) my detection rate dropped drastically last week. I could literally stand in front of the camera waving my hands and DS would not detect anything. Pre-trigger buffer was set to 10 seconds. I changed it to 3 seconds and now everything is back to normal!
Click to expand...

Thanks and welcome to the forum! I have to ask, what's the story behind your avatar?
 
kc8tmv said:
I hope someone can help with root cause of this. It could be a bug or I'm wondering if it could be a hardware (CPU / Memory) issue / limitation. I like having a long pre-trigger as I like seeing WHERE things come from, but want to only trigger once the object gets to a certain place. I like the 10 second pre-trigger as it really fits my needs, but I to have had to lower this to about 3-4 seconds to get my detection to work well.
Click to expand...

If you use substreams and choose continuous+trigger in your cam's recording tab, you can still get the info you're looking for albeit in your substream format.
 
kc8tmv said:
I hope someone can help with root cause of this. It could be a bug or I'm wondering if it could be a hardware (CPU / Memory) issue / limitation. I like having a long pre-trigger as I like seeing WHERE things come from, but want to only trigger once the object gets to a certain place. I like the 10 second pre-trigger as it really fits my needs, but I to have had to lower this to about 3-4 seconds to get my detection to work well.
Click to expand...

I had been emailing back and forth with Ken trying to troubleshoot the missed frames. He was leaning towards a CPU utilization issue, but I wasn't seeing that. I haven't heard back from him since last Tuesday when I let him know about this solution. I know he's busy so hopefully he didn't just get sick of me pestering him! Maybe if others can confirm the issue it would help.
 
It is related to timing and when images are sent to DS by BI. If the alert images start too soon DS won't see anything and either time out or report nothing detected. I've been using 3 seconds since I started with DS and it rarely, if ever, misses something unless contrast or headlight bloom are too much.
 
  • Like
Reactions: slabbel, beepsilver and MaxBotev
So strange on the pretrigger.

I have mine set for 15secs and I get weird numbers for DS analysis, but I do get them all, regardless of the set timing(500ms/750ms/1sec)

for example with 1 sec I get:

t-533
t+1
t+934
t+1934
t+2934
etc

and, the 'first frame', t+1 in this example always has a timestamp of the first frame of the trigger, not one in my pretrigger time
 
JL-F1 said:
So strange on the pretrigger.

I have mine set for 15secs and I get weird numbers for DS analysis, but I do get them all, regardless of the set timing(500ms/750ms/1sec)

for example with 1 sec I get:

t-533
t+1
t+934
t+1934
t+2934
etc

and, the 'first frame', t+1 in this example always has a timestamp of the first frame of the trigger, not one in my pretrigger time
Click to expand...

I don't think those numbers are really concerning. Ken had said that one of the newer releases has the reported timings reporting more accurately to the actual timings rather than just lining up with the intervals exactly. Those just line up with t-500 (motion leading), T+0, T+1000, T+2000, T+3000. It's very possible for the T-500 and T+0 to have the same timestamp because they occur within the same second half the time.
I would like to know why you aren't seeing the same issue as me and some others though.
Are you running CPU or GPU version?
Is your recording set to continuous + triggered or continuous + alerts?
Do you have "begin analysis with motion leading image" enabled?
 
GPU
'When triggered' during day 'Continuous' at night, must be why: I am using neither of the options you listed
"begin analysis with motion leading image" enabled
 
You must log in or register to reply here.
Top Bottom