How to stop 'linked' or 'signal/linked' events on wifi cams?

[marcmerlin]

Is the search broken? zoneminder search seems to search the docs, but not the forums?

Anyway, I have ZM 1.25 working fine, but on my wifi cams, I'm getting occasional disconnects, which show up as a blue frame instead of video, and they create an event:

2684 Event-2684 patiocam1 Signal 01/17 09:47:19 39.38 71 1 100 100 100
The last 3 fields are total score, avg score, and max score.

It seems that ZM creates a new event each time a camera connects/disconnects.
Can this be stopped?
I tried creating a zone filter that filters out anything with more than 90% change, but that didn't help.
It looks like camera disconnects don't create motion events anyway, but 'signal (reacquired)' or 'signal/linked' events.

If I'd like to stop them from spamming my logs and eating my disk how do I do that?

Thanks,
Marc

[marcmerlin]

I found this in the logs, which does show a disconnection/reconnection.

Jan 21 17:48:59 gargamel zmwatch[16665]: INF [Restarting capture daemon for LVR, time since last capture 6 seconds (1358819339-1358819333)]
Jan 21 17:49:03 gargamel zmdc[16528]: INF ['zmc -m 4' stopping at 13/01/21 17:49:03]
Jan 21 17:49:03 gargamel zmc_m4[16631]: INF [Got signal 15 (Terminated), exiting]
Jan 21 17:49:03 gargamel zma_m4[16638]: WAR [Signal: Lost]
Jan 21 17:49:03 gargamel zmdc[16528]: INF ['zmc -m 4' exited normally]
Jan 21 17:49:03 gargamel zmdc[16528]: INF [Starting pending process, zmc -m 4]
Jan 21 17:49:03 gargamel zmdc[16528]: INF ['zmc -m 4' starting at 13/01/21 17:49:03, pid = 18412]
Jan 21 17:49:03 gargamel zmdc[18412]: INF ['zmc -m 4' started at 13/01/21 17:49:03]
Jan 21 17:49:03 gargamel zmc_m4[18412]: INF [Starting Capture]
Jan 21 17:49:04 gargamel zma_m4[16638]: WAR [Signal: Reacquired]
Jan 21 17:49:04 gargamel zma_m4[16638]: INF [LVR: 491 - Gone into alarm state]
Jan 21 17:49:04 gargamel zma_m4[16638]: INF [LVR: 491 - Opening new event 2874, alarm start]
Jan 21 17:49:04 gargamel zma_m4[16638]: INF [LVR: 492 - Gone into alert state]
Jan 21 17:49:13 gargamel zma_m4[16638]: INF [LVR: 537 - Left alarm state (2874) - 46(1) images]
Jan 21 17:49:13 gargamel zma_m4[16638]: INF [LVR: 537 - Closing event 2874, alarm end]

Is this what's causing new events in my event stream?

[marcmerlin]

I'm still debugging this, I really want those fake events go away.
In the event manager, I see:
Cause: signal
Notes: Signal: Reacquired

I've confirmed that the logs show this at the same time this event happened.
Jan 22 07:44:01 gargamel zmc_m3[20620]: WAR [Select timed out]
Jan 22 07:44:01 gargamel zmc_m3[20620]: ERR [Connection dropped by remote end]
Jan 22 07:44:01 gargamel zmc_m3[20620]: WAR [Unable to capture image, retrying]
Jan 22 07:44:02 gargamel zma_m3[7053]: WAR [Signal: Lost]
Jan 22 07:44:06 gargamel zmc_m3[20620]: WAR [Select timed out]
Jan 22 07:44:06 gargamel zmc_m3[20620]: ERR [Connection dropped by remote end]
Jan 22 07:44:06 gargamel zmc_m3[20620]: WAR [Unable to capture image, retrying]
Jan 22 07:44:08 gargamel zma_m3[7053]: WAR [Signal: Reacquired]
Jan 22 07:44:08 gargamel zma_m3[7053]: INF [frontdoorcam1: 167849 - Gone into alarm state]
Jan 22 07:44:08 gargamel zma_m3[7053]: INF [frontdoorcam1: 167849 - Opening new event 3148, alarm start]

So, is it possible to not create a new alarm in a case like this, or do I need to write a filter to auto delete them all as soon as they happen?

[marcmerlin]

Mmmh, I have a more worrisome problem.
My only 720p camera (aircam dome via RSTP), is the one generating a lot of fake events, and some are very long (like 3 hours), which sucks a lot of disk when there was no motion.

I see cause:
Signal (linked: aircam1Motion: allSignal: Reacquired)
Signal (linked: aircam1Signal: ReacquiredRecovered)
Linked (aircam1Motion: All)

This clearly looks like a bug to me. Any idea how to work around it?

[jonathancnewcomb]

I created a filter that runs in the background to delete those. It doesnt "fix" anything, but it saves my event history

[marcmerlin]

Right, this is what I ended up having to do too, but I'm worried about the 'reacquired recovered linked' triple state message. That just doesn't sound too good code-wise.

Hopefully this will get fixed somehow.