Linked cameras sometimes not working

[geraldbrandt]

Running 1.36.5

I run detection on a low res stream and trigger recording on a high res stream. Since upgrading to 1.36, it seems that sometimes the linking doesn't work... I have a valid recording on the low res stream, and nothing on the high res stream.

I'm thinking it's related to making changes to any camera in the system... the last one I did was zone changes, and linking stopped working. Has anyone seen a similar issue before I start really digging?

Restarting Zoneminder solves the issue.

Gerald

[jsylvia007]

As far as I am aware this has ALWAYS been an issue I've had. I'm positive that I had it in 1.34. I usually just end up restarting ZoneMinder after I make any configuration changes at all.

[fmeili1]

Hi,

just to add my experience about this issue. I always need to remove and re-connect a Nodect to a Modect monitor link, if I do any change in the Modect settings (options and also zones). I always had this (small, but inconvenient) problem. As far as I remember, I never lost a link between Nodect to Modect if I don't change settings on Modect before. I'm quite new to Zoneminder (about 5 weeks) and only used 1.34.x and 1.36.x so far.

Frank

[tsp84]

I am working on a python script that will detect linked cameras and restart them at specified intervals. I have noticed that when the events stop working all you need to do is set the camera to any different function and then set it back to nodect or mocord or whatever and it works again. So restarting just the camera stream and process itself works. Easy enough to do via the API and the best i've come up with so far.

[fmeili1]

Just curious, do you plan to just disable/enable ALL monitors (usually nodect monitors) in a fixed interval, which have a link to others. Or is it possible to find out somehow "from the outside" if a current link is broken or not?

I've played around with the API and my guess is, that you plan to build a loop over all monitors (GET /zm/api/monitors/<monId>.json) and query the "LinkedMonitors" field in the result and if it's not NULL you will do a POST /zm/api/monitors/<monId>.json "Monitor[Enabled]=0" to disable it. After a second or so, you will enable them again?! How long would you wait before enabling again ? Do you know something which may be also considered for such a workaround. I want to try to implement that in a small bash loop with cur and awk to implement that via cron in my dockerhost to run it via docker exec...

[fmeili1]

Just want to share you my cronjob to automatically disable/enable all monitors which have a link, every hour (using bash, curl and jq):

0 * * * * docker exec -i zoneminder bin/bash -c echo $(maxMon=$(curl -s http://<zonemidnerHost>:<port>/zm/api/monitors.json | jq '.monitors | length'); monId=1; while [ $monId -le $maxMon ]; do a=$(curl -s http://<zonemidnerHost>:<port>/zm/api/monitors/$monId.json | jq '.monitor.Monitor.LinkedMonitors'); if [[ $a != null ]]; then curl -s -XPOST http://<zonemidnerHost>:<port>/zm/api/monitors/$monId.json -d Monitor[Enabled]=0; curl -s -XPOST http://<zonemidnerHost>:<port>/zm/api/monitors/$monId.json -d Monitor[Enabled]=1; fi; ((monId += 1)); done)

This workaround helped in my situation, maybe others may find it useful.

[burger]

One option to avoid all of this, is to simply record (passthrough) on the high res stream, and mocord on the low res stream. This is what I do, and I haven't had any trouble.

[fmeili1]

I'm not sure if I understand you right. So you don't use any links between monitors at all?

I've learned, that a common use case is to choose "Modect" on the low res stream and "Nodect" on the high res stream and create alink from the high res to the low res monitor to not waste too much disk space with unnecessary recordings.

[tortho]

I'm not sure if I understand you right. So you don't use any links between monitors at all?

I've learned, that a common use case is to choose "Modect" on the low res stream and "Nodect" on the high res stream and create alink from the high res to the low res monitor to not waste too much disk space with unnecessary recordings.

Yes, this is what I have done. (I have a link and modect/nodect as you describe)
Sometimes the high res do not record when the low res have detected an alarm.
...and sometimes it is all okay.

Assume the other comment about some restarts now and then might solve it.. but should be fixed to ensure it is always working

[burger]

Not sure why Tortho ninja'd the response, but in any case...
EDIT: I see now, he is confused by a similarly named post he made...

I'm not sure if I understand you right. So you don't use any links between monitors at all?
...
not waste too much disk space with unnecessary recordings.

That's correct. No links, no linked camera problems / easier to configure. Sounds simple, huh?

There are two (3) reasons why not to use linked monitors:

1) Modect/nodect doesn't always detect events (main reason).
2) HDD space is not that expensive (use passthrough though)
3) Linked monitors can sometimes not work

