Ok, I have an interesting situation. Using modetect function, the monitor is idling without any problems, but then it jumps into alert state when there's motion. Now, i presume that it goes into alarm state first, and I'm just not seeing this (I'm yet to confirm this though).
The problem lies in that it stays in
alert state 'forever'. I have only tested it for about 30mins, but that's more than long enough to determine that it's not working as it should. I have my post frame buffer set to 10, on a 25fps camera, so it shoudln't be going for 30mins. It's not a refreshing problem, as I manually reload the page and it stills says
alert state. The event pops up and has an unknown event with a time (Secs) of 0. If I then change the function of the monitor to anythign else, it goes to idle and the secs are calculated.
It seems the problem is changing back from alert to idle even though the motion has stopped. Any ideas?
Another interesting thing is, that sometimes on longer recordings it miscalculates the duration. It has happened twice now, the current one I tested (30mins) shows: 14485494.04 secs duration, which is obviously incorrect, as it equates to something like 4000 hours. The frames seem to be correct, showing just under 9000 for 30mins. If I click on frames to get a complete frame listing, I get some interesting information - the pre-buffer is clearly working, as it shows 10 frames without motion.... now here's the problem. The rest of the frames are still showing motion.. even when it should have stopped. The wierdest part is the last 4 frames though - and remembering this has happened twice now:
Code: Select all
8984 Yes 11:48:36 1,713.74 55
8985 Yes 11:48:36 1,713.90 56
8986 Yes 11:48:36 1,714.05 57
8987 Yes 11:48:37 1,714.18 56
8988 Yes 10:00:00 9,999,999.99 68
8989 Yes 10:00:00 9,999,999.99 68
8990 Yes 10:00:00 9,999,999.99 66
8991 Yes 10:00:00 9,999,999.99 66
You can clearly see that there is a problem with those last four, especially as the time is registering as 10am... the rest of the frames all seem to be correct in regards to time etc, with the exception of the fact that they're all detecting motion with a score of ~50.
------------
Ok, well I have worked out the first issue of the motion continuing for ever. I took a look at the stills again and noticed that it's motion outside int the inclusive zone that is causing it. I have the window as inclusive and the rest of the room as active. I'll have to look into how I can get it stop, when motion in the rest of the room has stopped - I'm with a combination of zones, this is possible.
As for the last four frames, I have a little more info on that too. The last four frames are pitch black, but they still show the motion on certain areas such as the outline of posters on the wall. This is probably related to me having to manually change the function while it's in an alert state - although technically, shouldn't it be in alarm state if there is still motion?
I have one final problem, the email sending and FTP uploading aren't working. Once again this could be related to the same issue. The event is generated, the filters match the event (I run them manually afterwards), they're saved and checked, the options are set to send email and upload. So that's not the problem. I think it must be related to me manually forcing the function change. I'll set the inclusive zone to inactive and see if that fixes that problem.
I shall keep you updated, but if you have any ideas, that'd be great - the last four frame issue is still very odd, esp. with the time changing to 10:00.
