ZoneMinder Forums

Any further updates on this?

Also, I find myself wishing our cams were identical (and that I still had one for experimentation)... I'd been unable to locate the root password for mine.

Interesting... The initial issue was under 1.30... If you're running 1.32 now, and you have the choice in the camera itself between NTSC and PAL, you could give that a shot. I've found some cameras don't like to respond to ONVIF probes from within ZM unless they're set to PAL. It may also be that ...

Any update on this issue?

-dws

Any update on this?

-dws

There is no link bewen zoneminder auth and the credentials used in onvif probing. This issue is more complex than you think. There is a correlation between changing the ONVIF credentials when adding a camera and the user then being able to view any camera from within zoneminder after a camera is ...

Ahhhhh.... now I understand. this should not be the case...did you submit a bug report? I always create new user like "justlook" that only has permissions to view streams which has a different password than the cameras and the admin of the zoneminder system. I will try to get what you describe to ...

Hashed logins isn't turned on on my setup, so, no... that's not the case... The auth to access the camera streams should be separate from the auth to login to ZoneMinder, is my point. This behavior indicates that the camera access auth after ONVIF probe is tied to ZM login credentials, and, IMHO ...

When adding a camera to ZM, if the camera's username and password differs from the username used to login to ZM, and if you put that login information in the ONVIF probe window, after the camera is added, NO video streams are unable to be viewed by the user logged in until they log out of ZM and ...

Bump

Actually after looking at the code, any capture failure should trigger the end of an event. Will have to investigate further. Agreed... But any time a camera reboots/is powered off/etc, I believe a signal event should be generated, so the timing can be inspected on the reviews. This way, if a cam ...

Bumping the thread, in case @iconnor or someone on the dev team hasn't seen it yet...

Please... could really use an answer to this one...

I've seen no "blue screen" events at all... Increasing or decreasing sample framerate has zero effect on the appearance of blue screen events, and no "signal" events are ever generated.

I'd like to get the "signal" events back.

I'm wondering if there's a way to force this behavior in 1.32 without the CPU going ballistic. I can also partially answer this question, in 1.30 if you set the maximum fps to a little higher than the camera's fps, you could limit how fast it tried to process that blue screen (otherwise it sends as ...

Anyone? How do I turn the "signal" events back on?