Got a message back from Support that 5.5.2.4 should fix the problem, and it has.
5.5.2 - November 3, 2021
- Thread starter fenderman
- Start date
sebastiantombs
Known around here
Out of curiosity, are you guys that re experiencing this running the CPU or GPU version? The reason I ask is because I haven't seen that behavior.
I am running CPU.
Actually, maybe it's not the same thing. The blue boxes on mine are actually around a few stationary vehicles in my driveway when a car drives by on the road. When re-running in the DeepStack status window, it never really seems to catch the car driving by.
Unfortunately not for me...
Here's another screenshot from another camera:
T-66 detecting object only by chance, as the leading motion rectangle just marginally overlaps the object box.
t+999 perfectly in sync with the motion rectangle: correct and reliable detection.
Last edited:
Jetson Nano , here.
Dave Lonsdale
Pulling my weight
I have a Nvidia T600 GPU. 5.5.2.4 went a long way towards fixing the problem.
But I ask again if anyone can help me understand what’s going on:-
Referring to my second image above having the blue rectangle, from the help file it was cancelled because there was no highlight ”in which Blue Iris is attempting to match DeepStack objects”. However, if you simply look at the alert in BI instead of using the DS status window, at that instant it shows a red trigger rectangle. My understanding was that BI sends this image to DS for analysis followed by the additional images that we specify at 500mS intervals or whatever. So what’s the, “did not overlap areas where motion was detected” all about?
Is the highlight function somehow used to indicate how BI stops DS from analysing successive images when confirmation has been achieved? If so it’s screwing things up. And I always want all the additional images to be analysed to get the best one which is why I put an object in the Cancel box that will never be found (in my case “banana”).
sebastiantombs
Known around here
Just my own observations. I don't use highlights, I use rectangles. They always seem to lag the target and I'm getting 99% detection with DS.
Dave Lonsdale
Pulling my weight
Hi sebastiontombs, I think there may be a misunderstanding - I also use rectangles instead of highlights. I only check the highlight box in the DS status window afterwards because its absence indicates the reason for cancellation. I’m trying to find out why, on the basis that it‘s merely used to give a visual indication and perhaps nothing to do with what’s going on in the software.
sebastiantombs
Known around here
I don't know that in this case there's a difference between highlights and rectangles. My point being that the rectangles also lag behind the object so, in my befuddled brain, lagging highlights aren't surprising at all or indicative of a problem there. Remember that DS is getting a jpg to analyze and BI may very well be "stripping" highlights or rectangles from them to lower the "confusion" level for DS analysis. In fact I would bet that is indeed the case, stripping motion indicators.
We also know that using analysis of an existing video produces different results, generally better detection, than the real time detection produces. While it may be apples to oranges it is pretty close at times. It would be great is real time worked as well as analysis but it just isn't there yet.
We also know that using analysis of an existing video produces different results, generally better detection, than the real time detection produces. While it may be apples to oranges it is pretty close at times. It would be great is real time worked as well as analysis but it just isn't there yet.
@Dave Lonsdale You may have seen it already but some useful information in relation to main- & substream motion detection & deepstack analysis in this thread:
BTW, .5 didn't fix it for me. A step back on my system.
As per the documentation, the motion highlight rectangle you find in the DS status window is used by BI to check if the detected object is related to the actual motion. If not (motion highlight do not overlap to detected object), alert is cancelled. I think this is used to mitigate false alarms due to static objects detection. For me this feature is disrupting.
There is no dependability also on those cameras where only the sub-stream is used. The behaviour is always the same.
Maybe an option to disable the overlapping check would do the trick.
As per the documentation, the motion highlight rectangle you find in the DS status window is used by BI to check if the detected object is related to the actual motion. If not (motion highlight do not overlap to detected object), alert is cancelled. I think this is used to mitigate false alarms due to static objects detection. For me this feature is disrupting.
There is no dependability also on those cameras where only the sub-stream is used. The behaviour is always the same.
Maybe an option to disable the overlapping check would do the trick.
5.5.25 fixes it for me (DS CPU version). The only issue I'm still observing is the yellow motion overlay is not added for analysis for the second sample (T-76msec) however object detection is processed as expected
sebastiantombs
Known around here
I just spent an hour "fixing" deepstack after months of good operation using a GTX970. Around noon today it started failing, out of the blue, with the dreaded "100" error. Detection times went up from >200ms to over 10,000ms. Stopped and restarted DS. Stopped and restarted BI. Stopped and restarted both. Nothing worked. Rebooted and started getting 404 errors with semi-reasonable detection times but no confirmed detections.
Stopped BI from running as a service and shut it down. Uninstalled deepstack. Moved the whole directory structure off the C: drive, DS leaves a lot of stuff behind in an uninstall. Reinstalled DS. Put the models directory back with a new copy of dark.pt. It was still giving me 404 errors and no confirmed detections. Stopped and restarted DS and everything is finally working again.
I haven't got a clue what went corrupt, but something did. The CPU was spiking to 100% with every trigger. That's what actually caught my eye and made me start investigating. If I had to guess I'd say the executable went corrupt, but have no way to confirm that.
Stopped BI from running as a service and shut it down. Uninstalled deepstack. Moved the whole directory structure off the C: drive, DS leaves a lot of stuff behind in an uninstall. Reinstalled DS. Put the models directory back with a new copy of dark.pt. It was still giving me 404 errors and no confirmed detections. Stopped and restarted DS and everything is finally working again.
I haven't got a clue what went corrupt, but something did. The CPU was spiking to 100% with every trigger. That's what actually caught my eye and made me start investigating. If I had to guess I'd say the executable went corrupt, but have no way to confirm that.
I confirm that even 5.5.2.30 hasn't fixed it form me. Please have a look to the following sequence of screenshots. The motion-leading image will influence the T-XX image detection. The motion rectangle, in fact, is not updated in the T-XX image leading to cancelled alerts in some conditions:
a) if the DeepStack detection is ENABLED for the leading-image and the leading image has overlapping rectangles (motion highlight and detection) then also the T-XX will detect the object and confirm alert.
b) if the DeepStack detection is ENABLED for the leading-image and the leading image has NOT overlapping rectangles (motion highlight and detection) then also the T-XX will not detect the object and CANCEL alert.
c) if the DeepStack detection is DISABLED for the leading-image, the T-XX image detected object rectangle will be checked against the leading-image motion rectangle, not the one related to the T-XX, thus leading to many erroneously cancelled alerts.
d) the following detection after T-XX work perfectly.
So, something is still wrong with the first image detection after the leading motion image (ie. T-XX). Will also forward this post to Ken.
Example of point B (bench is not in the list of valid objects BTW)
Example of point C:
a) if the DeepStack detection is ENABLED for the leading-image and the leading image has overlapping rectangles (motion highlight and detection) then also the T-XX will detect the object and confirm alert.
b) if the DeepStack detection is ENABLED for the leading-image and the leading image has NOT overlapping rectangles (motion highlight and detection) then also the T-XX will not detect the object and CANCEL alert.
c) if the DeepStack detection is DISABLED for the leading-image, the T-XX image detected object rectangle will be checked against the leading-image motion rectangle, not the one related to the T-XX, thus leading to many erroneously cancelled alerts.
d) the following detection after T-XX work perfectly.
So, something is still wrong with the first image detection after the leading motion image (ie. T-XX). Will also forward this post to Ken.
Example of point B (bench is not in the list of valid objects BTW)
Example of point C: