capturing fails, zoneminder does not restart zmc

[rpdrewes]

Hello,

For years I have had situations where a monitor will stop capturing in Zoneminder: when I click on the monitor, I get a white area where the image should be. For reliability and other reasons, all of my monitors are configured to capture individual still images via url to the camara (something like http://192.168.1.115:88/cgi-bin/CGIProx ... d=sekritpw). Though such a camera is not working in Zoneminder any longer, if I bring up that url in my web browser, the camera responds. I think this problem usually occurs when there is some transient communication problem, for example a router is rebooted or something like that.

If I manually kill the zmc process, Zoneminder restarts it and then I can view the monitor fine again in Zoneminder.

If I do a restart of Zoneminder (through the web interface or at operating system level) that of course fixes the problem too.

If I examine the zmc process of a camera in this nonfunctional state, zmc is just in a select() for a while until that times out, and then another select(), continuously.

This arrangement seems very fragile. If communication to a camera is disrupted in a certain way, then Zoneminder just stops getting data and never realizes it and never recovers even when the camera becomes available. Of course we would like to never have any communication problems, but this is not realistic.

The option WATCH_MAX_DELAY seems like it could help, but the zmc process isn't actually hung; the selects keep timing out. The zmc process isn't hung as far as Zoneminder is concerned, it seems, and therefore zmc is never restarted by Zoneminder

What is the best way to deal with monitors that stop capturing and do not ever recover, even though the camera becomes available? I'm on Zoneminder v1.30.4 but I've had this problem over many years on multiple versions.

The related post viewtopic.php?t=26226 does not seem to have a good answer, except perhaps the idea of an external script that looks for events and then manually restarts things.

Thanks

[snake]

This appears to be a foscam only problem. Possibly setting the camera to modect or nodect is better than record, or mocord. Thinking about this again, perhaps setting a call to the API in the zmdc.pl will be a better approach than an external script. All you want to do is restart the camera. Either through zmdc.pl if possible, or API, or whatever is available.

[iconnor]

I've seen this problem and have been working on it for years. I am hoping that 1.32.3 may finally have a fix that allows ZM to recover.

In the meantime, you might try using the ffmpeg monitor type as input.

[rpdrewes]

Thanks for your replies, snake and iconnor.

iconnor: I just upgraded from 1.30 to 1.32 (using your ppa--thanks for your work!) so I should have some data soon on whether the issue is fixed. So far my attempts to artificially induce the error have not caused the problem. The system recovers nicely. But the problem wasn't completely reproducible in the past so I'm hopeful but not certain the problem is gone.

snake: I don't think this is specifically a Foscam problem, I think it is a case where Zoneminder would not recover from a transient network (or other) error condition. It may be the case that Foscams will experience more transient network errors than some other high-end cameras (because of poor wifi or general reliability issues), but all networks and cameras could experience reboots or network outages and the system should recover without manual intervention whenever the camera is reachable again (I think). When Zoneminder is no longer showing anything on the monitor screen, the camera is alive and responding (as I can verify by loading in image from it in my web browser). In this state, restarting zmc fixes the situation. Restarting the camera doesn't. The zmc process is just repeatedly doing select() and timing out. If zmc would simply realize that there is no data coming in and exit, or attempt to reopen a connection to the camera, the system would recover. But it didn't, at least on version 1.30.

thanks,
Rich

[rpdrewes]

So far in testing it seems that 1.32 is much better at recovering from transient problems. I have observed situations in 1.32 where the monitor turns red for a short time and no images are visible in Zoneminder, and then a few seconds later it comes back online. I am fairly confident that in the past the monitor would not have recovered. So far on 1.32 I have not seen any cases where a monitor would get into an error state and not recover on its own.

[earlymeadow]

rpdrewes: Could you tell me if updating to 1.32 solved your problems.