Some 'Analysis' monitors not creating motion events, unknown why.

[baudneo]

Describe Your Environment

• Version of ZoneMinder [release version, development version, or commit]
  f0088e4
• How you installed ZoneMinder [e.g. PPA, RPMFusion, from-source, etc]
  source
• Full name and version of OS
  Ubuntu Jammy
• Browser name and version (if this is an issue with the web interface)

Describe the bug
Only some (2/5) Monitors set as:

• Capture: always
• Decoding: always
• Analysis: always
• Recording: on motion/trigger

are not triggering anymore and haven't since February 18th. Restarting the monitors or zm itself doesn't help. I did not change any monitor OR zone configs at all, and I have checked the DB to make sure the settings are indeed as the frontend says.

If I manually trigger an event, it works. The zone sensitivity is maxed to test. I remember having an issue like this before, the DB had different values than the frontend was reporting, but this isn't the case from what I can see this time. Kind of stumped as where to start.

I may go through the front end and click save on zones and configs just to rewrite them to the DB and see if that helps, but as of now, I can't get 2 of my monitors to create motion events when they have been working flawlessly for quite a long time before Feb 18th.

I have compiled 2 times from source since Feb 18th and the issue persists through upgrades. Feb 18th commit also caused the other issue I have open with motion events being tagged as 'Continuous'. The commit for that is: 904f062

To Reproduce
N/A

Expected behaviour
Events are created for monitors that are configured to.

Debug Logs
N/A

[baudneo]

Did everything I could think of besides cloning the monitors and then deleting the old ones. I may just clone and delete but before I do, is there any debug logging I should be doing to see what the issue could be?

[connortechnology]

As always the answers are in the logs. I am surprised and worried that it isn't recording events. If anything causes score to be non zero, we create an event. Unless.. you have a strange or large value for alarm_frames meaning that you need a lot of alarmed frames before we create an event.

[baudneo]

Just not sure where exactly I should be looking in debug logs. There's a large amount of output on zmc debug level 5. If you can give me a bit of direction to what lines or sections I should be homing into?

Alarm-frames = 3 on both non recording monitors. The recording monitors also have alarm_frame = 3.

IIRC, I had this issue a cpl times awhile ago (year or so ago) and the remedy was to check DB, the db and frontend were out of sync and updating db values corrected 1 issue. The other issue was a clone and delete the old monitors. The only issue with clone and delete is I have some archived events and I would need to mess with db to "adopt" an event to a new monitor id, not a biggie.

I would just kind of like to get to the bottom of it even though it's not a big issue. I'll clone monitors and not delete the old ones so I can try digging through logs and see if I can spot any differences between a recording and not recording monitor.

Weird question but, is there a way to "adopt" an event to a new mid besides manual db editing?

[connortechnology]

All this stuff happens between line 1972 to 2445 ish. Level 3 should be plenty.

[baudneo]

Kk thanks, I'll try drilling down tonight and report back.

[rabsym]

I'm having the same issue as baudneo with latest master, going back solve issue.

[connortechnology]

Latest code may fix this. Please update and report.

[baudneo]

@rabsym what commit did u downgrade to? My issue started Feb 18th.

Just updating, I haven't found logs of interest yet but, I did clone the monitors and the clones monitors are also not creating events. Just thought I should mention it.

I am @ work but will do an upgrade remotely over coffee break and report back.

[rabsym]

@baudneo I was using zoneminder_1.37.50~20240126.68-bookworm_amd64.deb, i think commit is b5757a2.

@connortechnology now opening events but still anything strange related to EVENT_CLOSE_MODE. What mode should i use to not doing continuous event but open when motion honoring "Alarm Frame Count" and closing when object_detected or going idle after alarm?

When first motion detected it start to do defined "section lenght" (5 minutes) (continuous) events all time as seen in capture attached...

Thanks!

[connortechnology]

I have a suspicion that somethen went wrong when I added a per-monitor event_close_mode setting on the Misc tab. It should have defaulted to System, which means use the value from the Config table. However, some of my monitors seem to have defaulted to "Time". So double check that. Your pic shows Time behaviour.

[connortechnology]

Actually it shows the new Duration behaviour, which is really the old Time behaviour.

[baudneo]

I am getting motion events on the cloned monitors now but they are labeled as continuous. Will test some more after work when I can go and wave my arms around in a zone.

[rabsym]

I checked DB and it shows "idle" for this monitor because I changed it to try if that helped but 15 other monitors showing "system" and having the same behaviour.

[baudneo]

Ok, so, monitors set to only record on motion are now recording continuous events. Motion detection appears to be working as continuous events also have motion notes. All event close modes are set to System in Misc. tab.

[rabsym]

Not sure because of still understanding states change but maybe related to this commit? e78c873

[baudneo]

Fixed.