ZoneMinder / zmNinja

High performance, cross platform ionic app for Home/Commerical Security Surveillance using ZoneMinder

Home Page:http://zmninja.zoneminder.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Monitors not updating in zmNinja after RUN state change.

opened this issue · comments

The version of zmNinja you are reporting:

1.6.007 Android

The version and OS of ZoneMinder you are using:

1.35.16, Ubuntu 20.04 LXC 

Platform zmNinja is running on

Android 11 - Samsung Note 10+ North American Model

Did you build the package from source code yourself?
No, I downloaded from Playstore

Describe the bug
I have a script on ZM host that changes RUN states from Day to Night or some other state. When these states change ZMNinja does not pick up on them. My Montage view is confused, for example, If I have Front, Back Alley (Night), and Back Yard (Night) monitors set up and working correctly and the state changes, The montage view automatically hides monitors it 'thinks' aren't active.

This is hard to explain and there are no errors to report. I have made a forum post about it and there is also a youtube video showing what I mean.

Forum post describing errors (with video and pictures) --> Here

I know you replied in that post but I thought it more appropriate to open an issue as this is a major part of the functionality to me and the Wife Approval Factor is not being given because of this little issue.

Debug logs

No logs or errors to give for this issue, sorry.

Screenshots
Here is the video. (I think you've already seen this but just adding it for context).

In this screenshot you can see how Back Yard (Day) and Back Alley (Day) are set to NONE but there is clearly a stream incoming, Also notice how the (Night) monitors are set to MODECT with no stream incoming. This means zmNinja hides the (Day) monitors from view.

zmninja_monitors_bug

Additional context
Only way I have found to get things working properly are to go to "Settings" and hit the "SAVE" button in top right corner. It then says "Please explore the menu and enjoy zmNinja". This causes zmNinja to reload the monitors and correctly identify active streams to show, a small inconvenience for technically adept people but a breaking nuisance for non-techies.

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you follow the issue template or I may not respond.

Yup this is a known issue https://forums.zoneminder.com/viewtopic.php?f=33&t=30422
I'll get to this soon.

Let's talk about this a bit:

  1. Let's suppose ZM is in state "run1". In zmNinja, you are viewing montage and disable 3 monitors.
  2. Now ZM changes state to "run2". How should zmNinja treat the disabled 3 monitors?
  3. How should zmNinja montage profiles (which have their own local definitions of enabled/disabled monitors) play with run states?

Without knowing the mechanisms of how it all works I can't say specifically. I have some local montage views set up as Night and Day but I still need to go to settings and click "Save" for the monitor list to be updated with proper monitor modes.

I would possibly either have a function reset the monitor modes and reread them everytime zmninja is opened or have a daemon on server that senses run state changes/monitor mode changes and updates zmNinja over websocket.

The local montage run states I haven't played with much. I would assume that if you set monitors to disabled from zmNinja and the run state changes on the server, reenabling 1 or 2 of the 3 you disabled, the server should take precedence? Meaning that the same thing that happens if you are using zm webgui and changing monitors then a run state change happens.

Example: my run state is set to Day and it's almost the time it turns to Night. I have changed some monitors to random modes manually but have not saved it to any runstate. When the Cron job script turns the run state to Night the monitors are set to whatever they are for the Night run state. Meaning whatever you set those monitors to manually is changed/forgotten. This is my understanding of expected behaviour.

The local montage view can do what it does now and just show a grey background with 3 green dots if the stream isn't being offered by the servers current run state/monitor mode.

I hope I'm making sense? I just don't see the issue with the local montage saved views if the run state is being monitored and updated.

Well that was a terribly formatted response. Let me try again.

  1. I would have the server take precedence in what happens. If the server run state changes in webgui after you've changed monitor modes, the manual changes are not considered and the monitor modes are set to whatever they are for that specific run state.

  2. From my point of view these should act the way they are now.

Here is a screenshot showing my local zmninja montage view of Night while run state is set to Day and zmninja hasn't updated the monitor modes yet so it's still showing the incorrect Night streams but it's a grey background with 3 green dots.
Screenshot_20210307-100930_zmNinja

And here is a screenshot of the local zmninja montage view set to Day when the run state is set to Day and zmninja hasn't updated the monitor modes so it hides the Day streams from montage view.
Screenshot_20210307-101256_zmNinja

As far as I can tell zmninja just needs a way to monitor the mode changes per monitor and apply them if it's changed server side and also sync run state changes in regards to monitor modes (it displays proper "current run state" in "system status" but doesn't update monitor mode).
Idk if a pre check function can be added everytime zmninja is opened or regains main focus that checks which monitors are set to what and update that locally. I have very basic programming knowledge but I am trying to attempt to learn python, Perl, and JavaScript.

