Strange Capture behavior in latest version (and previous associated beta)
  • Hi Ben,
    I have a camera where different two different maskings of the same field of view are defined as two different cameras. (The idea is to have a trigger and notification in a specific area, like my mailbox.) Let me refer to them as "defined area cameras" for this discussion.

    Some strange behavior started in the 4.1.5 beta series and continues into the current release version: It seems that a "defined area camera" seems to miss motion detection, or more properly, the motion appears to be captured in the other "defined area camera" where it shouldn't be and where it's masked out.

    Where it should appear in both, it only appears in one of the defined area cameras. It's almost like the motion captured by the defined area camera is based on the ip address or internal variable instead of what I have defined as the defined area camera name.

    Has there been some change in the programming where the captured video gets filed by IP address or other internal variable instead of the defined camera names (and associated masks)? I've just been seeing this too often to feel it's some other cause and it didn't occur before 4.1.5x Thanks.
  • We fixed a bug in 4.1.6 whereby some of the parts of the image outside the defined mask were erroneously being used for motion detection when they shouldn't be. There were a few tweaks to the motion-detection algorithm to do with filtering out isolated pixels of motion and taking more account of multiple pixels with motion grouped together (indicating an actual object rather than noise).

    This all should have made the motion detection more accurate, so your report is a bit perplexing!

    Probably the best way for you to debug this is to look at which areas of the image are shown in red, under Preferences -> Cameras -> Masks. Areas that have motion detected are highlighted here in red, so this may help you see what is going on with your situation.
  • Ben,
    I reverted back to 4.1.5b15 where things worked well and it seems to be working as it had previously. I'm wondering if your new algorithm is too insensitive for very small areas of interest (like a mailbox) and where (reciprocally) the masking area is very large. BTW, I have the sensitivity set at 99 or 100 and the capture time to 0.5 seconds. With 4.1.6, it misses capturing motion events. With 4.1.5b15 it seems to work properly.
  • The problem with 4.1.5 was that it was erroneously using pixels for motion detection that were outside the area defined by the mask. So it could be that the area left exposed by the mask is too small for 4.1.6 to detect anything, but was big enough for 4.1.5 simply because it wasn't respecting the boundaries of the mask properly. Could you please try 4.1.6, but make the are exposed by the mask (i.e. not green) larger?
  • Hi Ben
    I will try again with 4.1.6. The problem I'm having is that the area of interest falls between branches of trees, so I need to keep the mask small to prevent tree movement from creating false positives. One thing that occurred to me is that with a large mask, (area of interest small), 0.5 seconds is now too insensitive and "single frame" is too sensitive. Any possibility of having 0.25 seconds as a motion option, or is that overkill?
  • I think 0.5 is the absolute minimum trigger time that should be used in order to cut down on false-positive detections for cameras pointed outdoors. I would suggest making the area of interest defined by the mask a little larger (after all, this is what v4.1.5 is doing erroneously). If you can email us a screenshot of your current mask we may be able to make some suggestions.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!