[jsylvia007]

That's correct. No links, no linked camera problems / easier to configure. Sounds simple, huh?

There are two (3) reasons why not to use linked monitors:

1) Modect/nodect doesn't always detect events (main reason).
2) HDD space is not that expensive (use passthrough though)
3) Linked monitors can sometimes not work

So i've thought about converting my setup to this, and storage space isn't a concern at all. Question though... Is there a "simple" way to look at the triggered event on the lo-res, and go to that "timeframe" across another monitor (even if it's ALL the monitors), or is there still a bunch of manual seeking involved?

[burger]

So i've thought about converting my setup to this, and storage space isn't a concern at all. Question though... Is there a "simple" way to look at the triggered event on the lo-res, and go to that "timeframe" across another monitor (even if it's ALL the monitors), or is there still a bunch of manual seeking involved?

Show Timeline on the low res (https://wiki.zoneminder.com/How_to_view ... w_timeline) and then once you know what date/time the event occurs, navigate to that time on the hi res monitor. Shouldn't take too long.

[lk777]

Upgrading my LXD container storage (ZM is installed in the LXD container) to SSD I believe resolved modect/nodect issues. I have not experienced any linked monitors related issues lately.

[tsp84]

Just curious, do you plan to just disable/enable ALL monitors (usually nodect monitors) in a fixed interval, which have a link to others. Or is it possible to find out somehow "from the outside" if a current link is broken or not?

I've played around with the API and my guess is, that you plan to build a loop over all monitors (GET /zm/api/monitors/<monId>.json) and query the "LinkedMonitors" field in the result and if it's not NULL you will do a POST /zm/api/monitors/<monId>.json "Monitor[Enabled]=0" to disable it. After a second or so, you will enable them again?! How long would you wait before enabling again ? Do you know something which may be also considered for such a workaround. I want to try to implement that in a small bash loop with cur and awk to implement that via cron in my dockerhost to run it via docker exec...

https://github.com/baudneo/zmeventnotif ... d_reset.py

[Last_Mile]

I know this is a late response, but I spent a better part of the day figuring out what was going on and fixing it for the time being. One day, with no changes one monitor decided it won't go into alarm via a linked monitor. Prior to this it was working for months.

I have two streams coming from my camera a HD and SD. The SD stream is linked to the HD camera and triggers an alarm. One day a single camera out of the 12 I have decided not to trigger an alarm.

I did all the tricks listed in this thread.
Restart zoneminder.
Shutdown and startup zoneminder server.
Set HD monitor to None, then back to Nodect.
Set SD monitor to None, then back to Mocord.
Manually trigger alarm on SD monitor. This worked and the HD monitor triggered an alarm and sent me an email!
Manually trigger alarm on the HD monitor. This also worked!
In the HD monitor I also set the link to a different SD monitor. This worked! A different monitor is able to trigger the HD monitor to alarm.
Changed the HD monitor source to a different RTSP address stream. This worked. When the SD monitor triggered an alarm, the HD monitor from a different source triggered!

At this point I figured there was an issue with the SD stream triggering an alarm on the HD stream of the same camera. I was on my way to completely delete the HD monitor and provisioning a new HD monitor with the same parameters. Then, I saw the clone option. I did a clone of the HD monitor and deleted the old HD monitor.

It worked, everything is fixed and works just as it has been working for the past 3 months.