Edit: Could also possibly have an option to just show all monitors on montage/events view regardless of if zmninja thinks they are active or not? Might get ugly for events viewing though. Deff would be wacky behavior because you would see events for monitors that are disabled, maybe that can be another option, see all events instead of active monitor events on events list?

Sorry if my ideas seem outlandish, I am unaware of the limitations of each language. I am however actively looking at your source files and walking through them trying to understand and maybe help if at all possible.

Here is a screenshot of the montage "eye" list after screenshot of local montage Day view. Monitor modes not updated. Can only update them by going to "Settings" and clicking "Save" so you get the "Welcome to zmninja, please explore the menus" prompt. Then it polls and updates the monitor modes.
Screenshot_20210307-104958_zmNinja

Would it be possible to run the function that is linked to the "Save" button or a stripped down version that only polls and updates monitor modes? Possibly during opening, reopening or zmninja becoming the main focus? Also maybe a timedjob that will do it if you have your phone set to "keep awake while viewing montage" and the montage opened for awhile, say polls every minute while keeping screen alive?

I would think the secure websocket would be ideal for this because then you don't have to poll, zmninja would just be listening for anytime the server sends a monitor mode change? Or a combo of websocket and a timed job that polls just to make sure there's a 2nd mechanism to fallback if websocket has issues?

I dont know for certain these are all just ideas flowing.

I've noticed that it seems the montage view has its own list it uses instead of using whatever zm sends. For example, in my above screenshots the monitors that are active have a small image showing the stream is active BUT the mode is set to NONE, so zmNinja hides the stream. If you then go to the Monitors menu you can see that all of the monitors are showing the correct data from zm API.
This leads me to believe that the montage/events uses its own list to decide what to show and it isn't updated by the zm API returns. Would you be able to hook the montage list into the monitors list? Or maybe have an option to disable the automatically show/hide streams logic and add filters so the user can decide what to show?

Yup that’s the complexity. ZmNinja has its own concept of groups and I need to figure out a clean solution. I need to think about it - I won’t be able to get to this immediately.

I have a version for you to test (desktop). What will happen is while zmNinja is running, it will not reflect the change. But if the run state changes and you restart zmNinja, it should show the monitors. Let me know which desktop version you can test, so I can upload a version.

linux x64

Please give this a try https://drive.google.com/file/d/1Ahkpcg-DKOJaKi_QXPDAq_9hMk_TFLDD/view?usp=sharing
You'll have to restart zmN after runstate changes

There doesnt seem to be any change in behavior. I waited until it switched from day to night and the grey BG with 3 green dots appeared, closed zmNinja and then reopened it and tried to see my night streams. It shows a stream but its mode is set wrong still.
Screenshot from 2021-04-03 20-32-11
Screenshot from 2021-04-03 20-31-49

I'd like to see logs for the following:

  1. Set ZM to day
  2. Load zmN, don't do anything. Just save logs.
  3. Quit zmN
  4. Change ZM to night
  5. Load zmN, don't do anything, just save logs.

I'd like to see both logs. Specifically, I'm looking for text that says "ZM Changed state from" in step 5. Please post full logs for both runs.

Okay, please hold on. My API cache was off. Will ping when fixed.

This newest version works as described. After restarting desktop app it loads the correct Night/Day monitors in montage

Okay, closing this. There is no way for me to know when a run state changes, unless I keep polling on a timed basis, which I don't want to do. So for now, restart the client it is.