motion detect (mocord) doesn't do what I expect

eddyhkim · Post by **eddyhkim** » Fri Jun 02, 2006 6:24 pm

I'm playing around with my newly running zm system (Yay!), but have a problem.

When I look at the event window, the continuous-cause records too much, while the motion-cause doesn't record enough.

From what I've gleaned on the forums, mocord should do what i'm looking for.

I've played around with the pre and post event image buffer in the monitor editing dialog, but it doesn't make a discernable difference for me. I'm I going in the right direction?

BTW, so far I'm very impressed with the quality and function of the package. Great job!!! As soon as I feel more comfortable with how everything works, I'd like to help with the documentation and hope to start work on POS integration asap.

zm 1.22 on ubuntu 5.10

jameswilson · Post by **jameswilson** » Fri Jun 02, 2006 7:11 pm

id join the POS group too!
Re your setttings
Mocord is record with motion detection so you can search for motion. I personally mainly use record or mocord. If record was too much then mocord will be just as bad. Unfortunatly pre events on mocord dont make any difference as it was already dropping images to disk. It does work in modect though as thats not recording all the time. The easist way to explain modect is as a list of images eg

1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20

if you have a pre and post event count of 5 and motion was detected at image 10, zm will drop to disk 5 iumages before 10, all the frames that were in alarm eg 10, 11 and 12 and then another 5 so up to 17. Then it will end the event. If you want the event to last longer, ie to prevent lotys of little alarms extend the post event count, then it wiill take longer to close the event and subsequent alarms will be added to the current alarm + 5 frames.

If you extend the pre alarm then this wont help in the above situation as the event would already be deemed to have ended and so a new event would be raised. Pre alarm is used for where did they/it come from, and the longer you need in frames the more memory you will need as these images are held in ram.

Hope that explains it

James

eddyhkim · Post by **eddyhkim** » Fri Jun 02, 2006 8:51 pm

Thanks James, that clears it up. I think I'm slowly getting some understanding here.

Cheers,
Ed

jameswilson · Post by **jameswilson** » Fri Jun 02, 2006 9:41 pm

Its a hell of an app mate takes a few months to get to grips with all of whats its caperble of. I think in about 6 more months ill have grasped most of it!!

Cheers

James

eddyhkim · Post by **eddyhkim** » Sat Jun 03, 2006 2:43 am

do you have any tips on where to start? anything that isn't obvious, but if you had known, would have helped you understand the architecture and processes more quickly? I haven't started down this road yet, as I'm still try to grasp it from the user side.

Unless there are any objections, I'll make notes of how everything goes together from a technical standpoint and maybe that could be the basis of a developers manual or reference. perhaps it would make it easier for people who want to contribute to get up to speed more quickly.. I did similar work for a couple of companies when I used to get paid for programming

Ed

jameswilson · Post by **jameswilson** » Sat Jun 03, 2006 11:15 am

I did similar work for a couple of companies when I used to get paid for programming

Lol what PAID ACTUAL MONEY WOW!!

Feel free to document and it will definetly help others and maybe me!!

HOw i got started was to turn outline motion on and stats on to see what was happening. Always use blobs, and use the defaults, then adjust the min alarm rates to increase the sens, but thats as far as ive got mate and its by no means perfect. Im looking into (with Phils help) making a walk test mode so we can make a change and with in a couple of seconds see the result ie nearly an alarm, so you can see thresholds etc. But its only just at the idea stage in my head at the moment!