Well thats good new and bad news
I may have to send you a further debug patch so we can figure out what is going on. If you want to play yourself then you just need to find the zmaudit.pl file. If you find the installed one, probably in /usr/local/bin, then you can play with it and have it take effect immediately without worrying about a reinstall, though if you do a reinstall for any other reason it will be overwritten. Actually you will need to restart ZM or kill the running zmaudit.pl process for it to be restarted before your changes are effective.
If you edit zmaudit.pl you should find the 300 value clearly defined not too far from the top (under the BEGIN block).
Phil
Axis cameras on time lapse with dropped events
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Thanks Phil
I guess I will play a little with the 300 second time for now.
On a similiar note, with the great work Ross is doing too with his RPM to upgrade LiveCD 1.19.5 to 1.21.0, do you think doing an upgrade would be better to this setup before continuing the debug or could we remain at current?
Regards!
I guess I will play a little with the 300 second time for now.
I would definitely like to try to get rid of this problem (of course that is only if you feel its worth it to debug, it is not my intention to become a headache for you).I may have to send you a further debug patch
On a similiar note, with the great work Ross is doing too with his RPM to upgrade LiveCD 1.19.5 to 1.21.0, do you think doing an upgrade would be better to this setup before continuing the debug or could we remain at current?
Regards!
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Hi all
I post this as an update and final fix (at least for me) on this problem. Sorry for the time it took, but I had to be sure it worked.
Phil released a zmaudit patch for my version 1.19.5 and I believe has included this fix on all subsecuent releases. Zmaudit is the program responsible for physically deleting events from the hard drive. The patch Phil made basically tells zmaudit to NOT delete any event younger than a certain amount of seconds.
Phil set this default time frame to 300 seconds in zmaudit.pl on the following line:
As I originally stated, my setup is running nineteen Axis cameras capturing one jpg every ten seconds for 10 minute lapses.
Somewhere along the way, the MIN_AGE of 300 seconds did render a positive result upon most events not being dropped off but still some were being deleted. This happend too, added to the fact that I presume zmaudit does not run every five minutes on the hour (as events do starting and ending every 10 minutes on the hour) which led me to believe that zmaudit is triggered every 300 seconds depending on the first time it was initiated (after a restart of the system or restart from the console).
The final fix I came upon was setting MIN_AGE to 900 seconds. I figured that this was enough time for the time lapse events being created every 600 seconds to not get deleted by the "nervous" zmaudit, and it did, events do not disappear anyomore!
Finally on another post I read that lazyleopard (I guess using modect) on its cameras found that zmaudit was deleting them upon being created much in the way my time lapse ones were. Obviously cameras setup on modect that had dropped events were harder to catch, because of the nature of modect, where perhaps, no one had noticed before that either the event never got created or sometimes got the ax.
I think that the default Phil set on MIN_AGE of 300 seconds does the job for modect and most setups unless perhaps if these events run long and not get enough time to gracefully end and close before zmaudit does its pass.
If for any reason someone finds out to have dropped events, of course first check de logs to see if these are being deleted by zmaudit, then you can fiddle with this MIN_AGE seconds and find out, like I did, to do the trick.
Regards!
I post this as an update and final fix (at least for me) on this problem. Sorry for the time it took, but I had to be sure it worked.
Phil released a zmaudit patch for my version 1.19.5 and I believe has included this fix on all subsecuent releases. Zmaudit is the program responsible for physically deleting events from the hard drive. The patch Phil made basically tells zmaudit to NOT delete any event younger than a certain amount of seconds.
Phil set this default time frame to 300 seconds in zmaudit.pl on the following line:
Code: Select all
use constant MIN_AGE => 300; # Minimum age when we will delete anything
Somewhere along the way, the MIN_AGE of 300 seconds did render a positive result upon most events not being dropped off but still some were being deleted. This happend too, added to the fact that I presume zmaudit does not run every five minutes on the hour (as events do starting and ending every 10 minutes on the hour) which led me to believe that zmaudit is triggered every 300 seconds depending on the first time it was initiated (after a restart of the system or restart from the console).
The final fix I came upon was setting MIN_AGE to 900 seconds. I figured that this was enough time for the time lapse events being created every 600 seconds to not get deleted by the "nervous" zmaudit, and it did, events do not disappear anyomore!
Finally on another post I read that lazyleopard (I guess using modect) on its cameras found that zmaudit was deleting them upon being created much in the way my time lapse ones were. Obviously cameras setup on modect that had dropped events were harder to catch, because of the nature of modect, where perhaps, no one had noticed before that either the event never got created or sometimes got the ax.
I think that the default Phil set on MIN_AGE of 300 seconds does the job for modect and most setups unless perhaps if these events run long and not get enough time to gracefully end and close before zmaudit does its pass.
If for any reason someone finds out to have dropped events, of course first check de logs to see if these are being deleted by zmaudit, then you can fiddle with this MIN_AGE seconds and find out, like I did, to do the trick.
Regards!
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Thanks for the extensive report. I'm still not 100% sure there isn't something else hidden away that might be causing a problem but if setting the min age to 900 works for you then that's really good, it's not like it an extra 10 minutes worth of events is likely to overwhelm your system either.
Phil
Phil