Provided by: zoneminder_1.32.3-2_amd64 bug

NAME

       zoneminder - ZoneMinder Documentation

USER GUIDE

   Introduction
       Welcome to ZoneMinder, the all-in-one security camera solution for Linux with GPL License.

       Commercial  “security  systems”  are  often  designed  as  a monitoring system with little
       attention to recording quality. In such a system, locating and  exporting  relevant  video
       can  be  challenging  and  often  requires  extensive  human  intervention. ZoneMinder was
       designed to provide the best  possible  record  quality  while  allowing  easy  searching,
       filtering and exporting of security footage.

       ZoneMinder  is  designed around a series of independent components that only function when
       necessary, limiting any wasted resource and maximising the efficiency of your machine.  An
       outdated Pentium II PC can have multiple recording devices connected to it, and it is able
       to track one camera per device at up to 25 frames per second, which drops by approximately
       half  for each additional camera on the same device. Additional cameras on devices that do
       not interact with other devices can maintain the 25  frame  rate  per  second.  Monitoring
       several  cameras  will not overload the CPU as frame processing is designed to synchronise
       with capture.

       A fast video interface core, a user-friendly and comprehensive  PHP  based  web  interface
       allows  ZoneMinder  to be efficient, friendly and most importantly useful. You can control
       and monitor your cameras from home, at work, on the road, or a web-enabled cell phone.  It
       supports  variable  web  capabilities based on available bandwidth. The web interface also
       allows you to view events that your cameras have captured, which can be archived, reviewed
       or  deleted.  The  web  application directly interacts with the core daemons ensuring full
       co-operation at all times. ZoneMinder can also be installed as a system service to  reboot
       a system remotely.

       The core of ZoneMinder is the capture and analysis of images and a highly configurable set
       of parameters that eliminate false positives whilst ensuring minimum loss of footage.  For
       example,  you  can  define  a  set  of  ‘zones’ for each camera of varying sensitivity and
       functionality. This eliminates zones that you don’t wish to track  or  define  areas  that
       will alarm if various thresholds are exceeded in conjunction with other zones.

       ZoneMinder  is free under GPL License, but if you do find it useful, then please feel free
       to visit http://www.zoneminder.com/donate.html and help us fund our future improvements.

   Components
       ZoneMinder is not a single monolithic application but is formed from  several  components.
       These  components  primarily  include executable compiled binaries which do the main video
       processing work, perl scripts which usually perform helper and/or external interface tasks
       and php web scripts which are used for the web interface.

   System Overview
       Depicted  below  is  a  high  level  diagram  of the ZoneMinder system with key components
       [image]

       A brief description of each of the principle components follows.

   Binaries
       zmc    This is the ZoneMinder Capture daemon. This binary’s job  is  to  sit  on  a  video
              device and suck frames off it as fast as possible, this should  run at more or less
              constant speed.

       zma    This is the ZoneMinder Analysis daemon. This is the component that goes through the
              captured  frames and checks them for motion which might generate an alarm or event.
              It generally keeps up with the Capture daemon but if very busy may skip some frames
              to prevent it falling behind.

       zmf    This  is  the  ZoneMinder  Frame daemon. This is an optional daemon that can run in
              concert with the Analysis daemon  and  whose  function  it  is  to  actually  write
              captured  frames to disk. This frees up the Analysis daemon to do more analysis (!)
              and so keep up with the Capture daemon better. If it isn’t running or dies then the
              Analysis daemon just writes them itself.

       zms    This  is  the  ZoneMinder Streaming server. The web interface connects with this to
              get real-time or historical streamed images. It  runs  only  when  a  live  monitor
              stream or event stream is actually being viewed and dies when the event finishes or
              the associate web page is closed. If  you  find  you  have  several  zms  processes
              running  when nothing is being viewed then it is likely you need a patch for apache
              (see the Troubleshooting section). A  non-parsed  header  version  of  zms,  called
              nph-zms,  is  also  installed  and may be used instead depending on your web server
              configuration.

       zmu    This is the ZoneMinder Utility. It’s basically a handy command  line  interface  to
              several useful functions. It’s not really meant to be used by anyone except the web
              page (there’s only limited ‘help’ in it so far) but can be if necessary, especially
              for debugging video problems.

   PHP
       As  well as this there are the web PHP files in the web directory. Currently these consist
       of a single skin with Classic and Flat styles.

       Classic
              Original ZoneMinder skin

       Flat   An updated version of Classic skin, retaining the same layout with  a  more  modern
              style. Originally a skin this is now just a CSS style.

   Perl
       Finally  some  perl  scripts  in  the  scripts  directory.  These  scripts  all  have some
       configuration at the top of the files which should be viewed and amended if necessary  and
       are as follows.

       zmpkg.pl
              This  is  the  ZoneMinder Package Control script. This is used by the web interface
              and service scripts to control the execution of the system as a whole.

       zmdc.pl
              This is the ZoneMinder Daemon Control script. This is used by the web interface and
              the  zmpkg.pl  script  to  control  and  maintain  the execution of the capture and
              analysis daemons, amongst others. You should not need to run this script yourself.

       zmfilter.pl
              This script controls the execution of saved filters and will be started and stopped
              by  the  web interface based on whether there are filters that have been defined to
              be autonomous. This script is also  responsible  for  the  automatic  uploading  of
              events to a 3rd party server.

       zmaudit.pl
              This script is used to check the consistency of the event file system and database.
              It can delete orphaned events, i.e. ones that appear in one location  and  not  the
              other as well as checking that all the various event related tables are in line. It
              can be run interactively or in batch mode either from the command line  or  a  cron
              job or similar. In the zmconfig.pl there is an option to specify fast event deletes
              where the web interface only deletes the event entry from the database  itself.  If
              this is set then it is this script that tidies up the rest.

       zmwatch.pl
              This  is  a simple script purely designed to keep an eye on the capture daemons and
              restart them if they lockup. It has been known  for  sync  problems  in  the  video
              drivers to cause this so this script makes sure that nothing important gets missed.

       zmupdate.pl
              Currently  this  script  is  responsible  for  checking  whether  a  new version of
              ZoneMinder is available and other miscellaneous actions  related  to  upgrades  and
              migrations.  It  is also intended to be a ‘one stop shop’ for any upgrades and will
              execute everything necessary to update your installation to a new version.

       zmvideo.pl
              This script is used from the web interface  to  generate  video  files  in  various
              formats  in  a  common  way.  You  can also use it from the command line in certain
              circumstances but this is not usually necessary.

       zmx10.pl
              This is an optional script that can be  used  to  initiate  and  monitor  X10  Home
              Automation style events and interface with an alarm system either by the generation
              of X10 signals on ZoneMinder events or  by  initiating  ZoneMinder  monitoring  and
              capture on receipt of X10 signals from elsewhere, for instance the triggering of an
              X10 PIR. For example I have several cameras that don’t do motion detection until  I
              arm  my  alarm  system  whereupon  they switch to active mode when an X10 signal is
              generated by the alarm system and received by ZoneMinder.

       zmtrigger.pl
              This is an optional script that is a more generic solution to  external  triggering
              of  alarms.  It  can  handle  external connections via either internet socket, unix
              socket or file/device interfaces. You  can  either  use  it  ‘as  is’  if  you  can
              interface  with  the  existing  format,  or  override  connections  and channels to
              customise it to your needs. The format of  triggers  used  by  zmtrigger.pl  is  as
              follows “<id>|<action>|<score>|<cause>|<text>|<showtext>” where

              · ‘id’ is the id number or name of the ZM monitor.

              · ‘action’  is ‘on’, ‘off’, ‘cancel’ or ‘show’ where ‘on’ forces an alarm condition
                on, ‘off’ forces an alarm condition off and ‘cancel’ negates the previous ‘on’ or
                ‘off’.  The ‘show’ action merely updates some auxiliary text which can optionally
                be displayed in the images captured by the monitor. Ordinarily you would use ‘on’
                and  ‘cancel’,  ‘off’  would  tend  to  be  used to suppress motion based events.
                Additionally ‘on’ and ‘off’ can take an additional time offset, e.g. on+20  which
                automatically ‘cancel’s the previous action after that number of seconds.

              · ‘score’ is the score given to the alarm, usually to indicate it’s importance. For
                ‘on’ triggers it should be non-zero, otherwise it should be zero.

              · ‘cause’ is a 32 char max string indicating the reason for, or source of the alarm
                e.g. ‘Relay 1 open’. This is saved in the ‘Cause’ field of the event. Ignored for
                ‘off’ or ‘cancel’ messages.

              · ‘text’ is  a  256  char  max  additional  info  field,  which  is  saved  in  the
                ‘Description’ field of an event. Ignored for ‘off’ or ‘cancel’ messages.

              · ‘showtext’  is up to 32 characters of text that can be displayed in the timestamp
                that is added to images. The ‘show’  action  is  designed  to  update  this  text
                without  affecting  alarms  but  the  text is updated, if present, for any of the
                actions. This is designed to  allow  external  input  to  appear  on  the  images
                captured, for instance temperature or personnel identity etc.

              Note that multiple messages can be sent at once and should be LF or CRLF delimited.
              This script is not necessarily intended to be a solution in itself, but is intended
              to  be  used  as  ‘glue’  to  help ZoneMinder interface with other systems. It will
              almost certainly require some customisation before you can make any use of  it.  If
              all  you  want  to  do  is  generate  alarms  from  external sources then using the
              ZoneMinder::SharedMem perl module is likely to be easier.

       zmcamtool.pl
              This optional script is new for the upcoming 1.27  release  of  ZoneMinder.  It  is
              intended  to make it easy to do the following: bring in new ptz controls and camera
              presets, convert existing monitors into presets, and export custom ptz controls and
              presets.  For  the  initial  release, this script is not integrated into the UI and
              must be called from the command line.  Type ‘’zmcamtool.pl –help’’ from the command
              line to get an explanation of the different arguments one can pass to the script.

       zmcontrol-*.pl
              These are a set of example scripts which can be used to control Pan/Tilt/Zoom class
              cameras. Each script converts a set of standard parameters used for camera  control
              into  the  actual  protocol  commands sent to the camera. If you are using a camera
              control protocol that is not in the shipped list then you will  have  to  create  a
              similar  script  though  it  can be created entirely separately from ZoneMinder and
              does not need to named as these scripts are.  Although  the  scripts  are  used  to
              action commands originated from the web interface they can also be used directly or
              from other programs or scripts, for instance  to  implement  periodic  scanning  to
              different presets.

       zmtrack.pl
              This  script  is  used  to  manage  the experimental motion tracking feature. It is
              responsible for detecting that an alarm is taking place and moving  the  camera  to
              point  to  the  alarmed  location,  and then subsequently returning it to a defined
              standby location. As well as  moving  the  camera  it  also  controls  when  motion
              detection  is suspended and restored so that the action of the camera tracking does
              not trigger endless further alarms which are not justified.

       zm     This is the (optional) ZoneMinder init script, see below for details.

       Finally, there are also a number of ZoneMinder perl modules included. These  are  used  by
       the  scripts  above,  but  can  also  be  used  by  your  own  or  3rd party scripts. Full
       documentation for most modules is available in ‘pod’ form via ‘perldoc’  but  the  general
       purpose of each module is as follows.

       ZoneMinder.pm
              This  is  a general ZoneMinder container module. It includes the Base.pm, Config.pm
              Debug.pm, Database.pm, and SharedMem.pm modules described below.  It  also  exports
              all  of  their  symbols  by default. If you use the other modules directly you have
              request which symbol tags to import.

       ZoneMinder/Base.pm
              This is the base ZoneMinder perl module. It  contains  only  simple  data  such  as
              version information. It is included by all other ZoneMinder perl modules

       ZoneMinder/Config.pm
              This module imports the ZoneMinder configuration from the database.

       ZoneMinder/Debug.pm
              This  module  contains  the defined Debug and Error functions etc, that are used by
              scripts to produce diagnostic information in a standard format.

       ZoneMinder/Database.pm
              This module contains database access definitions and functions. Currently not a lot
              is in this module but it is included as a placeholder for future development.

       ZoneMinder/SharedMem.pm
              This  module contains standard shared memory access functions. These can be used to
              access the current state of monitors  etc  as  well  as  issuing  commands  to  the
              monitors to switch things on and off. This module effectively provides a ZoneMinder
              API.

       ZoneMinder/ConfigAdmin.pm
              This module is a  specialised  module  that  contains  the  definition,  and  other
              information, about the various configuration options. It is not intended for use by
              3rd parties.

       ZoneMinder/Trigger/*.pm
              These modules contain definitions of trigger channels and connections used  by  the
              zmtrigger.pl script. Although they can be used ‘as is’, they are really intended as
              examples  that  can  be  customised  or  specialised  for   different   interfaces.
              Contributed  modules  for new channels or connections will be welcomed and included
              in future versions of ZoneMinder.

   Getting Started
       After installation of Zoneminder you should  now  be  able  to  load  the  ZoneMinder  web
       frontend.  By  default this will be with the Classic skin, below is an example of the page
       you should now see.  [image]

   Enabling Authentication
       We strongly recommend enabling authentication right away. There are some situations  where
       certain  users don't enable authentication, such as instances where the server is in a LAN
       not directly exposed to the Internet, and is only accessible via VPN  etc.,  but  in  most
       cases, authentication should be enabled. So let's do that right away.

       · Click on the Options link on the top right corner of the web interface

       · You will now be presented with a screen full of options. Click on the "System" tab
       [image]

       · The relevant portions to change are marked in red above

       · Enable  OPT_USE_AUTH - this automatically switches to authentication mode with a default
         user (more on that later)

       · Select a random string for AUTH_HASH_SECRET - this is used to  make  the  authentication
         logic  more  secure,  so  please  generate your own string and please don't use the same
         value in the example.

       · The other options highlighed above should already be set, but if not, please  make  sure
         they are

       · Click on Save at the bottom and that's it! The next time you refresh that page, you will
         now be presented with a login screen. Job well done!
       [image]

       NOTE:
          The default login/password is "admin/admin"

   Switching to flat theme
       What you see is what is called a "classic" skin. Zoneminder has a  host  of  configuration
       options  that  you  can  customize  over  time. This guide is meant to get you started the
       easiest possible way, so we will not go into all the details. However, it is worthwhile to
       note  that  Zoneminder also has a 'flat' theme that depending on your preferences may look
       more modern. So let's use that as an example of introducing you to the Options menu

       · Click on the Options link on the top right of the web interface in the image above

       · This will bring you to the options window as shown below. Click on the "System" tab  and
         then select the "flat" option for CSS_DEFAULT as shown below
       [image]

       · Click Save at the bottom

       Now, switch to the "Display" tab and also select "Flat" there like so: [image]

       Your screen will now look like this:

       Congratulations! You now have a modern looking interface.  [image]

   Understanding the Web Console
       Before  we  proceed,  lets  spend a few minutes understanding the key functions of the web
       console.  For the sake of illustration,  we  are  going  to  use  a  populated  zoneminder
       configuration  with  several  monitors  and events.  Obviously, this does not reflect your
       current web console - which is essentially void of any useful information till now, as  we
       are  yet to add things. Let's take a small break and understand what the various functions
       are before we configure our own empty screen.  [image]

       · A: This is the username that is logged in. You are logged in as 'admin' here

       · B: Click here to explore the various options of ZoneMinder and how  to  configure  them.
         You  already  used  this to enable authentication and change style above. Over time, you
         will find this to have many other things you will want to customize.

       · C: This link, when clicked, opens up a color coded log window of what  is  going  on  in
         Zoneminder and often gives you good insight into what is going wrong or right. Note that
         the color here is red - that is an indication that some error  occurred  in  ZoneMinder.
         You should click it and investigate.

       · D:  This  is the core of ZoneMinder - recording events. It gives you a count of how many
         events were recorded over the hour, day, week, month.

       · E: These are the "Zones". Zones are areas within the camera that you mark as  'hotspots'
         for  motion  detection. Simply put, when you first configure your monitors (cameras), by
         default Zoneminder uses the entire field of view of the camera to detect motion. You may
         not  want  this.  You  may  want to create "zones" specifically for detecting motion and
         ignore others. For example, lets consider a room with a fan that spins. You surely don't
         want  to consider the fan moving continuously a reason for triggering a record? Probably
         not - in that case, you'd leave the fan out while making your zones.

       · F: This is the "source" column that tells you the type of the camera  -  if  its  an  IP
         camera,  a  USB camera or more. In this example, they are all IP cameras. Note the color
         red on item F ? Well that means there is something wrong with that camera. No wonder the
         log also shows red. Good indication for you to tap on logs and investigate

       · G:  This  defines  how  Zoneminder will record events. There are various modes. In brief
         Modect == record if a motion is detected,Record = always record 24x7,  Mocord  =  always
         record PLUS detect motion,  Monitor = just provide a live view but don't record anytime,
         Nodect = Don't record till an external entity via zmtrigger tells Zoneminder to (this is
         advanced usage).

       · H:  If you click on these links you can view a "Montage" of all your configured monitors
         or cycle through each one

       · I: One of the most often missed features is the ability of ZoneMinder to  maintain  "run
         states".  If  you  click on the "Running" text, ZoneMinder brings up a popup that allows
         you to define additional "states" (referred to as runstates). A runstate is  essentially
         a  snapshot  that  records  the  state of each monitor and you can switch between states
         easily. For example, you might have a run state defined that switches  all  monitors  to
         "monitor"  mode  in  which they are not recording anything while another state that sets
         some of the monitors to "modect". Why would you want this? A great example is to disable
         recording  when  you  are  at home and enable when you are away, based on time of day or
         other triggers. You can switch states by selecting an appropriate state manually, or  do
         it  automatically  via cron jobs, for example. An example of using cron to automatically
         switch is provided in the FAQ.  More esoteric examples of switching run states based  on
         phone location can be found here.

       Here  is  an example of multiple run states that I've defined. Each one of these runstates
       changes the mode of specific monitors depending on time of day and other  conditions.  Use
       your imagination to decide which conditions require state changes.  [image]

   Adding Monitors
       Now  that  we  have  a  basic understanding of the web console, lets go about adding a new
       camera (monitor). For this example, lets assume we have an IP camera that streams RTSP  at
       LAN IP address 192.168.1.33.

       The  first  thing we will need to know is how to access that camera's video feed. You will
       need to consult your camera's manual or check their forum. Zoneminder community users also
       have  a  frequently  updated list right here that lists information about many cameras. If
       you don't find your list there and can't seem to find it elsewhere, feel free to  register
       and ask in the user foums.

       The  camera  we  are  using  as an example here is a Foscam 9831W which is a 1280x960 RTSP
       camera, and the URL to access it's feed is username:password@IPADDRESS:PORT/videoMain

       Let's get started:

       Click on the "Add new monitor" button below: [image]

       This brings up the new monitor window: [image]

       · We've given it a name of 'Garage', because, well, its better than Monitor-1 and this  is
         my Garage camera.

       · There  are  various  source  types. As a brief introduction you'd want to use 'Local' if
         your camera is physically attached to your ZM server (like a USB camera,  for  example),
         and  one of 'Remote', 'FFMpeg', 'Libvlc' or 'cURL' for a remote camera (not necessarily,
         but usually). For this example, let's go with 'Remote'.

       NOTE:
          As a  thumb rule, if you have a camera accessible via IP and  it  does  HTTP  or  RTSP,
          start    with   Remote,   then   try   FFMpeg   and   libvlc   if   it   doesn't   work
          (/userguide/definemonitor covers other modes in more details).  If  you  are  wondering
          what 'File' does, well, ZoneMinder was built with compatibility in mind. Take a look at
          this post  to see how file can be used for leisure reading.

       · Let's leave the Function as 'Monitor' just so we can use this as an example to change it
         later another way. Practically, feel free to select your mode right now - Modect, Record
         etc depending on what you want ZoneMinder to do with this camera

       · We've put in MaxFPS and AlarmFPS as 20 here. You can leave this empty too. Whatever  you
         do here, it's important to make sure these values are higher than the FPS of the camera.
         The reason we've added a value here is that as of Aug 2015, if a  camera  goes  offline,
         ZoneMinder eats up a lot of CPU  trying to reach it and putting a larger value here than
         the actual FPS helps in that specific situation.

       NOTE:
          We strongly recommend not putting in a lower FPS here that the  one  configured  inside
          your  camera.   Zoneminder  should not be used to manage camera frame rate. That always
          causes many problems. It's much better you set the value directly in-camera and  either
          leave this blank or specify a higher FPS here. In this case, our actual camera FPS is 3
          and we've set this value here to 10.

       · We are done for the General tab. Let's move to the next tab
       [image]

       · Let's select a protocol of RTSP and a remote method of RTP/RTSP (this is an RTSP camera)

       · The other boxes are mostly self-explanatory

       That's pretty much it. Click on Save. We are not going to explore the other tabs  in  this
       simple guide.

       You now have a configured monitor: [image]

       If  you want to change its mode from Monitor to say, Modect (Motion Detect), later all you
       need to do is click on the Function column that says 'Monitor' and change it  to  'Modect'
       like so: [image]

       and we now have: [image]

       And then, finally, to see if everything works, lets click on the monitor name ('Garage' in
       this example) and that should bring up a live feed just like this: [image]

   Conclusion
       This was a quick 'Getting Started' guide where you were introduced to the very  basics  of
       how  to  add  a  monitor (camera). We've skipped many details to keep this concise. Please
       refer to /userguide/definemonitor for many other customization details.

   Defining Monitors
       To use ZoneMinder properly you need to define at least one Monitor. Essentially, a monitor
       is  associated  with  a  camera and can continually check it for motion detection and such
       like.

       You can access the monitor window by clicking on the  “Add  New  Monitor”  button,  or  by
       clicking on the “Source” column of a predefined monitor.  [image]

       There  are  a  small  number of camera setups that ZoneMinder knows about and which can be
       accessed by clicking on the ‘Presets’ link. Selecting one of the presets will fill in  the
       monitor  configuration with appropriate values but you will still need to enter others and
       confirm the preset settings. Here is an example of the presets window: [image]

       The options are divided into a set of tabs to make it easier to edit. You do not  have  to
       ‘save’  to  change  to  different tab so you can make all the changes you require and then
       click ‘Save’ at the end. The individual options are explained  in  a  little  more  detail
       below,

   Monitor Tab
       Name   The  name  for  your  monitor.  This  should  be made up of alphanumeric characters
              (a-z,A-Z,0-9) and hyphen (-) and underscore(_) only. Whitespace is not allowed.

       Server Multi-Server implementation  allows  the  ability  to  define  multiple  ZoneMinder
              servers  sharing a single database. When servers are configured this setting allows
              you nominate the server for each monitor.

       Source Type
              This determines whether the camera is a local one attached to a physical  video  or
              USB  port  on  your  machine,  a  remote  network camera or an image source that is
              represented by a file  (for  instance  periodically  downloaded  from  a  alternate
              location).  Choosing one or the other affects which set of options are shown in the
              Source tab.

       Function
              This essentially defines what the  monitor  is  doing.  This  can  be  one  of  the
              following;

                 · None  –  The monitor is currently disabled. No streams can be viewed or events
                   generated. Nothing is recorded.

                 · Monitor – The monitor is only available for live streaming. No image  analysis
                   is  done  so  no  alarms  or  events  will  be  generated, and nothing will be
                   recorded.

                 · Modect – or MOtion DEteCTtion. All captured images will be analysed and events
                   generated with recorded video where motion is detected.

                 · Record  –  The monitor will be continuously recorded. Events of a fixed-length
                   will be generated regardless of motion, analogous to a conventional time-lapse
                   video recorder. No motion detection takes place in this mode.

                 · Mocord  –  The  monitor  will  be continuously recorded, with any motion being
                   highlighted within those events.

                 · Nodect – or No DEteCTtion. This is a special mode designed  to  be  used  with
                   external  triggers.  In  Nodect no motion detection takes place but events are
                   recorded if external triggers require it.

              Generally speaking it is best to choose ‘Monitor’ as an initial setting here.

       Enabled
              The enabled field indicates whether the monitor should be started in an active mode
              or in a more passive state. You will nearly always want to check this box, the only
              exceptions being when you want the camera to be enabled  or  disabled  by  external
              triggers  or scripts. If not enabled then the monitor will not create any events in
              response to motion or any other triggers.

       Linked Monitors
              This field allows you to select other monitors on your system that act as  triggers
              for  this monitor. So if you have a camera covering one aspect of your property you
              can force all cameras to record while that camera detects motion or  other  events.
              You  can  either  directly  enter a comma separated list of monitor ids or click on
              ‘Select’ to choose a selection. Be very careful not to create circular dependencies
              with  this  feature  however  you  will  have infinitely persisting alarms which is
              almost certainly not what you want! To unlink monitors you can ctrl-click.

       Maximum FPS
              On some occasions you may have one or more cameras capable of  high  capture  rates
              but  find that you generally do not require this performance at all times and would
              prefer to lighten the load on your server. This option permits  you  to  limit  the
              maximum  capture rate to a specified value. This may allow you to have more cameras
              supported on your system by reducing the CPU load or to  allocate  video  bandwidth
              unevenly  between cameras sharing the same video device. This value is only a rough
              guide and the lower the value you set the less close the actual FPS may approach it
              especially  on  shared devices where it can be difficult to synchronise two or more
              different capture rates precisely. This option controls  the  maximum  FPS  in  the
              circumstance where no alarm is occurring only.

              This feature is limited and will only work under the following conditions:

              1. Local cameras

              2. Remote (IP) cameras in snapshot or jpeg mode only

              Using  this  field for video streams from IP cameras will cause undesirable results
              when the value is equal to or less than the frame rate from the camera.  Note  that
              placing a value higher than the camera’s frame rate is allowed and can help prevent
              cpu spikes when communication from the camera is lost.

       Alarm Maximum FPS
              If you have specified a Maximum FPS it may be that you don’t want  this  limitation
              to  apply when your monitor is recording motion or other event. This setting allows
              you to override the Maximum FPS value if this  circumstance  occurs.  As  with  the
              Maximum  FPS  setting  leaving  this  blank  implies  no limit so if you have set a
              maximum fps in the previous option then when an alarm occurs this  limit  would  be
              ignored  and  ZoneMinder  would capture as fast as possible for the duration of the
              alarm, returning to the limited value after the alarm has  concluded.  Equally  you
              could  set  this  to the same, or higher (or even lower) value than Maximum FPS for
              more precise control over the capture rate in the event of an alarm.

              IMPORTANT: This field is subject to the same limitations as the Maximum FPS  field.
              Ignoring these limitations will produce undesriable results.

       Reference Image Blend %ge
              Each  analysed  image in ZoneMinder is a composite of previous images and is formed
              by applying the current image as a certain percentage  of  the  previous  reference
              image. Thus, if we entered the value of 10 here, each image’s part in the reference
              image will diminish by a factor of 0.9 each time  round.  So  a  typical  reference
              image  will  be 10% the previous image, 9% the one before that and then 8.1%, 7.2%,
              6.5% and so on of the rest of the way. An image will effectively vanish  around  25
              images later than when it was added. This blend value is what is specified here and
              if higher will make slower progressing events  less  detectable  as  the  reference
              image  would  change  more quickly. Similarly events will be deemed to be over much
              sooner as the reference image adapts to the new  images  more  quickly.  In  signal
              processing  terms  the  higher this value the steeper the event attack and decay of
              the signal. It depends on your particular requirements what the  appropriate  value
              would  be  for  you  but  start  with 10 here and adjust it (usually down) later if
              necessary.

       Triggers
              This small section lets you select which triggers will apply if the  run  mode  has
              been  set to ‘triggered’ above. The most common trigger is X10 and this will appear
              here if you indicated that your system supported it during installation.  Only  X10
              is  supported  as  a  shipped trigger with ZoneMinder at present but it is possible
              that other triggers will become available as  necessary.  You  can  also  just  use
              ‘cron’  jobs  or  other  mechanisms  to  actually  control the camera and keep them
              completely outside of the ZoneMinder settings.  The  zmtrigger.pl  script  is  also
              available to implement custom external triggering.

   Source Tab
   FFmpeg
          This is the recommended source type for most modern ip cameras.

       Source Path
              Use  this  field  to enter the full URL of the stream or file your camera supports.
              This is usually an RTSP url. There are several methods to learn this:

                 · Check the documentation that came with your camera

                 · Look  for  your  camera  in  the  hardware  compatibilty  list  in  the   wiki
                   http://wiki.zoneminder.com/Hardware_Compatibility_List

                 · Try ZoneMinder’s new ONVIF probe feature

                 · Download  and  install  the  ONVIF  Device  Manager  onto  a  Windows  machine
                   https://sourceforge.net/projects/onvifdm/

                 · Use Google to find third party  sites,  such  as  ispy,  which  document  this
                   information

       Source Colours
              Specify the amount of colours in the captured image. 32 bit is the preferred choice
              here. Unlike with local cameras changing this has  no  controlling  effect  on  the
              remote  camera  itself  so  ensure  that  your camera is actually capturing to this
              palette beforehand.

       Capture Width/Height
              Make sure you enter here the same  values  as  they  are  in  the  remote  camera’s
              internal setting.

       Keep aspect ratio
              As per local devices.

       Orientation
              As per local devices.

   LibVLC
          The  fields for the LibVLC source type are configured the same way as the ffmpeg source
          type. We recommend only using this source type  if  issues  are  experienced  with  the
          ffmpeg source type.

   cURL
   Local
       Device Path/Channel
              Enter  the  full  path  to  the  device  file that your camera is attached to, e.g.
              /dev/video0. Some video devices, e.g. BTTV cards support multiple  cameras  on  one
              device  so  in this case enter the channel number in the Channel box or leave it at
              zero if you’re using a USB camera or one with just one channel. Look  in  Supported
              Hardware  section,  how  to  see if your capture card or USB webcam is supported or
              not, and what extra settings you may have to do, to make it work.

       Device Format
              Enter the video format of the video stream. This is defined in various system files
              (e.g.  /usr/include/linux/videodev.h)  but  the two most common are 0 for PAL and 1
              for NTSC.

       Capture Palette
              Finally for the video part of the configuration enter the colour depth.  ZoneMinder
              supports a handful of the most common palettes, so choose one here. If in doubt try
              32 bit colour first, then 24 bit colour, then grey. If  none  of  these  work  very
              well,  and  your  camera is local, then YUV420P or one of the others probably will.
              There is a slight performance penalty when using palettes other  than  32,  24,  or
              grey  palettes as an internal conversion is involved. Recent versions of ZoneMinder
              support 32bit colour. This capture palette provides a performance boost  when  used
              on all modern Intel-based processors.

       Capture Width/Height
              The dimensions of the video stream your camera will supply. If your camera supports
              several just enter the one you’ll want to use for this application, you can  always
              change  it later. However I would recommend starting with no larger than 320x240 or
              384x288 and then perhaps increasing and seeing how performance  is  affected.  This
              size  should  be  adequate  in  most cases. Some cameras are quite choosy about the
              sizes you can use  here  so  unusual  sizes  such  as  197x333  should  be  avoided
              initially.

       Keep aspect ratio
              When  typing  in  the  dimensions of monitors you can click this checkbox to ensure
              that the width stays in the correct ratio to the height, or vice versa.  It  allows
              height  to  be  calculated  automatically  from  width (or vice versa) according to
              preset aspect ratio. This is preset to 4:3 but can  be  amended  globally  via  the
              Options->Config->ZM_DEFAULT_ASPECT_RATIO setting. Aside from 4:3 which is the usual
              for network and analog cameras another common setting is  11:9  for  CIF  (352x288)
              based sources.

       Orientation
              If  your camera is mounted upside down or at right angles you can use this field to
              specify a rotation that is applied to the image as it is captured. This  incurs  an
              additional processing overhead so if possible it is better to mount your camera the
              right way round if you can. If you choose one of the rotation options  remember  to
              switch the height and width fields so that they apply, e.g. if your camera captures
              at 352x288 and you choose ‘Rotate Right’ here then set the height  to  be  352  and
              width  to  be  288. You can also choose to ‘flip’ the image if your camera provides
              mirrored input.

   Remote
       Remote Protocol
              Choices are currently HTTP and RTSP. Before RTSP became the industry standard, many
              ip  cameras  streamed directly from their web portal. If you have an ip camera that
              does not speak RTSP then choose HTTP here. If you camera does speak RTSP  then  you
              should change your source type to ffmpeg instead of selecting RTSP here. The Remote
              -> RTSP method is no longer being maintained and may go away at some point  in  the
              future.

       Remote Method
              When  HTTP  is the Remote Protocol, your choices are Simple and Regexp. Most should
              choose Simple. When RTSP is the Remote  Protocol,  your  choices  are  RTP/Unicast,
              RTP/Multicast,  RTP/RTSP, RTP,RTSP,HTTP. Try each of these to determine which works
              with your camera. Most cameras will use either RTP/Unicast (UDP) or RTP/RTSP (TCP).

       Remote Host/Port/Path
              Use these fields to enter the full URL of the camera. Basically if your  camera  is
              at  http://camserver.home.net:8192/cameras/camera1.jpg  then  these  fields will be
              camserver.home.net, 8192 and /cameras/camera1.jpg respectively. Leave the  port  at
              80  if  there  is no special port required. If you require authentication to access
              your   camera   then   add   this   onto   the    host    name    in    the    form
              <username>:<password>@<hostname>.com. This will usually be 32 or 24 bit colour even
              if the image looks black and white. Look in Supported Hardware  >  Network  Cameras
              section, how to obtain these strings that may apply to your camera.

       Remote Image Colours
              Specify  the  amount  of  colours  in the captured image. Unlike with local cameras
              changing this has no controlling effect on the remote camera itself so ensure  that
              your camera is actually capturing to this palette beforehand.

       Capture Width/Height
              Make  sure  you  enter  here  the  same  values  as they are in the remote camera’s
              internal setting.

       Keep aspect ratio
              As per local devices.

       Orientation
              As per local devices.

       For      an      example       to       setup       a       MPEG-4       camera       see:
       How_to_Setup_an_Axis211A_with_MPEG-4_streaming

   File
       File Path
              Enter the full path to the file to be used as the image source.

       File Colours
              Specify the amount of colours in the image. Usually 32 bit colour.

       Capture Width/Height
              As per local devices.

       Keep aspect ratio
              As per local devices.

       Orientation
              As per local devices.

   WebSite
       This  Source  Type allows one to configure an arbitrary website as a non-recordable, fully
       interactive, monitor in ZoneMinder. Note that sites with self-signed certificates will not
       display  until  the end user first manually navigates to the site and accpets the unsigned
       certificate. Also note that some sites will set an X-Frame option  in  the  header,  which
       discourages  their  site  from being displayed within a frame. ZoneMinder will detect this
       condition and present a warning in the log. When this occurs, the end user can  choose  to
       install a browser plugin or extension to workaround this issue.

       Website URL
              Enter the full http or https url to the desired website.

       Width (pixels)
              Chose  a desired width in pixels that gives an acceptable appearance. This may take
              some expirimentation.

       Height (pixels)
              Chose a desired height in pixels that gives an acceptable appearance. This may take
              some expirimentation.

       Web Site Refresh
              If  the  website  in question has static content, optionally enter a time period in
              seconds for ZoneMinder to refresh the content.

   Storage Tab
       The storage section allows for each monitor to configure if and how video  and  audio  are
       recorded.

       Save JPEGs
              Records  video in individual JPEG frames. Storing JPEG frames requires more storage
              space than h264 but it allows to view an event anytime while it is being recorded.

              · Disabled – video is not recorded as JPEG frames. If  this  setting  is  selected,
                then  “Video  Writer”  should be enabled otherwise there is no video recording at
                all.

              · Frames only – video is recorded in individual JPEG frames.

              · Analysis images only (if available) – video is recorded in invidual  JPEG  frames
                with  an  overlay  of  the  motion detection analysis information. Note that this
                overlay remains permanently visible in the frames.

              · Frames + Analysis images (if available) – video is recorded twice, once as normal
                individual JPEG frames and once in invidual JPEG frames with analysis information
                overlaid.

       Video Writer
              Records video in real video format. It provides  much  better  compression  results
              than saving JPEGs, thus longer video history can be stored.

              · Disabled  –  video  is not recorded in video format. If this setting is selected,
                then “Save JPEGs” should be enabled otherwise there is no video recording at all.

              · X264 Encode – the video or picture frames received from the camera are transcoded
                into  h264  and  stored  as  a  video. This option is useful if the camera cannot
                natively stream h264.

              · H264 Camera Passthrough – this option assumes that the camera is already  sending
                an  h264  stream.  Video  will  be recorded as is, without any post-processing in
                zoneminder. Video characteristics such as bitrate, encoding mode, etc. should  be
                set directly in the camera.

       Recording Audio
              Check  the box labeled “Whether to store the audio stream when saving an event.” in
              order to save audio (if available) when events are recorded.

   Timestamp Tab
       Timestamp Label Format
              This relates to the timestamp that is applied to each frame.  It  is  a  ‘strftime’
              style  string with a few extra tokens. You can add %f to add the decimal hundredths
              of a  second  to  the  frame  timestamp,  so  %H:%M:%S.%f  will  output  time  like
              10:45:37.45.  You  can  also use %N for the name of the monitor and %Qwhich will be
              filled by any of the ‘show text’ detailed in the zmtriggers.pl section.

       Timestamp Label X/Y
              The X and Y values determine where to put the timestamp. A value of  0  for  the  X
              value will put it on the left side of the image and a Y value of 0 will place it at
              the top of the image. To place the timestamp at the bottom of the image use a value
              eight less than the image height.

   Buffers Tab
       Image Buffer Size
              This option determines how many frames are held in the ring buffer at any one time.
              The ring buffer is the storage space where the last ‘n’ images are kept,  ready  to
              be resurrected on an alarm or just kept waiting to be analysed. It can be any value
              you like with a couple of provisos, (see next options). However  it  is  stored  in
              shared  memory  and  making  it  too  large especially for large images with a high
              colour depth can use a lot of memory. A value of no more than 50 is usually ok.  If
              you  find  that  your system will not let you use the value you want it is probably
              because your system has an arbitrary limit on the size of shared memory that may be
              used  even  though  you  may  have  plenty  of free memory available. This limit is
              usually fairly easy to change, see the Troubleshooting section for details.

       Warm-up Frames
              This specifies how many frames the analysis daemon should process but  not  examine
              when  it  starts.  This  allows  it  to generate an accurate reference image from a
              series of images before looking too carefully for any changes. I use a value of  25
              here,  too  high  and  it  will take a long time to start, too low and you will get
              false alarms when the analysis daemon starts up.

       Pre/Post Event Image Buffer
              These options determine how many frames from before and after an  event  should  be
              preserved  with  it.  This  allows  you to view what happened immediately prior and
              subsequent to the event. A value of 10 for both of these will get you  started  but
              if  you  get  a  lot  of short events and would prefer them to run together to form
              fewer longer ones then increase the Post Event buffer size. The pre-event buffer is
              a  true  buffer and should not really exceed half the ring buffer size. However the
              post-event buffer is just a count that is applied to captured frames and so can  be
              managed  more  flexibly.  You should also bear in mind the frame rate of the camera
              when choosing these values. For instance a network camera capturing  at  1FPS  will
              give you 10 seconds before and after each event if you chose 10 here. This may well
              be too much and pad out events more than necessary. However a fast video  card  may
              capture  at 25FPS and you will want to ensure that this setting enables you to view
              a reasonable time frame pre and post event.

       Stream Replay Image Buffer
              The number of frames buffered to allow pausing and rewinding  of  the  stream  when
              live  viewing a monitor. A value of 0 disables the feature.  Frames are buffered to
              ZM_PATH_SWAP. If this path points to a physical drive, a lot of IO will  be  caused
              during live view / montage. If you experience high system load in those situations,
              either disable the feature or use a RAM drive for ZM_PATH_SWAP.

       Alarm Frame Count
              This option allows you to specify how many  consecutive  alarm  frames  must  occur
              before  an  alarm  event  is  generated.  The  usual, and default, value is 1 which
              implies that any alarm frame will cause or participate in an event. You  can  enter
              any value up to 16 here to eliminate bogus events caused perhaps by screen flickers
              or other transients. Values over 3 or 4 are unlikely to be useful  however.  Please
              note  that  if  you have statistics recording enabled then currently statistics are
              not recorded for the first ‘Alarm Frame Count’-1 frames of an event. So if you  set
              this value to 5 then the first 4 frames will be missing statistics whereas the more
              usual value of 1 will ensure that all alarm frames have statistics recorded.

   Control Tab
       Note: This tab and its options will only appear if you have  selected  the  ZM_OPT_CONTROL
       option  to  indicate that your system contains cameras which are able to be controlled via
       Pan/Tilt/Zoom or other mechanisms. See  the  Camera  Control  section  elsewhere  in  this
       document for further details on camera control protocols and methods.

       Controllable
              Check this box to indicate your camera can be controlled.

       Control Type
              Select  the control type that is appropriate for your camera. ZoneMinder ships with
              a small number of predefined control protocols which will works with  some  cameras
              without  modification but which may have to amended to function with others, Choose
              the edit link to create new control types or to edit the existing ones.

       Control Device
              This is the device that is used to control your camera. This  will  normally  be  a
              serial  or similar port. If your camera is a network camera, you will generally not
              need to specify a control device.

       Control Address
              This is the address of your camera. Some control protocols require that each camera
              is  identified by a particular, usually numeric, id. If your camera uses addressing
              then enter the id of your camera here. If your camera is a network camera then  you
              will  usually  need  to  enter  the  hostname  or  IP  address  of it here. This is
              ordinarily the same as that given for the camera itself.

       Auto Stop Timeout
              Some cameras only support a continuous mode of movement. For instance you tell  the
              camera  to  pan right and then when it is aligned correctly you tell it to stop. In
              some cases it is difficult to time this precisely over  a  web  interface  so  this
              option  allows  you  to  specify  an  automatic  timeout  where the command will be
              automatically stopped. So a value of 0.25 here can tell the script to stop moving a
              quarter  of  a  second  after  starting.  This allows a more precise method of fine
              control. If this value is left blank or at zero it will be ignored, if set then  it
              will  be  used  as the timeout however it will only be applied for the lower 25% of
              possible speed ranges. In other words if your camera has a pan speed range of 1  to
              100  then  selecting to move at 26 or over will be assumed to imply that you want a
              larger movement that you can control yourself  and  no  timeout  will  be  applied.
              Selecting motion at lower speeds will be interpreted as requiring finer control and
              the automatic timeout will be invoked.

       Track Motion
              This and the following four options are used with the experimental motion function.
              This  will only work if your camera supports mapped movement modes where a point on
              an image can be mapped to a control command.  This  is  generally  most  common  on
              network  cameras but can be replicated to some degree on other cameras that support
              relative movement modes. See the Camera Control section  for  more  details.  Check
              this box to enable motion tracking.

       Track Delay
              This  is  the  number  of  seconds  to  suspend  motion detection for following any
              movement that the camera may make to track motion.

       Return Location
              If you camera supports a ‘home’ position or presets you can choose which preset the
              camera should return to after tracking motion.

       Return Delay
              This  is  the delay, in seconds, once motion has stopped being detected, before the
              camera returns to any defined return location.

   X10 Tab
       Note: This tab and its options will only appear if you have  indicated  that  your  system
       supports the X10 home automation protocol during initial system configuration.

       X10 Activation String
              The  contents  of  this  field  determine  when a monitor starts and/or stops being
              active when running in ‘Triggered; mode and with X10 triggers. The format  of  this
              string is as follows,

                 · n  :  If  you simply enter a number then the monitor will be activated when an
                   X10 ON signal for that unit code is detected and will be deactivated  when  an
                   OFF signal is detected.

                 · !n  :  This  inverts  the  previous  mode,  e.g.  !5 means that the monitor is
                   activated when an OFF signal for unit code 5 is detected and deactivated by an
                   ON.

                 · n+ : Entering a unit code followed by + means that the monitor is activated on
                   receipt of a ON signal for that unit code but will ignore the OFF  signal  and
                   as  such  will not be deactivated by this instruction. If you prepend a ‘!’ as
                   per the previous definition it similarly inverts the mode, i.e. the ON  signal
                   deactivates the monitor.

                 · n+<seconds> : As per the previous mode except that the monitor will deactivate
                   itself after the given number of seconds.

                 · n- : Entering a unit code followed by - means that the monitor is  deactivated
                   on  receipt  of  a OFF signal for that unit code but will ignore the ON signal
                   and as such will not be activated by this instruction. If you prepend a ‘!’ as
                   per the previous definition it similarly inverts the mode, i.e. the OFF signal
                   activates the monitor.

                 · n-<seconds> : As per the previous mode except that the monitor  will  activate
                   itself after the given number of seconds.

              You  can  also  combine  several  of these expressions to by separating them with a
              comma to create multiple circumstances of activation. However for  now  leave  this
              blank.

       X10 Input Alarm String
              This  has  the  same  format  as  the  previous field but instead of activating the
              monitor with will cause a forced alarm to be generated and an event recorded if the
              monitor  is  Active. The same definition as above applies except that for activated
              read alarmed and for deactivated read unalarmed(!). Again leave this blank for now.

       X10 Output Alarm String
              This X10 string also has the same format as the two above options. However it works
              in  a  slightly  different  way.  Instead of ZoneMinder reacting to X10 events this
              option controls how ZoneMinder emits X10 signals when the current monitor goes into
              or  comes  out  of  the  alarm state. Thus just entering a number will cause the ON
              signal for that unit code to be sent when going into alarm state and the OFF signal
              when  coming out of alarm state. Similarly 7+30 will send the unit code 7 ON signal
              when going into alarm state and the OFF  signal  30  seconds  later  regardless  of
              state.   The  combination  of  the  X10  instruction  allows  ZoneMinder  to  react
              intelligently to, and also assume control of, other devices when necessary. However
              the  indiscriminate  use of the Input Alarm and Output Alarm signals can cause some
              horrendous race conditions such as a light going on in response to an  alarm  which
              then  causes  an alarm itself and so on. Thus some circumspection is required here.
              Leave this blank for now anyway.

   Misc Tab
       Event Prefix
              By default events are named ‘Event-<event id>’, however you are free to rename them
              individually  as  you  wish.  This  option  lets  you  modify the event prefix, the
              ‘Event-‘ part, to be a value of your choice so that events are named differently as
              they  are  generated.  This  allows  you  to name events according to which monitor
              generated them.

       Section Length
              This specifies the length (in seconds) of any fixed length events produced when the
              monitor  function is ‘Record’ or ‘Mocord’. Otherwise it is ignored. This should not
              be so long that events are difficult to navigate nor so short that too many  events
              are generated. A length of between 300 and 900 seconds I recommended.

       Frame Skip
              This  setting also applies only to the ‘Record’ or ‘Mocord’ functions and specifies
              how many frames should be skipped in the recorded events. The  default  setting  of
              zero  results  in every captured frame being saved. Using a value of one would mean
              that one frame is skipped between each saved, two means that two frames are skipped
              between  each  saved  frame  etc. An alternate way of thinking is that one in every
              ‘Frame Skip + 1’ frames is saved. The point of this is to ensure that saved  events
              do  not  take  up  too much space unnecessarily whilst still allowing the camera to
              capture at a fairly high frame rate. The alternate approach is to limit the capture
              frame rate which will obviously affect the rate at which frames are saved.

       FPS Report Interval
              How  often  the  current performance in terms of Frames Per Second is output to the
              system log. Not used in any functional way so set it to maybe 1000 for now. If  you
              watch  /var/log/messages  (normally)  you  will see this value being emitted at the
              frequency you specify both for video capture and processing.

       Default Scale
              If your monitor has been defined with a particularly large or small image size then
              you  can choose a default scale here with which to view the monitor so it is easier
              or more visible from the web interface.

       Web Colour
              Some elements of ZoneMinder now use colours to identify monitors on certain  views.
              You  can  select which colour is used for each monitor here. Any specification that
              is valid for HTML colours is valid here, e.g. ‘red’ or ‘#ff0000’.  A  small  swatch
              next to the input box displays the colour you have chosen.

   Defining Zones
       The  next  important  thing  to  do  with  a new monitor is set up Zones for it to use. By
       default you’ll already have one generated for you  when  you  created  your  monitor  (the
       default  zone is the full area captured by the monitor) but you might want to modify it or
       add others.

       Click on the Zones column for your monitor and you should see a small popup window  appear
       which  contains  an  image  from your camera overlain with a stippled pattern representing
       your zone. In the default case this will cover the whole image. The colour  of  the  zones
       appearing here is determined by what type they are. The default zone is Active and so will
       be red, Inclusive zones are orange, exclusive zones are purple, preclusive zones are  blue
       and inactive zones are white.

       Beneath  the  zones  image will be a table containing a listing of your zones. Clicking on
       either the relevant bit of the image or on the Id or Name  in  the  table  will  bring  up
       another  window where you can edit the particulars for your Zones. For more information on
       defining or editing a zone, see Defining Zones.

       Zone configuration and tuning are important when running in the motion detection modes  to
       avoid storing, sorting through, or being alerted on uninteresting video data.  Configuring
       a zone involves setting some basic parameters, as well as choosing an alarm  check  method
       and tuning their associated detection parameters.

       The Zone view is split into two main areas, on the left is the options are area and on the
       right is the zone drawing area. A default or new zone will cover the  whole  drawing  area
       and  will  overlay  any  other  zones you already have on there. Unlike the previous zones
       image, the current zone is coloured green, other zones will be orange regardless of  type.
       The smaller the zone, the less processing time it takes to examine it.

   Basic parameters
       Name   Each  Zone  can  be  named  for  reference  purposes.   It  is used for logging and
              debugging.  Choose a name that helps you identify your zones.

       Type   This is one of the more important concepts in  ZoneMinder  and  there  are  six  to
              choose from.

              · Active  Triggers  an  alarm  when motion is detected within it.  This is the zone
                type you’ll use most often, and which will be set for your  default  zone.   Only
                Active and Exclusive zones can trigger an alarm.

              · Inclusive  This  zone  type can be used for any zones that you want to trigger an
                alarm only if at least one other Active zone  has  already  triggered  one.  This
                might  be  for  example  to cover an area of the image like a plant or tree which
                moves a lot and which would trigger lots of alarms. Perhaps  this  is  behind  an
                area  you’d  like  to  monitor  though,  in this case you’d create an active zone
                covering the non-moving parts and an inclusive zone  covering  the  tree  perhaps
                with  less  sensitive detection settings also. If something triggered an alarm in
                the Active zone and also in the Inclusive zone they would both be registered  and
                the  resulting  alarm  would  be  that much bigger than if you had blanked it out
                altogether.

              · Exclusive Triggers an alarm when motion is detected within  it,  as  long  as  no
                alarms  have  already  been  triggered  in  an  Active  zone.   This  is the most
                specialized of the zone types. For instance in the camera covering  my  garden  I
                keep  watch  for a hedgehog that visits most nights and scoffs the food out of my
                cats bowls. By creating a sensitive Exclusive zone in that area I can ensure that
                a  hedgehog  alarm  will only trigger if there is activity in that small area. If
                something much bigger occurs, like someone walking by it will trigger  a  regular
                alarm and not one from the Exclusive zone. Thus I can ensure I get alarms for big
                events and also special small events but not the noise in between.

              · Preclusive This zone type is relatively recent. It is called  a  Preclusive  zone
                because  if  it  is  triggered it actually precludes an alarm being generated for
                that image frame. So motion or other changes that occur in a Preclusive zone will
                have the effect of ensuring that no alarm occurs at all. The application for this
                zone type is primarily as a shortcut for detecting general  large-scale  lighting
                or  other  changes. Generally this may be achieved by limiting the maximum number
                of alarm pixels or other measure in an Active zone. However in  some  cases  that
                zone  may  cover  an  area  where  the  area  of  variable illumination occurs in
                different places as the sun and/or shadows move and it thus may be  difficult  to
                come  up  with  general  values.  Additionally, if the sun comes out rapidly then
                although the initial change may be ignored in this way  as  the  reference  image
                catches  up  an  alarm  may  ultimately  be  triggered  as the image becomes less
                different. Using one or  more  Preclusive  zones  offers  a  different  approach.
                Preclusive  zones are designed to be fairly small, even just a few pixels across,
                with quite low alarm thresholds. They should be situated in areas  of  the  image
                that  are less likely to have motion occur such as high on a wall or in a corner.
                Should a general illumination change occur they would be triggered  at  least  as
                early  as  any Active zones and prevent any other zones from generating an alarm.
                Obviously careful placement is required to ensure that they  do  not  cancel  any
                genuine  alarms  or that they are not so close together that any motion just hops
                from one Preclusive zone to another.  Preclusive zones may also be used to reduce
                processing  time  by  situating  one over an Active zone.  The Preclusive zone is
                processed first; if it is small, and is triggered, the  rest  of  the  zone/image
                will not be processed.

              · Inactive  Suppresses  the  detection of motion within it.  This can be layered on
                top of any other zone type, preventing motion within the Inactive zone from being
                effective  for  any  other zone type.  Use inactive zones to cover areas in which
                nothing notable will ever happen or where you get false alarms that don’t  relate
                to what you are trying to monitor.  Inactive zones may be overlaid on other zones
                to blank out areas, and are processed first (with the exception of Privacy zones,
                see below).  As a general practice, you should try and make zones abut each other
                instead of overlapping to avoid repeated duplicate processing of the same area.

              · Privacy Blackens the pixels within it. This can be used if you want to hide  some
                regions  in the image if the situation does not allow another solution. This zone
                type is different to all the others in that it gets processed as soon as possible
                during  capture  (even  before  the timestamp gets into the image) and not in the
                analyzing process. So if you add, change or delete a Privacy zone, you don’t  see
                the  changes  in the image until the capture process gets restarted. This will be
                done automatically, but needs a few seconds.

       Preset The preset chooser sets sensible default values based on computational needs  (fast
              v. best) and sensitivity (low, medium, high.)  It is not required that you select a
              preset, and you can alter any of the parameters after choosing  a  preset.   For  a
              small  number  of  monitors with ZoneMinder running on modern equipment, Best, high
              sensitivity can be chosen as a good starting point.

              It is important to understand that the available presets are intended merely  as  a
              starting  point.  Since  every  camera’s view is unique, they are not guaranteed to
              work properly in every case. Presets tend to work acceptably  for  indoor  cameras,
              where  the  objects of interest are relatively close and there typically are few or
              no unwanted objects moving within the cameras view. Presets,  on  the  other  hand,
              tend  to  not  work  acceptably  for  outdoor  cameras,  where the field of view is
              typically much wider, objects of interest are farther away,  and  changing  weather
              patterns  can  cause  false  triggers.  For outdoor cameras in particular, you will
              almost certainly have to tune your motion detection zone to  get  desired  results.
              Please refer to this guide to learn how to do this.

       Units

              · Pixels  -  Selecting  this  option  will allow many of the following values to be
                entered (or viewed) in units of pixels.

              · Percentage -  Selecting this option will allow may of the following values to  be
                entered  (or  viewed) as a percentage.  The sense of the percentage values refers
                to the area of the zone and not the image as a whole. This makes trying  to  work
                out necessary sizes rather easier.

       Region points [image]

       The  sample  region  shown  to  the right shows a region defined by 6 control points.  The
       shape of the region causes the check methods to ignore the sidewalk and areas of the porch
       wall that receive changing sunlight; two conditions that are not of interest in this zone.
          A  region  is  a  part  of  the  captured  image that is of interest for this zone.  By
          default, a region is configured to cover the whole captured image.   Depending  on  the
          selected  type  of  this  zone,  the shape of the region can be adjusted to accommodate
          multiple effects.  This can be done by dragging the control  points  in  the  reference
          image  around, or by altering the coordinates found in the controls below the reference
          image.  Clicking on a control point in the reference image highlights  the  coordinates
          in  the table below.  Clicking the + button in a point row adds a control point between
          this point and the next; clicking the - button  removes  this  control  point.   It  is
          possible  to accidentally place a control point outside of the valid coordinates of the
          image.  This will prevent the monitor from working properly.  You can make zones almost
          any  shape you like; except that zones may not self-intersect (i.e. edges crossing over
          each other).

       Alarm Colour
              These parameters can be used to individually colorize  the  zone  overlay  pattern.
              Alarms  in  this  zone  will  be  highlighted  in the alarm colour.  This option is
              irrelevant for Preclusive and Inactive zones and will be disabled.

       Alarm Check Methods
              There are 3 Alarm Check  Methods.   They  are  sequential,  and  are  layered:   In
              AlarmedPixels mode, only the AlarmedPixel analysis is performed.  In FilteredPixels
              mode, the AlarmedPixel analysis is performed first, followed by  the  FilteredPixel
              analysis.   In  the  Blobs mode, all 3 analysis methods are performed in order.  An
              alarm is only triggered if all of the enabled analysis modes  are  triggered.   For
              performance  reasons,  as soon as the criteria for one of the analysis modes is not
              met, the alarm checking for the frame is complete.  Since the subsequent modes each
              require  progressively  more computations, it is a good idea to tune the parameters
              in each of the activated layers.

              For reference purposes, the Zone Area box shows the area of the  entire  region  of
              interest.   In  percent mode, this is 100.  In Pixels mode, this is the pixel count
              of the region.  All 3 Min/Max Area parameter groups are based on the Zone  Area  as
              the maximum sensible value, and all 3 are interpreted in the units specified in the
              Units input.

       AlarmedPixels
              Alarmed pixels is the  first  layer  of  analysis,  and  is  always  enabled.   Its
              recommended  that  you start with this method and move on to the subsequent methods
              once the effects of the basic parameters  are  understood.   In  the  AlarmedPixels
              mode, 2 parameter categories are available for tuning: Min/Max Pixel Threshold, and
              Min/Max Alarmed Area.

       Min/Max Pixel Threshold (0-255)
              In the AlarmedPixel layer of analysis,  each  individual  pixel  of  the  image  is
              compared  to  the  current  reference  image.   Pixels  that are different from the
              reference image are considered  alarmed  pixels.   However,  small  aberrations  in
              lighting  or  auto  exposure  camera  adjustments may cause the explicit value of a
              pixel to vary by small amounts from image to image.  This parameter allows  you  to
              set  the  limits  of what will be considered a changed pixel.  For example, if your
              camera points to a blank white wall, and you raise a black colored item into  view,
              then  the  change in any one pixel will be great, indeed, extreme.  If however, you
              raise a white piece of paper, then the change in an individual pixel will be less.

              The minimum pixel threshold setting should be high enough to cause minor  lighting,
              imaging, or compression changes to be ignored.  Setting the minimum value too high,
              may allow a white cat to walk undetected across the view of the white wall.  A good
              starting  point  for the minimum pixel threshold is 40, meaning that the difference
              in pixel value from must be greater than 40.  A good default for the maximum  pixel
              threshold  is  0  (indicating  that all differences above the minimum threshold are
              considered a change.)

       Min/Max Alarmed Area
              The count of alarmed pixels (or percentage of alarmed pixels relative to the  pixel
              area  of  the region if in percent mode) is used in this first layer of analysis to
              determine if an alarm is triggered.  If  the  count  or  percentage  is  above  the
              minimum  alarmed  area,  but  less  than  the  maximum  alarmed  area,  an alarm is
              triggered.  These settings depend on the size of  the  object  you  are  trying  to
              capture:  a  value too low may cause false alarms, while a value too high might not
              detect small objects.  A good starting point for both the minimum and maximum are 0
              and  0,  indicating  that  any number of alarmed pixels (or any percentage) greater
              than 0 will trigger an alarm.  The frame scores from logged events can then be used
              to  bring  the minimum up to a reasonable value.  An alternative starting point for
              the minimum alarmed area (in percent) is 25% of the area that an object of interest
              takes  up  in  the  region.   For example, if you approximate that a subject moving
              through the frame takes up 30% of the frame, then a good starting minimum  area  is
              about 7.5%.

       FilteredPixels
              Selecting  the  FilteredPixels  Alarm  Check  Method  adds  an  additional layer of
              analysis to the AlarmedPixels check along with 2  additional  parameter  categories
              for  tuning.   This  layer  works by analyzing the alarmed pixels identified in the
              first layer.  Alarmed pixels are disregarded, in this and future layers if enabled,
              if  they  are  not  in  groups  of  a  minimum  small square size.  Primarily, this
              filtering removes isolated alarmed pixels that may  be  artifacts  of  the  camera,
              lens, or compression.

       Filter Width/Height (pixels)
              This  parameter  is  always  specified  in  Pixels,  even  when Percentages are the
              selected units.  It specifies the size of the group of pixels surrounding  a  given
              pixel  that  must  be  in  alarmed  pixels for the pixel itself to be considered an
              alarmed pixel.  The width and height should always be an odd number.  3 x 3 is  the
              default  value, and 5 x 5 is also suggested as a sensible alternative.  Avoid using
              large numbers for the width and height of the filter area.  When  using  the  Blobs
              Alarm  Check  Method,  FilteredPixels can be effectively disabled by setting either
              the width or height to a value less than 1.

       Min/Max Filtered Area
              Applying the filtering analysis results in an area that is less than  or  equal  to
              the  alarmed area.  Thus the minimum and maximum filtered area parameters for alarm
              should be equal to or less than the corresponding alarm  area  parameters,  or  the
              FilteredPixels  analysis  will never trigger an alarm.  In particular, it is useful
              to raise the minimum alarmed area parameter until false events from image artifacts
              disappear,  and  setting a minimum filtered area parameter less the minimum alarmed
              area parameter by enough to capture small events of interest.

       Blobs [image]

       This image shows an image with 1 identified blob.  The  blob  is  outlined  in  the  Alarm
       Colour specified above.

       When  two or more Filtered areas touch or share a boundary, it is sensible to evaluate the
       regions as one contiguous area instead of separate entities.  A Blob is a contiguous  area
       made  up  of multiple filtered areas.  Whereas FilteredPixes is useful for excluding parts
       of the image that are not part of the actual scene, Blob filtering  is  better  suited  to
       disregarding areas of the actual scene that are not of interest.
          Selecting  the  Blobs  Alarm  Check  Method  opens  up all of the available parameters.
          Enabling Blobs adds one more layer of analysis to the  AlarmedPixel  and  FilteredPixel
          checks  in  the  determination of a valid alarm along along with 2 additional parameter
          categories for tuning: the size of the blobs, and the number of blobs.  A Blob  is  not
          necessarily  the  whole  object  that  may  be  of interest.  In the example image, the
          subject is moving, but only a portion of him is marked as a blob.  This is  because  as
          the  subject  moves,  many  pixels  of  the image do not change in value beyond the set
          threshold.  A pixel that is representing the subject’s shoulder in  one  frame  may  be
          representing  his  back in the next, however, the value of the pixel remains nearly the
          same.

       Min/Max Blob Area
              The blob area parameters control the smallest and largest contiguous areas that are
              to  be  considered  a blob.  A good value for the maximum area is the default of 0.
              (There is no upper bound for the size of a  contiguous  area  that  will  still  be
              considered a blob.)

       Min/Max Blobs
              Normally,  you  would want any positive number of blobs to trigger an event, so the
              default value of 1 should suffice.  In some circumstances, it may benefit  to  have
              only  one  blob  NOT  trigger  an  event, in which case, setting this value to 2 or
              higher may serve some special purpose.  A good value for the maximum blobs  is  the
              default of 0. (There is no upper bound for the number of blobs that will trigger an
              event.  Use the maximum blobs parameter can be used to tune out events that show  a
              high number of blobs.

       Overload Frame Ignore Count
              This  setting  specifies  the  number  of  frames  to  NOT  raise an alarm after an
              overload. In this context, overload is defined as a  detected  change  too  big  to
              raise  an  alarm.  Depending  on  the  alarm check method that could be * Number of
              alarmed pixels > Max Alarmed Area or * Number of filtered  pixels  >  Max  Filtered
              Area  or * Number of Blobs > Max Blobs The idea is that after a change like a light
              going on that is considered too big to count as an alarm, it could take a couple of
              frames for things to settle down again.

   Other information
       Refer to this user contributed Zone guide for additional information will illustrations if
       you are new to zones and need more help.

   Viewing Monitors
       ZoneMinder allows you to view a live feed of your configured monitors. One can access this
       view by clicking on the “Name” column of any of the monitors [image]

       Clicking on the name produces a view similar to this: [image]

       The  image should be self-explanatory but if it looks like garbage it is possible that the
       video configuration is wrong so look in your system error log  and  check  for  or  report
       anything  unusual.  The  centre  of the window will have a tiny frame that just contains a
       status; this will be ‘Idle’, ‘Alarm’ or ‘Alert’ depending on the function of  the  Monitor
       and  what’s  going  on  in the field of view. Idle means nothing is happening, Alarm means
       there is an alarm in progress and Alert means that an alarm has happened and  the  monitor
       is  ‘cooling down’, if another alarm is generated in this time it will just become part of
       the same event. These indicators are colour coded in green, red and amber.

       By default if you have minimised this window or opened other windows in front it will  pop
       up  to  the front if it goes to Alarm state. This behaviour can be turned off in ‘options’
       if required. You can also specify a sound file in the configuration, which will be  played
       when  an  alarm  occurs to alert you to the fact if you are not in front of your computer.
       This should be a short sound of only a couple of seconds ideally. Note that as the  status
       is  refreshed  every  few  seconds it is possible for this not to alert you to every event
       that takes place, so you shouldn’t rely on it for this purpose if you  expect  very  brief
       events.  Alternatively  you  can  decrease  the  refresh  interval  for this window in the
       configuration though having too frequent refreshing may impact on performance.

       Below the status is a list of recent events that have  occurred,  by  default  this  is  a
       listing  of just the last 10 but clicking on ‘All’ will give you a full list and ‘Archive’
       will take you to the event archive for this monitor, more on this later. Clicking  on  any
       of the column headings will sort the events appropriately.

       From  here  you  can also delete events if you wish. The events themselves are listed with
       the event id, and event name (which you can change), the time that the event occurred, the
       length  of  the  event  including  any preamble and postamble frames, the number of frames
       comprising the event with the number that  actually  contain  an  alarm  in  brackets  and
       finally  a  score.  This  column  lists  the  average score per alarm frame as well as the
       maximum score that any alarm frame had.

       The score is an arbitrary value that essentially represents the percentage  of  pixels  in
       the  zone  that  are  in  blobs divided by the square root of the number of blobs and then
       divided by the size of the zone. This gives a nominal maximum of 100 for a  zone  and  the
       totals  for  each  zone  are  added  together,  Active  zones  scores are added unchanged,
       Inclusive zones are halved first and Exclusive zones are doubled. In  reality  values  are
       likely  to  be  much  less  than 100 but it does give a simple indication of how major the
       event was.

   Filtering Events
       Filters allow you to define complex conditions  with  associated  actions  in  ZoneMinder.
       Examples could include:

       · Send an email each time a new event occurs for a specific monitor

       · Delete events  that are more than 10 days old

       And many more.

       The filter window can be accessed from various views, one of which is to simply tap on the
       filter button in the main web view: [image]

       You can use the filter window to create your own filters or to modify existing  ones.  You
       can  even  save  your  favourite  filters  to re-use at a future date. Filtering itself is
       fairly simple; you first choose how many expressions you’d like your  filter  to  contain.
       Changing  this  value  will  cause  the window to redraw with a corresponding row for each
       expression. You then select what you want to filter on and how the expressions  relate  by
       choosing  whether  they  are  ‘and’  or  ‘or’ relationships. For filters comprised of many
       expressions you will also get the option to bracket parts of the filter to ensure you  can
       express  it  as  desired.  Then  if  you  like choose how you want your results sorted and
       whether you want to limit the amount of events displayed.

       Here is what the filter window looks like [image]

       · A: This is a dropdown list where you can select pre-defined  filters.  You  will  notice
         that ZoneMinder comes with a PurgeWhenFull filter that is configured to delete events if
         you reach 95% of disk space.

       · B and C: This is where you specify conditions that need to match before  the  filter  is
         executed. You use the “+” and “-” buttons to add/delete conditions

       ·

         D: This is where you specify what needs to happen when the conditions match:

                · Archive  all  matches:  sets  the  archive  field  to 1 in the Database for the
                  matched events.  Think of ‘archiving’ as grouping them under a special category
                  -  you  can view archived events later and also make sure archived events don’t
                  get deleted, for example

                · Email details of all matches: Sends an email to  the  configured  address  with
                  details about the event.  The email can be customized as per TBD

                · Execute  command on all matches: Allows you to execute any arbitrary command on
                  the matched events. You can use replacement tokens as  subsequent  arguents  to
                  the  command,  the  last  argument  will  be  the  absolute  path to the event,
                  preceeded by replacement arguents. eg: /usr/bin/script.sh %MN% will excecute as
                  /usr/bin/script.sh MonitorName /path/to/event.

                · Delete all matches: Deletes all the matched events

       · E:  Use  ‘Submit’  to ‘test’ your matching conditions. This will just match and show you
         what filters match. Use ‘Execute’ to actually execute the  action  after  matching  your
         conditions.  Use  ‘Save’  to  save  the  filter for future use and ‘Reset’ to clear your
         settings

       NOTE:
          More details on filter conditions:

          There are several different elements to an event that you can filter on, some of  which
          require further explanation. These are as follows, * ‘Date/Time’ which must evaluate to
          a date and a time together, * ‘Date’ and ‘Time’  which  are  variants  which  may  only
          contain  the  relevant  subsets  of this, * ‘Weekday’ which as expected is a day of the
          week.

          All of the preceding elements take a very flexible free format of dates and time  based
          on  the  PHP  strtotime function (http://www.php.net/manual/en/function.strtotime.php).
          This allows values such as ‘last Wednesday’ etc to be entered. We recommend acquainting
          yourself  with  this  function  to  see what the allowed formats are. However automated
          filters are run in perl and so are parsed by the  Date::Manip  package.  Not  all  date
          formats are available in both so if you are saved your filter to do automatic deletions
          or other tasks you should make sure that the date and time format you use is compatible
          with  both methods. The safest type of format to use is ‘-3 day’ or similar with easily
          parseable numbers and units are in English.

          The other things you can filter on are all fairly self explanatory, except perhaps  for
          ‘Archived’  which  you can use to include or exclude Archived events. In general you’ll
          probably do most filtering on un-archived events. There are  also  two  elements,  Disk
          Blocks and Disk Percent which don’t directly relate to the events themselves but to the
          disk partition on which the events are stored. These allow you to specify an amount  of
          disk  usage  either  in  blocks  or in percentage as returned by the ‘df’ command. They
          relate to the amount of disk space used and not the amount left free. Once your  filter
          is specified, clicking ‘submit’ will filter the events according to your specification.
          As the disk based elements are not event related directly if you create  a  filter  and
          include the term ‘DiskPercent > 95’ then if your current disk usage is over that amount
          when you submit the filter then all events will be listed whereas if it  is  less  then
          none  at  all  will.  As  such  the  disk related terms will tend to be used mostly for
          automatic filters (see below). If you have created a filter you want to keep,  you  can
          name it and save it by clicking ‘Save’.

          If  you do this then the subsequent dialog will also allow you specify whether you want
          this filter automatically applied in order to delete events or upload events via ftp to
          another  server  and mail notifications of events to one or more email accounts. Emails
          and messages (essentially small emails intended for mobile phones  or  pagers)  have  a
          format  defined  in the Options screen, and may include a variety of tokens that can be
          substituted for various details of the event that caused them. This includes  links  to
          the event view or the filter as well as the option of attaching images or videos to the
          email itself. Be aware that tokens that represent links may require you to  log  in  to
          access  the  actual page, and sometimes may function differently when viewed outside of
          the general ZoneMinder context. The tokens you can use are as follows.

          · %EI%           Id of the event

          · %EN%          Name of the event

          · %EC%          Cause of the event

          · %ED%          Event description

          · %ET%          Time of the event

          · %EL%          Length of the event

          · %EF%          Number of frames in the event

          · %EFA%        Number of alarm frames in the event

          · %EST%        Total score of the event

          · %ESA%       Average score of the event

          · %ESM%       Maximum score of the event

          · %EP%          Path to the event

          · %EPS%       Path to the event stream

          · %EPI%         Path to the event images

          · %EPI1%       Path to the first alarmed event image

          · %EPIM%      Path to the (first) event image with the highest score

          · %EI1%         Attach first alarmed event image

          · %EIM%        Attach (first) event image with the highest score

          · %EV%          Attach event mpeg video

          · %MN%         Name of the monitor

          · %MET%       Total number of events for the monitor

          · %MEH%       Number of events for the monitor in the last hour

          · %MED%       Number of events for the monitor in the last day

          · %MEW%      Number of events for the monitor in the last week

          · %MEM%      Number of events for the monitor in the last month

          · %MEA%       Number of archived events for the monitor

          · %MP%         Path to the monitor window

          · %MPS%       Path to the monitor stream

          · %MPI%        Path to the monitor recent image

          · %FN%          Name of the current filter that matched

          · %FP%          Path to the current filter that matched

          · %ZP%          Path to your ZoneMinder console

          Finally you can also specify a script which is run on each matched event.  This  script
          should  be  readable  and  executable by your web server user. It will get run once per
          event and the relative path to the directory containing the event in question. Normally
          this  will be of the form <MonitorName>/<EventId> so from this path you can derive both
          the monitor name and event id and perform any action  you  wish.  Note  that  arbitrary
          commands  are not allowed to be specified in the filter, for security the only thing it
          may contain is the full path to an executable. What that contains is entirely up to you
          however.

          Filtering  is  a  powerful mechanism you can use to eliminate events that fit a certain
          pattern however in many cases modifying the zone settings  will  better  address  this.
          Where  it  really  comes  into  its  own  is generally in applying time filters, so for
          instance events that happen during  weekdays  or  at  certain  times  of  the  day  are
          highlighted, uploaded or deleted. Additionally using disk related terms in your filters
          means you can automatically create filters that delete the oldest events when your disk
          gets  full.  Be  warned however that if you use this strategy then you should limit the
          returned results to the amount of events you want deleted in each pass until  the  disk
          usage  is  at  an  acceptable level. If you do not do this then the first pass when the
          disk usage is high will match, and then delete, all events unless you have  used  other
          criteria  inside  of  limits.  ZoneMinder ships with a sample filter already installed,
          though disabled. The PurgeWhenFull filter can be used to delete the oldest events  when
          your  disk  starts  filling  up.  To use it you should select and load it in the filter
          interface, modify it to your requirements, and then save it making you sure  you  check
          the  ‘Delete  all matches’ option. This will then run in the background and ensure that
          your disk does not fill up with events.

   Saving filters
       [image]

       When saving filters, if you want the filter to run in the background make sure you  select
       the  “Run filter in background” option. When checked, ZoneMinder will make sure the filter
       is checked regularly. For example, if you want to be notified of new events by email,  you
       should  make  sure  this  is checked. Filters that are configured to run in the background
       have a “*” next to it.

       For example: [image]

   How filters actually work
       It is useful to know how filters actually work behind the scenes  in  ZoneMinder,  in  the
       event you find your filter not functioning as intended:

       · the  primary  filter  processing process in ZoneMinder is a perl file called zmfilter.pl
         which retrieves filters from the Filters database table

       · zmfilter.pl runs every FILTER_EXECUTE_INTERVAL seconds (default is 20s, can  be  changed
         in Options->System)

       · in each run, it goes through all the filters which are marked as “Run in Background” and
         if the conditions match performs the specified action

       ·

         zmfilter.pl also reloads all the filters every FILTER_RELOAD_DELAY seconds  (default  is
         300s/5mins, can be changed in Options->System)

                · So  if  you  have  just created a new filter, zmfilter will not see it till the
                  next FILTER_RELOAD_DELAY cycle

                · This is also important if you are using  “relative  times”  like  ‘now’  -  see
                  Caveat with Relative items

   Relative items in date strings
       Relative  items  adjust  a  date  (or  the  current date if none) forward or backward. The
       effects of relative items accumulate. Here are some examples:

          * 1 year
          * 1 year ago
          * 3 years
          * 2 days

       The unit of time displacement may be selected by the string ‘year’ or ‘month’  for  moving
       by  whole years or months. These are fuzzy units, as years and months are not all of equal
       duration. More precise units are ‘fortnight’ which is worth 14 days, ‘week’ worth 7  days,
       ‘day’  worth  24  hours,  ‘hour’ worth 60 minutes, ‘minute’ or ‘min’ worth 60 seconds, and
       ‘second’ or ‘sec’ worth one second. An ‘s’ suffix on these units is accepted and ignored.

       The unit of time may be preceded by a multiplier, given as an  optionally  signed  number.
       Unsigned  numbers  are  taken  as  positively  signed.  No  number  at all implies 1 for a
       multiplier. Following a relative item by the string ‘ago’ is equivalent to  preceding  the
       unit by a multiplier with value -1.

       The  string  ‘tomorrow’  is  worth one day in the future (equivalent to ‘day’), the string
       ‘yesterday’ is worth one day in the past (equivalent to ‘day ago’).

       The strings ‘now’  or  ‘today’  are  relative  items  corresponding  to  zero-valued  time
       displacement,  these strings come from the fact a zero-valued time displacement represents
       the current time when not otherwise changed by previous items. They may be used to  stress
       other  items,  like  in  ‘12:00  today’.  The  string  ‘this’  also  has  the meaning of a
       zero-valued time displacement, but is preferred in date strings like ‘this thursday’.

       When a relative item causes the resulting date to cross a boundary where the  clocks  were
       adjusted,  typically  for  daylight  saving time, the resulting date and time are adjusted
       accordingly.

       The fuzz in units can cause problems with relative  items.  For  example,  ‘2003-07-31  -1
       month’  might  evaluate to 2003-07-01, because 2003-06-31 is an invalid date. To determine
       the previous month more reliably, you can ask for the month before the 15th of the current
       month. For example:

          $ date -R

          Thu, 31 Jul 2003 13:02:39 -0700

          $ date --date='-1 month' +'Last month was %B?'

          Last month was July?

          $ date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B!'

          Last month was June!

       As this applies to ZoneMinder filters, you might want to search  for events in a period of
       time, or maybe for example create a purge filter that removes events older than  30  days.
       For the later you would want at least two lines in your filter. The first line should be:
          [<Archive Status> <equal to> <Unarchived Only>]

       as you don’t want to delete your archived events.

       Your second line to find events older than 30 days would be:
          [and <Date><less than> -30 days]

       You  use  “less than” to indicate that you want to match events before the specified date,
       and you specify “-30 days” to indicate a date 30 days before the time the filter  is  run.
       Of course you could use 30 days ago as well(?).

       You should always test your filters before enabling any actions based on them to make sure
       they consistently return the results you want. You can use the submit button to  see  what
       events are returned by your query.

   Caveat with Relative items
       One  thing  to  remember  if you specify relative dates like “now” or “1 minute ago”, etc,
       they are converted  to  a  specific  date  and  time  by  Zoneminder’s  filtering  process
       (zmfilter.pl)  when the filters are loaded. They are _NOT_ recomputed each time the filter
       runs. Filters are re-loaded  depending  on  the  value  specified  by  FILTER_RELOAD_DELAY
       variable in  the Zoneminder Web Console->Options->System

       This  may  cause confusion in the following cases, for example: Let’s say a user specifies
       that he wants to be notified of events via email the moment the event “DateTime” is  “less
       than”  “now”  as a filter criteria. When the filter first gets loaded by zmfilter.pl, this
       will translate to “Match events where Start Time < ” + localtime() where local time is the
       time  that  is  resolved  when  this filter gets loaded. Now till the time the filter gets
       reloaded after FILTER_RELOAD_DELAY seconds (which is usually set  to  300  seconds,  or  5
       minutes), that time does not get recomputed, so the filter will not process any new events
       that occur after that computed date till another 5 minutes, which is probably not what you
       want.

   Troubleshooting tips
       If your filter is not working, here are some useful tips:

       · Look at Info and Debug logs in Zoneminder

       · Run sudo zmfilter.pl -f <yourfiltername> from command line and see the log output

       · Check  how long your action is taking - zmfilter.pl will wait for the action to complete
         before it checks again

       · If you are using relative times like ‘now’ or ‘1 year ago’ etc. remember  that  zmfilter
         converts  that  relative time to an absolute date only when it reloads filters, which is
         dictated by the FILTER_RELOAD_DELAY duration. So, for example, if you are wondering  why
         your  events are not being detected before intervals of 5 minutes and you have used such
         a relative condition, this is why

       · In the event that you see your new filter is working great when you try it out from  the
         Web  Console  (using  the  Submit  or Execute button) but does not seem to work when its
         running in background mode, you might have  just  chanced  upon  a  compatibility  issue
         between  how  Perl and PHP translate free form text to dates/times. When you test it via
         the “Submit” or “Execute” button, you are invoking a PHP function for  time  conversion.
         When  the  filter runs in background mode, zmfilter.pl calls a perl equivalent function.
         In some cases, depending on the version of Perl and PHP you have, the results may  vary.
         If  you  face  this  situation,  the  best  thing  to  do  is to run sudo zmfilter.pl -f
         <yourfiltername> from a terminal to make sure the filter actually works in Perl as well.

   Viewing Events
       From the monitor or filtered events listing you can now click on an event to  view  it  in
       more detail.

       This is an example view that shows events for a specific monitor: [image]

       If  you  have streaming capability you will see a series of images that make up the event.
       Under that you should also see a progress bar. Depending on your configuration  this  will
       either  be  static  or will be filled in to indicate how far through the event you are. By
       default this functionality is turned off for low bandwidth settings as the image  delivery
       tends  to not be able to keep up with real-time and the progress bar cannot take this into
       account. Regardless of whether the progress bar updates, you can click on it  to  navigate
       to particular points in the events.

       You  will  also  see a link to allow you to view the still images themselves. If you don’t
       have streaming then you will be taken directly to this page.  The  images  themselves  are
       thumbnail  size  and  depending  on  the  configuration and bandwidth you have chosen will
       either be the full images scaled in your browser of actual scaled images.  If  it  is  the
       latter,  if  you have low bandwidth for example, it may take a few seconds to generate the
       images. If thumbnail images are required to be  generated,  they  will  be  kept  and  not
       re-generated  in  future.  Once the images appear you can mouse over them to get the image
       sequence number and the image score.

       Here is an example of viewing an event stream: [image]

       · A: Administrative Event options on the event including viewing individual frames

       · B: The actual image stream

       · C: Navigation control

       · D: You can switch between watching a single event or Continuous mode (where it  advances
         to the next event after playback is complete)

       · E: Event progress bar - how much of the current event has been played back

       You  will notice for the first time that alarm images now contain an overlay outlining the
       blobs that represent the alarmed area. This outline is in the colour defined for that zone
       and lets you see what it was that caused the alarm. Clicking on one of the thumbnails will
       take you to a full size window where you can see the image in all its  detail  and  scroll
       through  the  various images that make up the event. If you have the ZM_RECORD_EVENT_STATS
       option on, you will be able to click the ‘Stats’ link here and get some  analysis  of  the
       cause of the event.

   More details on the Administrative Event options (A)
       Should  you determine that you don’t wish to keep the event, clicking on Delete will erase
       it from the database and file system. Returning to the event window,  other  options  here
       are  renaming  the event to something more meaningful, refreshing the window to replay the
       event stream, deleting the event, switching between streamed and  still  versions  of  the
       event (if supported) and generating an MPEG video of the event (if supported).

       These  last  two  options require further explanation. Archiving an event means that it is
       kept to one side and not displayed in the normal event listings  unless  you  specifically
       ask  to  view the archived events. This is useful for keeping events that you think may be
       important or just wish to protect. Once  an  event  is  archived  it  can  be  deleted  or
       unarchived but you cannot accidentally delete it when viewing normal unarchived events.

       The  final  option  of  generating  an  MPEG  video is still somewhat experimental and its
       usefulness may vary. It uses the open source ffmpeg  encoder  to  generate  short  videos,
       which  will  be  downloaded  to  your  browsing machine or viewed in place. When using the
       ffmpeg encoder, ZoneMinder will attempt to match  the  duration  of  the  video  with  the
       duration  of  the event. Ffmpeg has a particularly rich set of options and you can specify
       during configuration which additional options  you  may  wish  to  include  to  suit  your
       preferences.  In  particular  you may need to specify additional, or different, options if
       you are creating videos of events with particularly slow frame rates as some  codecs  only
       support  certain  ranges  of  frame  rates. A common value for FFMPEG_OUTPUT_OPTIONS under
       Options > Images might be '-r 25 -b 800k' for 25 fps  and  800  kbps.   Details  of  these
       options  can  be  found  in the documentation for the encoders and is outside the scope of
       this document.

       Building an MPEG video, especially for a large event, can take some time and should not be
       undertaken  lightly as the effect on your host box of many CPU intensive encoders will not
       be good. However once a video has been created for an event it will be kept so  subsequent
       viewing  will  not  incur  the  generation  overhead.  Videos  can  also  be  included  in
       notification emails, however care should be taken when  using  this  option  as  for  many
       frequent events the penalty in CPU and disk space can quickly mount up.

   Options
       The  various  options  you can specify are displayed in a tabbed dialog with each group of
       options displayed under a different heading. Each option is displayed  with  its  name,  a
       short description and the current value. You can also click on the ‘?’ link following each
       description to get a fuller explanation about each option. This is the same as  you  would
       get  from  zmconfig.pl.  A number of option groups have a master option near the top which
       enables or disables the whole group so you should be aware of the  state  of  this  before
       modifying options and expecting them to make any difference.

       If  you  have  changed  the  value of an option you should then ‘save’ it. A number of the
       option groups will then prompt you to let you know that the  option(s)  you  have  changed
       will require a system restart. This is not done automatically in case you will be changing
       many values in the same session, however once you have made all of your changes you should
       restart  ZoneMinder  as soon as possible. The reason for this is that web and some scripts
       will pick up the new changes immediately but some of the daemons will still be  using  the
       old values and this can lead to data inconsistency or loss.

   Options - Display
       [image]

       This  option  screen  allows  user  to select the skin for ZoneMinder. Currently available
       skins are:

       · Classic

       · Flat

       · XML (Deprecated in favour of web/API)

       · Mobile (Deprecated)

   Options - System
       [image]

       LANG_DEFAULT - ZoneMinder allows the web interface to use languages other than English  if
       the  appropriate  language file has been created and is present. This option allows you to
       change the default language that is used from the shipped language,  British  English,  to
       another language.

       OPT_USE_AUTH   -   ZoneMinder   can  run  in  two  modes.  The  simplest  is  an  entirely
       unauthenticated mode where anyone can access ZoneMinder and perform  all  tasks.  This  is
       most  suitable for installations where the web server access is limited in other ways. The
       other mode enables user accounts with varying sets of permissions.  Users  must  login  or
       authenticate   to  access  ZoneMinder  and  are  limited  by  their  defined  permissions.
       Authenticated mode  alone  should  not  be  relied  up  for  securing  Internet  connected
       ZoneMinder.

       AUTH_TYPE  -  ZoneMinder  can  use  two  methods  to  authenticate  users  when running in
       authenticated mode. The first is a builtin method where ZoneMinder provides facilities for
       users  to  log  in  and  maintains  track  of  their  identity.  The  second method allows
       interworking with other  methods  such  as  http  basic  authentication  which  passes  an
       independently authentication ‘remote’ user via http. In this case ZoneMinder would use the
       supplied user without additional authentication provided such a  user  is  configured  ion
       ZoneMinder.

       AUTH_RELAY  -  When  ZoneMinder  is running in authenticated mode it can pass user details
       between the web pages and the back end processes. There are two methods  for  doing  this.
       This  first  is  to  use a time limited hashed string which contains no direct username or
       password details, the second method is to  pass  the  username  and  passwords  around  in
       plaintext.  This  method  is  not recommend except where you do not have the md5 libraries
       available on your system or you have a completely isolated system with no external access.
       You can also switch off authentication relaying if your system is isolated in other ways.

       AUTH_HASH_SECRET - When ZoneMinder is running in hashed authenticated mode it is necessary
       to generate hashed strings containing encrypted sensitive information  such  as  usernames
       and  password. Although these string are reasonably secure the addition of a random secret
       increases security substantially.

       AUTH_HASH_IPS - When ZoneMinder is running in hashed authenticated mode it can  optionally
       include  the  requesting  IP  address  in  the resultant hash. This adds an extra level of
       security as only requests from that address may use that authentication  key.  However  in
       some circumstances, such as access over mobile networks, the requesting address can change
       for each request which will cause most requests to fail. This option allows you to control
       whether  IP  addresses  are  included  in  the  authentication hash on your system. If you
       experience intermitent problems with authentication, switching this option off may help.

       AUTH_HASH_LOGINS - The normal process for logging into ZoneMinder is via the login  screen
       with  username  and  password.  In  some circumstances it may be desirable to allow access
       directly to one or more pages, for instance from a third party application. If this option
       is  enabled  then  adding an ‘auth’ parameter to any request will include a shortcut login
       bypassing the login screen, if not already logged in. As authentication  hashes  are  time
       and,  optionally,  IP limited, this can allow short-term access to ZoneMinder screens from
       other web pages etc. In order to use this, the calling application will have  to  generate
       the  authentication  hash itself and ensure it is valid. If you use this option you should
       ensure that you have modified the ZM_AUTH_HASH_SECRET to something unique to your system.

       OPT_FAST_DELETE - Normally an event created as the result of an alarm consists of  entries
       in  one  or  more database tables plus the various files associated with it. When deleting
       events in the browser it can take a long time to remove all of this if your are trying  to
       do  a  lot  of events at once. It is recommended that you set this option which means that
       the browser client only deletes the key entries in  the  events  table,  which  means  the
       events will no longer appear in the listing, and leaves the zmaudit daemon to clear up the
       rest later.

       FILTER_RELOAD_DELAY - ZoneMinder allows you to save filters to the  database  which  allow
       events  that match certain criteria to be emailed, deleted or uploaded to a remote machine
       etc. The zmfilter daemon loads these and does the actual operation. This option determines
       how often in seconds the filters are reloaded from the database to get the latest versions
       or new filters. If you don’t change filters very often this value can be set  to  a  large
       value.

       FILTER_EXECUTE_INTERVAL  -  ZoneMinder  allows  you  to save filters to the database which
       allow events that match certain criteria to be emailed, deleted or uploaded  to  a  remote
       machine  etc.  The  zmfilter daemon loads these and does the actual operation. This option
       determines how often the filters are executed on the saved event in the database.  If  you
       want  a  rapid  response  to  new  events this should be a smaller value, however this may
       increase the overall load on the system and affect performance of other elements.

       MAX_RESTART_DELAY - The zmdc (zm daemon control) process  controls  when  processeses  are
       started or stopped and will attempt to restart any that fail. If a daemon fails frequently
       then a delay is introduced between each restart attempt. If the daemon stills  fails  then
       this  delay  is  increased  to  prevent extra load being placed on the system by continual
       restarts. This option controls what this maximum delay is.

       WATCH_CHECK_INTERVAL - The zmwatch daemon checks the  image  capture  performance  of  the
       capture  daemons  to  ensure  that  they have not locked up (rarely a sync error may occur
       which blocks indefinitely). This option determines how often the daemons are checked.

       WATCH_MAX_DELAY - The zmwatch daemon checks the image capture performance of  the  capture
       daemons to ensure that they have not locked up (rarely a sync error may occur which blocks
       indefinitely). This option determines the maximum delay to allow since the  last  captured
       frame.  The  daemon  will be restarted if it has not captured any images after this period
       though the actual restart may take slightly longer in conjunction with the check  interval
       value above.

       RUN_AUDIT  - The zmaudit daemon exists to check that the saved information in the database
       and on the filesystem match and are consistent with each other. If an error occurs  or  if
       you are using ‘fast deletes’ it may be that database records are deleted but files remain.
       In this case, and similar, zmaudit will remove redundant information  to  synchronise  the
       two  data  stores.  This  option  controls  whether  zmaudit  is run in the background and
       performs these checks and fixes continuously. This is recommended for most systems however
       if  you  have  a  very  large  number  of  events the process of scanning the database and
       filesystem may take a long time and impact performance. In this case you may prefer to not
       have  zmaudit  running  unconditionally  and  schedule  occasional  checks  at other, more
       convenient, times.

       AUDIT_CHECK_INTERVAL - The zmaudit daemon exists to check that the  saved  information  in
       the  database  and on the filesystem match and are consistent with each other. If an error
       occurs or if you are using ‘fast deletes’ it may be that database records are deleted  but
       files  remain.  In  this  case,  and similar, zmaudit will remove redundant information to
       synchronise the two data stores. The default check interval of 900 seconds (15 minutes) is
       fine  for  most  systems  however if you have a very large number of events the process of
       scanning the database and filesystem may take a long time and impact performance. In  this
       case you may prefer to make this interval much larger to reduce the impact on your system.
       This option determines how often these checks are performed.

       OPT_CONTROL - ZoneMinder includes limited support for controllable cameras.  A  number  of
       sample  protocols are included and others can easily be added. If you wish to control your
       cameras via ZoneMinder then select this option otherwise if you only have  static  cameras
       or use other control methods then leave this option off.

       OPT_TRIGGERS  -  ZoneMinder  can  interact  with  external  systems which prompt or cancel
       alarms. This is done via the zmtrigger.pl script. This option indicates whether  you  want
       to use these external triggers. Most people will say no here.

       CHECK_FOR_UPDATES - From ZoneMinder version 1.17.0 onwards new versions are expected to be
       more frequent. To save checking manually for each new version ZoneMinder  can  check  with
       the  zoneminder.com  website  to  determine  the  most  recent  release.  These checks are
       infrequent, about once per week, and no personal  or  system  information  is  transmitted
       other  than  your current version number. If you do not wish these checks to take place or
       your ZoneMinder system has no internet access you can switch these  check  off  with  this
       configuration variable

       UPDATE_CHECK_PROXY  -  If  you use a proxy to access the internet then ZoneMinder needs to
       know so it can access zoneminder.com to check for updates. If you do use a proxy enter the
       full proxy url here in the form of http://<proxy host>:<proxy port>/

       SHM_KEY  -  ZoneMinder  uses  shared  memory to speed up communication between modules. To
       identify the right area to use shared memory keys are used. This option controls what  the
       base  key  is,  each monitor will have it’s Id or’ed with this to get the actual key used.
       You will not normally need to change this value unless it clashes with another instance of
       ZoneMinder  on  the  same machine. Only the first four hex digits are used, the lower four
       will be masked out and ignored.

   Options - Config
       [image]

       TIMESTAMP_ON_CAPTURE - ZoneMinder can add a timestamp to images in two ways.  The  default
       method,  when  this  option  is  set,  is  that each image is timestamped immediately when
       captured and so the image held in memory is marked right away. The second method does  not
       timestamp  the images until they are either saved as part of an event or accessed over the
       web. The timestamp used in both methods will contain the same time as  this  is  preserved
       along  with the image. The first method ensures that an image is timestamped regardless of
       any other circumstances but will result in all images being timestamped even  those  never
       saved  or viewed. The second method necessitates that saved images are copied before being
       saved otherwise two timestamps perhaps at different scales may be applied.  This  has  the
       (perhaps)  desirable  side  effect  that  the  timestamp  is  always  applied  at the same
       resolution so an image that has scaling applied will still have a  legible  and  correctly
       scaled timestamp.

       CPU_EXTENSIONS  -  When advanced processor extensions such as SSE2 or SSSE3 are available,
       ZoneMinder can use them,  which  should  increase  performance  and  reduce  system  load.
       Enabling  this option on processors that do not support the advanced processors extensions
       used by ZoneMinder is harmless and will have no effect.

       FAST_IMAGE_BLENDS - To detect alarms ZoneMinder needs to blend the captured image with the
       stored  reference  image  to  update  it for comparison with the next image. The reference
       blend percentage specified for the monitor controls how much the  new  image  affects  the
       reference  image. There are two methods that are available for this. If this option is set
       then fast calculation which does not use any multiplication  or  division  is  used.  This
       calculation  is  extremely  fast, however it limits the possible blend percentages to 50%,
       25%, 12.5%, 6.25%, 3.25% and 1.5%. Any other blend  percentage  will  be  rounded  to  the
       nearest  possible  one.  The  alternative  is  to  switch this option off and use standard
       blending instead, which is slower.

       OPT_ADAPTIVE_SKIP - In previous versions of ZoneMinder the analysis daemon  would  attempt
       to  keep  up  with  the capture daemon by processing the last captured frame on each pass.
       This would sometimes have the undesirable side-effect of missing a chunk  of  the  initial
       activity  that  caused the alarm because the pre-alarm frames would all have to be written
       to disk and the database before processing the next frame, leading to some  delay  between
       the  first and second event frames. Setting this option enables a newer adaptive algorithm
       where the analysis daemon attempts to process as many captured frames  as  possible,  only
       skipping  frames  when  in  danger  of  the capture daemon overwriting yet to be processed
       frames. This skip is variable depending on the size of the ring buffer and the  amount  of
       space left in it. Enabling this option will give you much better coverage of the beginning
       of alarms whilst biasing out any skipped frames towards the middle or end  of  the  event.
       However  you  should be aware that this will have the effect of making the analysis daemon
       run somewhat behind the capture daemon during events and for particularly  fast  rates  of
       capture  it  is possible for the adaptive algorithm to be overwhelmed and not have time to
       react to a rapid build up of pending frames and thus for a  buffer  overrun  condition  to
       occur.

       MAX_SUSPEND_TIME  -  ZoneMinder  allows monitors to have motion detection to be suspended,
       for instance while panning a camera. Ordinarily  this  relies  on  the  operator  resuming
       motion  detection  afterwards  as  failure  to  do so can leave a monitor in a permanently
       suspended state. This setting allows you to set a maximum  time  which  a  camera  may  be
       suspended  for before it automatically resumes motion detection. This time can be extended
       by subsequent suspend indications after the first so continuous camera movement will  also
       occur while the monitor is suspended.

       STRICT_VIDEO_CONFIG  -  With  some  video  devices  errors  can be reported in setting the
       various video attributes when in fact the operation was successful. Switching this  option
       off will still allow these errors to be reported but will not cause them to kill the video
       capture daemon. Note however that doing this will cause all errors to be ignored including
       those  which  are genuine and which may cause the video capture to not function correctly.
       Use this option with caution.

       SIGNAL_CHECK_POINTS - For locally attached video cameras ZoneMinder can check  for  signal
       loss  by  looking  at  a  number  of random points on each captured image. If all of these
       points are set to the same fixed colour then the camera is assumed to  have  lost  signal.
       When  this  happens  any open events are closed and a short one frame signal loss event is
       generated, as is another when the signal returns. This option defines how many  points  on
       each  image  to check. Note that this is a maximum, any points found to not have the check
       colour will abort any further checks so in most cases on a couple of points will  actually
       be checked. Network and file based cameras are never checked.

       V4L_MULTI_BUFFER  -  Performance  when  using  Video  4  Linux  devices is usually best if
       multiple buffers are used allowing the next image to be captured while the previous one is
       being  processed.  If  you have multiple devices on a card sharing one input that requires
       switching then this approach can sometimes cause frames from one source  to  be  mixed  up
       with  frames from another. Switching this option off prevents multi buffering resulting in
       slower but more stable image capture. This option is ignored for non-local cameras  or  if
       only  one  input  is present on a capture chip. This option addresses a similar problem to
       the ZM_CAPTURES_PER_FRAME option and you should normally change the value of only  one  of
       the options at a time.  If you have different capture cards that need different values you
       can ovveride them in each individual monitor on the source page.

       CAPTURES_PER_FRAME - If you are using cameras attached  to  a  video  capture  card  which
       forces  multiple  inputs  to  share one capture chip, it can sometimes produce images with
       interlaced frames reversed resulting in poor image quality and  a  distinctive  comb  edge
       appearance.  Increasing  this setting allows you to force additional image captures before
       one is selected as the captured frame. This allows the capture hardware to  ‘settle  down’
       and produce better quality images at the price of lesser capture rates. This option has no
       effect on (a) network cameras, or (b) where multiple inputs do not share a  capture  chip.
       This  option  addresses a similar problem to the ZM_V4L_MULTI_BUFFER option and you should
       normally change the value of only one of the options at a time.   If  you  have  different
       capture  cards that need different values you can ovveride them in each individual monitor
       on the source page.

       FORCED_ALARM_SCORE - The ‘zmu’ utility can be used to force an alarm on a  monitor  rather
       than  rely  on  the motion detection algorithms. This option determines what score to give
       these alarms to distinguish them from regular ones. It must be 255 or less.

       BULK_FRAME_INTERVAL - Traditionally ZoneMinder writes an entry into  the  Frames  database
       table  for  each  frame  that  is  captured and saved. This works well in motion detection
       scenarios but when in a DVR situation (‘Record’ or ‘Mocord’ mode) this results in  a  huge
       number of frame writes and a lot of database and disk bandwidth for very little additional
       information. Setting this to a non-zero value  will  enabled  ZoneMinder  to  group  these
       non-alarm frames into one ‘bulk’ frame entry which saves a lot of bandwidth and space. The
       only disadvantage of this is that timing information for individual frames is lost but  in
       constant frame rate situations this is usually not significant. This setting is ignored in
       Modect mode and individual frames are still written if an  alarm  occurs  in  Mocord  mode
       also.

       EVENT_CLOSE_MODE  -  When  a  monitor is running in a continuous recording mode (Record or
       Mocord) events are usually closed after a fixed  period  of  time  (the  section  length).
       However  in  Mocord  mode it is possible that motion detection may occur near the end of a
       section. This option controls what happens when an alarm occurs in Mocord mode. The ‘time’
       setting  means that the event will be closed at the end of the section regardless of alarm
       activity. The ‘idle’ setting means that the event will be closed at the end of the section
       if  there  is no alarm activity occurring at the time otherwise it will be closed once the
       alarm is over meaning the event may end up being longer than the  normal  section  length.
       The  ‘alarm’  setting  means  that  if an alarm occurs during the event, the event will be
       closed once the alarm is over regardless of when this  occurs.  This  has  the  effect  of
       limiting  the  number  of  alarms to one per event and the events will be shorter than the
       section length if an alarm has occurred.

       CREATE_ANALYSIS_IMAGES - By default during  an  alarm  ZoneMinder  records  both  the  raw
       captured  image  and  one  that  has been analysed and had areas where motion was detected
       outlined. This can be very useful during zone configuration or  in  analysing  why  events
       occurred.  However  it  also  incurs some overhead and in a stable system may no longer be
       necessary. This parameter allows you to switch the generation of these images off.

       WEIGHTED_ALARM_CENTRES - ZoneMinder will always calculate the centre point of an alarm  in
       a  zone  to  give  some  indication  of where on the screen it is. This can be used by the
       experimental motion tracking feature or your own custom  extensions.  In  the  alarmed  or
       filtered pixels mode this is a simple midpoint between the extents of the detected pxiesl.
       However in the blob method this can instead be calculated using weighted  pixel  locations
       to  give  more  accurate positioning for irregularly shaped blobs. This method, while more
       precise is also slower and so is turned off by default.

       EVENT_IMAGE_DIGITS - As event images are captured they are stored to the filesystem with a
       numerical index. By default this index has three digits so the numbers start 001, 002 etc.
       This works works for most scenarios as  events  with  more  than  999  frames  are  rarely
       captured. However if you have extremely long events and use external applications then you
       may wish to increase this to ensure correct sorting of images in  listings  etc.  Warning,
       increasing  this value on a live system may render existing events unviewable as the event
       will have been saved with the previous scheme. Decreasing this value should  have  no  ill
       effects.

       DEFAULT_ASPECT_RATIO - When specifying the dimensions of monitors you can click a checkbox
       to ensure that the width stays in the correct ratio to the height,  or  vice  versa.  This
       setting  allows you to indicate what the ratio of these settings should be. This should be
       specified in the format <width value>:<height value> and the default of  4:3  normally  be
       acceptable  but  11:9  is  another  common  setting.  If  the checkbox is not clicked when
       specifying monitor dimensions this setting has no effect.

       USER_SELF_EDIT - Ordinarily only users with system edit privilege are able to change users
       details.  Switching  this  option  on  allows ordinary users to change their passwords and
       their language settings

   Options - Servers
       [image]

       Servers tab is used for setting up multiple ZoneMinder servers sharing the  same  database
       and  using  a shared file share for all event data. To add a new server use the Add Server
       button. All that is required is a Name for the Server and Hostname.

       To delete a server mark that server and click the Delete button.

       Please note that all servers must have a functional web UI as the live view must come from
       the monitor’s host server.

       On each server, you will have to edit /etc/zm/zm.conf and set either ZM_SERVER_NAME=

   Options - Paths
       [image]

       ZM_DIR_EVENTS  -  This  is the path to the events directory where all the event images and
       other miscellaneous files are stored. CAUTION: The directory you specify  here  cannot  be
       outside the web root. This is a common mistake. Most users should never change this value.
       If you intend to record events to a second disk or network share, then  you  should  mount
       the  drive or share directly to the ZoneMinder events folder or follow the instructions in
       the ZoneMinder Wiki titled Using a dedicated Hard Drive.

       USE_DEEP_STORAGE - Traditionally ZoneMinder  stores  all  events  for  a  monitor  in  one
       directory  for  that monitor. This is simple and efficient except when you have very large
       amounts of events. Some filesystems are unable  to  store  more  than  32k  files  in  one
       directory and even without this limitation, large numbers of files in a directory can slow
       creation and deletion of files. This option allows you to select an  alternate  method  of
       storing events by year/month/day/hour/min/second which has the effect of separating events
       out into more directories, resulting in less per directory, and also making it  easier  to
       manually navigate to any events that may have happened at a particular time or date.

       DIR_IMAGES  - ZoneMinder generates a myriad of images, mostly of which are associated with
       events. For those that aren’t this is where they go. CAUTION: The  directory  you  specify
       here  cannot  be  outside  the web root. This is a common mistake. Most users should never
       change this value. If you intend to save images to a second disk or  network  share,  then
       you should mount the drive or share directly to the ZoneMinder images folder or follow the
       instructions in the ZoneMinder Wiki titled Using a dedicated Hard Drive.

       DIR_SOUNDS - ZoneMinder can optionally play a sound file when an alarm is  detected.  This
       indicates  where  to look for this file. CAUTION: The directory you specify here cannot be
       outside the web root. Most users should never change this value.

       PATH_ZMS - The ZoneMinder streaming server is required to send  streamed  images  to  your
       browser.  It  will  be  installed  into the cgi-bin path given at configuration time. This
       option determines what the web path to the server is rather than the local  path  on  your
       machine.  Ordinarily  the  streaming  server  runs  in  parser-header  mode however if you
       experience problems with streaming you can change this to non-parsed-header (nph) mode  by
       changing ‘zms’ to ‘nph-zms’.

       PATH_MAP  -  ZoneMinder  has  historically  used IPC shared memory for shared data between
       processes. This has it’s advantages and limitations. This version of ZoneMinder can use an
       alternate  method,  mapped  memory,  instead  with  can  be  enabled with the –enable–mmap
       directive to configure. This requires less system  configuration  and  is  generally  more
       flexible. However it requires each shared data segment to map onto a filesystem file. This
       option indicates where those mapped files go. You should ensure  that  this  location  has
       sufficient  space  for  these files and for the best performance it should be a tmpfs file
       system or ramdisk otherwise disk access may render this method  slower  than  the  regular
       shared memory one.

       PATH_SOCKS  -  ZoneMinder  generally uses Unix domain sockets where possible. This reduces
       the  need  for  port  assignments  and  prevents  external  applications   from   possibly
       compromising  the  daemons.  However each Unix socket requires a .sock file to be created.
       This option indicates where those socket files go.

       PATH_LOGS - There are various daemons that are  used  by  ZoneMinder  to  perform  various
       tasks.  Most  generate helpful log files and this is where they go. They can be deleted if
       not required for debugging.

       PATH_SWAP - Buffered playback requires  temporary  swap  images  to  be  stored  for  each
       instance  of  the  streaming  daemons.  This  option determines where these images will be
       stored. The images will actually be stored in sub directories beneath  this  location  and
       will be automatically cleaned up after a period of time.

   Options - Web
       [image]

       WEB_TITLE_PREFIX  - If you have more than one installation of ZoneMinder it can be helpful
       to display different titles for each one. Changing this option allows you to customise the
       window titles to include further information to aid identification.

       WEB_RESIZE_CONSOLE  -  Traditionally  the  main  ZoneMinder web console window has resized
       itself to shrink to a size small enough to  list  only  the  monitors  that  are  actually
       present.  This is intended to make the window more unobtrusize but may not be to everyones
       tastes, especially if opened in a tab in browsers  which  support  this  kind  if  layout.
       Switch this option off to have the console window size left to the users preference

       WEB_POPUP_ON_ALARM  -  When viewing a live monitor stream you can specify whether you want
       the window to pop to the front if an alarm occurs when the window is minimised  or  behind
       another  window. This is most useful if your monitors are over doors for example when they
       can pop up if someone comes to the doorway.

       WEB_SOUND_ON_ALARM - When viewing a live monitor stream you can specify whether  you  want
       the window to play a sound to alert you if an alarm occurs.

       WEB_ALARM_SOUND  -  You can specify a sound file to play if an alarm occurs whilst you are
       watching a live monitor stream. So long as your browser understands the format it does not
       need to be any particular type. This file should be placed in the sounds directory defined
       earlier.

       WEB_COMPACT_MONTAGE - The montage view shows the output of all of your active monitors  in
       one  window.  This  include  a  small  menu  and status information for each one. This can
       increase the web traffic and make the window larger than  may  be  desired.  Setting  this
       option on removes all this extraneous information and just displays the images.

       WEB_EVENT_SORT_FIELD  - Events in lists can be initially ordered in any way you want. This
       option controls what field is used to sort them. You can modify this ordering from filters
       or  by  clicking on headings in the lists themselves. Bear in mind however that the ‘Prev’
       and ‘Next’ links, when scrolling through events, relate to the ordering in the  lists  and
       so not always to time based ordering.

       WEB_EVENT_SORT_ORDER  - Events in lists can be initially ordered in any way you want. This
       option controls what order (ascending or descending) is used to sort them. You can  modify
       this  ordering  from  filters  or by clicking on headings in the lists themselves. Bear in
       mind however that the ‘Prev’ and ‘Next’ links, when scrolling through  events,  relate  to
       the ordering in the lists and so not always to time based ordering.

       WEB_EVENTS_PER_PAGE - In the event list view you can either list all events or just a page
       at a time. This option controls how many events are listed per page in paged mode and  how
       often to repeat the column headers in non-paged mode.

       WEB_LIST_THUMBS  -  Ordinarily  the event lists just display text details of the events to
       save space and time. By switching this option on you can also display small thumbnails  to
       help  you  identify  events of interest. The size of these thumbnails is controlled by the
       following two options.

       WEB_LIST_THUMB_WIDTH - This options controls the width of the thumbnail images that appear
       in the event lists. It should be fairly small to fit in with the rest of the table. If you
       prefer you can specify a height instead in the next option but you should only use one  of
       the  width  or height and the other option should be set to zero. If both width and height
       are specified then width will be used and height ignored.

       WEB_LIST_THUMB_HEIGHT - This options controls the height  of  the  thumbnail  images  that
       appear in the event lists. It should be fairly small to fit in with the rest of the table.
       If you prefer you can specify a width instead in the previous option but you  should  only
       use  one  of the width or height and the other option should be set to zero. If both width
       and height are specified then width will be used and height ignored.

       WEB_USE_OBJECT_TAGS - There are two methods of including media content in web  pages.  The
       most  common way is use the EMBED tag which is able to give some indication of the type of
       content. However this is not a standard part of HTML. The official method is to use OBJECT
       tags  which are able to give more information allowing the correct media viewers etc to be
       loaded. However these are less widely supported and content may be  specifically  tailored
       to a particular platform or player. This option controls whether media content is enclosed
       in EMBED tags only or whether, where appropriate, it is  additionally  wrapped  in  OBJECT
       tags.  Currently  OBJECT  tags are only used in a limited number of circumstances but they
       may become more widespread in the future. It is suggested that you leave  this  option  on
       unless you encounter problems playing some content.

   Options - Images
       [image]

       OPT_FFMPEG  -  ZoneMinder  can  optionally  encode  a  series of video images into an MPEG
       encoded movie file for viewing, downloading or storage. This option allows you to  specify
       whether  you  have the ffmpeg tools installed. Note that creating MPEG files can be fairly
       CPU and disk intensive and is not a required option as events can  still  be  reviewed  as
       video streams without it.

       PATH_FFMPEG - This path should point to where ffmpeg has been installed.

       FFMPEG_INPUT_OPTIONS  -  Ffmpeg  can  take many options on the command line to control the
       quality of video produced. This option allows you to specify your own set  that  apply  to
       the  input  to  ffmpeg  (options  that  are  given before the -i option). Check the ffmpeg
       documentation for a full list of options which may be used here.

       FFMPEG_OUTPUT_OPTIONS - Ffmpeg can take many options on the command line  to  control  the
       quality  of  video  produced. This option allows you to specify your own set that apply to
       the output from ffmpeg (options that are given after the  -i  option).  Check  the  ffmpeg
       documentation  for a full list of options which may be used here. The most common one will
       often be to force an output frame rate supported by the video encoder.

       FFMPEG_FORMATS - Ffmpeg can generate video in many different formats. This  option  allows
       you to list the ones you want to be able to select. As new formats are supported by ffmpeg
       you can add them here and be able to use them immediately. Adding a  ‘*’  after  a  format
       indicates that this will be the default format used for web video, adding ‘**’ defines the
       default format for phone video.

       FFMPEG_OPEN_TIMEOUT - When Ffmpeg is opening a stream, it can  take  a  long  time  before
       failing;  certain  circumstances  even  seem  to be able to lock indefinitely. This option
       allows you to set a maximum time in seconds to pass before closing the stream  and  trying
       to reopen it again.

       JPEG_STREAM_QUALITY  -  When viewing a ‘live’ stream for a monitor ZoneMinder will grab an
       image from the buffer and encode it into  JPEG  format  before  sending  it.  This  option
       specifies  what image quality should be used to encode these images. A higher number means
       better quality but less compression so will take longer to view over a slow connection. By
       contrast  a  low  number  means  quicker  to view images but at the price of lower quality
       images. This option does not apply when viewing  events  or  still  images  as  these  are
       usually  just  read  from  disk  and  so  will  be encoded at the quality specified by the
       previous options.

       MPEG_TIMED_FRAMES - When using streamed MPEG based video, either for live monitor  streams
       or  events,  ZoneMinder  can send the streams in two ways. If this option is selected then
       the timestamp for each frame, taken from it’s capture time, is  included  in  the  stream.
       This means that where the frame rate varies, for instance around an alarm, the stream will
       still maintain it’s ‘real’ timing. If this option is  not  selected  then  an  approximate
       frame  rate  is calculated and that is used to schedule frames instead. This option should
       be selected unless you encounter problems with your preferred streaming method.

       MPEG_LIVE_FORMAT - When using MPEG mode ZoneMinder can output  live  video.  However  what
       formats are handled by the browser varies greatly between machines. This option allows you
       to specify a video format using a file extension format,  so  you  would  just  enter  the
       extension  of  the  file  type  you  would  like and the rest is determined from that. The
       default of ‘asf’ works well under Windows with Windows Media Player but I’m currently  not
       sure  what, if anything, works on a Linux platform. If you find out please let me know! If
       this option is left blank then live streams will revert to being in motion jpeg format

       MPEG_REPLAY_FORMAT - When using MPEG mode ZoneMinder can replay events  in  encoded  video
       format.  However  what formats are handled by the browser varies greatly between machines.
       This option allows you to specify a video format using a file  extension  format,  so  you
       would  just enter the extension of the file type you would like and the rest is determined
       from that. The default of ‘asf’ works well under Windows with  Windows  Media  Player  and
       ‘mpg’, or ‘avi’ etc should work under Linux. If you know any more then please let me know!
       If this option is left blank then live streams will revert to being in motion jpeg format

       RAND_STREAM - Some browsers can cache the streams used by ZoneMinder. In order to  prevent
       his  a  harmless  random  string can be appended to the url to make each invocation of the
       stream appear unique.

       OPT_CAMBOZOLA - Cambozola is a handy low fat cheese flavoured Java applet that  ZoneMinder
       uses  to  view  image  streams  on  browsers such as Internet Explorer that don’t natively
       support this format. If you use this browser it is highly recommended to install this from
       http://www.charliemouse.com/code/cambozola/   however  if it is not installed still images
       at a lower refresh rate can still be viewed.

       PATH_CAMBOZOLA - Cambozola is a handy low fat cheese flavoured Java applet that ZoneMinder
       uses  to  view  image  streams  on  browsers such as Internet Explorer that don’t natively
       support this format. If you use this browser it is highly recommended to install this from
       http://www.charliemouse.com/code/cambozola/   however  if it is not installed still images
       at a lower refresh rate can still be viewed. Leave this as ‘cambozola.jar’ if cambozola is
       installed in the same directory as the ZoneMinder web client files.

       RELOAD_CAMBOZOLA  -  Cambozola allows for the viewing of streaming MJPEG however it caches
       the entire stream into cache space on the computer, setting this to  a  number  >  0  will
       cause it to automatically reload after that many seconds to avoid filling up a hard drive.

       OPT_FFMPEG  -  ZoneMinder  can  optionally  encode  a  series of video images into an MPEG
       encoded movie file for viewing, downloading or storage. This option allows you to  specify
       whether  you  have the ffmpeg tools installed. Note that creating MPEG files can be fairly
       CPU and disk intensive and is not a required option as events can  still  be  reviewed  as
       video streams without it.

       PATH_FFMPEG - This path should point to where ffmpeg has been installed.

       FFMPEG_INPUT_OPTIONS  -  Ffmpeg  can  take many options on the command line to control the
       quality of video produced. This option allows you to specify your own set  that  apply  to
       the  input  to  ffmpeg  (options  that  are  given before the -i option). Check the ffmpeg
       documentation for a full list of options which may be used here.

       FFMPEG_OUTPUT_OPTIONS - Ffmpeg can take many options on the command line  to  control  the
       quality  of  video  produced. This option allows you to specify your own set that apply to
       the output from ffmpeg (options that are given after the  -i  option).  Check  the  ffmpeg
       documentation  for a full list of options which may be used here. The most common one will
       often be to force an output frame rate supported by the video encoder.

       FFMPEG_FORMATS - Ffmpeg can generate video in many different formats. This  option  allows
       you to list the ones you want to be able to select. As new formats are supported by ffmpeg
       you can add them here and be able to use them immediately. Adding a  ‘*’  after  a  format
       indicates that this will be the default format used for web video, adding ‘**’ defines the
       default format for phone video.

       FFMPEG_OPEN_TIMEOUT - When Ffmpeg is opening a stream, it can  take  a  long  time  before
       failing;  certain  circumstances  even  seem  to be able to lock indefinitely. This option
       allows you to set a maximum time in seconds to pass before closing the stream  and  trying
       to reopen it again.

   Options - Logging
       [image]

       LOG_LEVEL_SYSLOG  -  ZoneMinder logging is now more more integrated between components and
       allows you to specify the destination for logging output and  the  individual  levels  for
       each.  This  option  lets  you control the level of logging output that goes to the system
       log. ZoneMinder binaries have always logged to the system log  but  now  scripts  and  web
       logging  is also included. To preserve the previous behaviour you should ensure this value
       is set to Info or Warning. This option controls the maximum level of logging that will  be
       written, so Info includes Warnings and Errors etc. To disable entirely, set this option to
       None. You should use caution when setting this option to Debug as it can  affect  severely
       affect  system  performance.  If  you  want  debug  you  will also need to set a level and
       component below

       LOG_LEVEL_FILE - ZoneMinder logging is now more more  integrated  between  components  and
       allows  you  to  specify  the destination for logging output and the individual levels for
       each. This option lets you control the level of logging output that goes to individual log
       files  written  by specific components. This is how logging worked previously and although
       useful for tracking down issues in specific components it also resulted in many  disparate
       log  files.  To  preserve  this  behaviour  you should ensure this value is set to Info or
       Warning. This option controls the maximum level of logging that will be written,  so  Info
       includes Warnings and Errors etc. To disable entirely, set this option to None. You should
       use caution when setting this option to Debug as it  can  affect  severely  affect  system
       performance  though  file output has less impact than the other options. If you want debug
       you will also need to set a level and component below

       LOG_LEVEL_WEBLOG - ZoneMinder logging is now more more integrated between  components  and
       allows  you  to  specify  the destination for logging output and the individual levels for
       each. This option lets you control the level of logging output from the web interface that
       goes  to  the httpd error log. Note that only web logging from PHP and JavaScript files is
       included and so this option is really only useful for investigating specific  issues  with
       those  components. This option controls the maximum level of logging that will be written,
       so Info includes Warnings and Errors etc. To disable entirely, set this  option  to  None.
       You  should use caution when setting this option to Debug as it can affect severely affect
       system performance. If you want debug you will also need to  set  a  level  and  component
       below

       LOG_LEVEL_DATABASE - ZoneMinder logging is now more more integrated between components and
       allows you to specify the destination for logging output and  the  individual  levels  for
       each.  This  option  lets  you  control the level of logging output that is written to the
       database. This is a new option which can make  viewing  logging  output  easier  and  more
       intuitive  and  also  makes  it  easier  to get an overall impression of how the system is
       performing. If you have a large or very busy system then it is possible that use  of  this
       option  may  slow  your  system  down  if the table becomes very large. Ensure you use the
       LOG_DATABASE_LIMIT option to keep the table to a manageable size. This option controls the
       maximum  level  of logging that will be written, so Info includes Warnings and Errors etc.
       To disable entirely, set this option to None. You should use  caution  when  setting  this
       option to Debug as it can affect severely affect system performance. If you want debug you
       will also need to set a level and component below

       LOG_DATABASE_LIMIT - If you are using database logging then  it  is  possible  to  quickly
       build  up  a  large number of entries in the Logs table. This option allows you to specify
       how many of these entries are kept. If you set this option to a number greater  than  zero
       then  that  number  is used to determine the maximum number of rows, less than or equal to
       zero indicates no limit and is not recommended. You can also set this value to time values
       such  as ‘<n> day’ which will limit the log entries to those newer than that time. You can
       specify ‘hour’, ‘day’, ‘week’, ‘month’ and ‘year’, note that the values should be singular
       (no ‘s’ at the end). The Logs table is pruned periodically so it is possible for more than
       the expected number of rows to be present briefly in the meantime.

       LOG_DEBUG” - ZoneMinder components usually support debug logging available  to  help  with
       diagnosing  problems.  Binary  components  have several levels of debug whereas more other
       components have only one. Normally this is disabled to minimise performance penalties  and
       avoid  filling  logs  too quickly. This option lets you switch on other options that allow
       you to configure additional debug information to be output. Components will pick  up  this
       instruction when they are restarted.

       LOG_DEBUG_TARGET  -  There  are three scopes of debug available. Leaving this option blank
       means that all components will use extra debug (not recommended). Setting this  option  to
       ‘_<component>’,  e.g.  _zmc,  will  limit extra debug to that component only. Setting this
       option to ‘_<component>_<identity>’,  e.g.  ‘_zmc_m1’  will  limit  extra  debug  to  that
       instance  of the component only. This is ordinarily what you probably want to do. To debug
       scripts use their names without the .pl extension, e.g. ‘_zmvideo’  and  to  debug  issues
       with  the  web  interface  use ‘_web’. You can specify multiple targets by separating them
       with ‘|’ characters.

       LOG_DEBUG_LEVEL - There are 9 levels of debug available, with higher  numbers  being  more
       debug  and level 0 being no debug. However not all levels are used by all components. Also
       if there is debug at a high level it is usually likely to be output at such a volume  that
       it  may  obstruct normal operation. For this reason you should set the level carefully and
       cautiously until the degree of debug you wish to see  is  present.  Scripts  and  the  web
       interface only have one level so this is an on/off type option for them.

       LOG_DEBUG_FILE  -  This  option allows you to specify a different target for debug output.
       All components have a default log file which will norally be in /tmp or /var/log and  this
       is  where  debug  will  be  written  to  if  this  value is empty. Adding a path here will
       temporarily redirect debug, and other logging output, to  this  file.  This  option  is  a
       simple  filename and you are debugging several components then they will all try and write
       to the same file with undesirable consequences. Appending a ‘+’ to the filename will cause
       the  file  to  be  created  with a ‘.<pid>’ suffix containing your process id. In this way
       debug from each run of a component is kept separate. This is the recommended setting as it
       will  also  prevent  subsequent runs from overwriting the same log. You should ensure that
       permissions are set up to allow writing to the file and directory specified here.

       LOG_CHECK_PERIOD  -  When  ZoneMinder  is  logging  events  to   the   database   it   can
       retrospectively  examine the number of warnings and errors that have occurred to calculate
       an overall state of system health. This option allows  you  to  indicate  what  period  of
       historical  events are used in this calculation. This value is expressed in seconds and is
       ignored if LOG_LEVEL_DATABASE is set to None.

       LOG_ALERT_WAR_COUNT  -  When  ZoneMinder  is  logging  events  to  the  database  it   can
       retrospectively  examine the number of warnings and errors that have occurred to calculate
       an overall state of system health. This option allows you to  specify  how  many  warnings
       must  have  occurred  within  the  defined time period to generate an overall system alert
       state. A value of zero means warnings  are  not  considered.  This  value  is  ignored  if
       LOG_LEVEL_DATABASE is set to None.

       LOG_ALERT_ERR_COUNT   -  When  ZoneMinder  is  logging  events  to  the  database  it  can
       retrospectively examine the number of warnings and errors that have occurred to  calculate
       an  overall state of system health. This option allows you to specify how many errors must
       have occurred within the defined time period to generate an overall system alert state.  A
       value of zero means errors are not considered. This value is ignored if LOG_LEVEL_DATABASE
       is set to None.

       LOG_ALERT_FAT_COUNT  -  When  ZoneMinder  is  logging  events  to  the  database  it   can
       retrospectively  examine the number of warnings and errors that have occurred to calculate
       an overall state of system health. This option allows you to specify how many fatal errors
       (including  panics)  must  have  occurred  within  the  defined time period to generate an
       overall system alert state. A value of zero means fatal errors are  not  considered.  This
       value is ignored if LOG_LEVEL_DATABASE is set to None.

       LOG_ALARM_WAR_COUNT   -  When  ZoneMinder  is  logging  events  to  the  database  it  can
       retrospectively examine the number of warnings and errors that have occurred to  calculate
       an  overall  state  of  system health. This option allows you to specify how many warnings
       must have occurred within the defined time period to  generate  an  overall  system  alarm
       state.  A  value  of  zero  means  warnings  are  not considered. This value is ignored if
       LOG_LEVEL_DATABASE is set to None.

       LOG_ALARM_ERR_COUNT  -  When  ZoneMinder  is  logging  events  to  the  database  it   can
       retrospectively  examine the number of warnings and errors that have occurred to calculate
       an overall state of system health. This option allows you to specify how many errors  must
       have  occurred within the defined time period to generate an overall system alarm state. A
       value of zero means errors are not considered. This value is ignored if LOG_LEVEL_DATABASE
       is set to None.

       LOG_ALARM_FAT_COUNT   -  When  ZoneMinder  is  logging  events  to  the  database  it  can
       retrospectively examine the number of warnings and errors that have occurred to  calculate
       an overall state of system health. This option allows you to specify how many fatal errors
       (including panics) must have occurred within  the  defined  time  period  to  generate  an
       overall  system  alarm  state. A value of zero means fatal errors are not considered. This
       value is ignored if LOG_LEVEL_DATABASE is set to None.

       RECORD_EVENT_STATS - This version of ZoneMinder records detailed information about  events
       in  the  Stats  table.  This can help in profiling what the optimum settings are for Zones
       though this is tricky at present. However in future releases this will be done more easily
       and  intuitively,  especially  with  a large sample of events. The default option of ‘yes’
       allows this information to be collected now in readiness for this but if you are concerned
       about  performance  you  can  switch  this  off in which case no Stats information will be
       saved.

       RECORD_DIAG_IMAGES - In addition to recording event statistics you  can  also  record  the
       intermediate  diagnostic  images  that  display  the  results  of  the  various checks and
       processing that occur when trying to determine if an alarm event has  taken  place.  There
       are  several  of  these  images  generated for each frame and zone for each alarm or alert
       frame so this can have a massive impact on performance. Only switch this  setting  on  for
       debug or analysis purposes and remember to switch it off again once no longer required.

       DUMP_CORES  -  When  an  unrecoverable  error occurs in a ZoneMinder binary process is has
       traditionally been trapped and the details written to logs  to  aid  in  remote  analysis.
       However in some cases it is easier to diagnose the error if a core file, which is a memory
       dump of the process at the time of the  error,  is  created.  This  can  be  interactively
       analysed  in  the  debugger  and may reveal more or better information than that available
       from the logs. This option is recommended for advanced users only otherwise leave  at  the
       default.  Note  using  this  option  to trigger core files will mean that there will be no
       indication in the binary logs that a process has died, they will just  stop,  however  the
       zmdc  log  will  still  contain an entry. Also note that you may have to explicitly enable
       core file creation on your system via the ‘ulimit -c’ command or other means otherwise  no
       file will be created regardless of the value of this option.

   Options - Network
       [image]

       HTTP_VERSION  -  ZoneMinder  can  communicate  with  network  cameras  using either of the
       HTTP/1.1 or HTTP/1.0 standard. A server will normally fall back to the version it supports
       with  no  problem so this should usually by left at the default. However it can be changed
       to HTTP/1.0 if necessary to resolve particular issues.

       HTTP_UA - When ZoneMinder communicates with remote cameras it will identify  itself  using
       this  string and it’s version number. This is normally sufficient, however if a particular
       cameras expects only to communicate with certain browsers then this can be  changed  to  a
       different string identifying ZoneMinder as Internet Explorer or Netscape etc.

       HTTP_TIMEOUT  - When retrieving remote images ZoneMinder will wait for this length of time
       before deciding that an image is not going to arrive  and  taking  steps  to  retry.  This
       timeout is in milliseconds (1000 per second) and will apply to each part of an image if it
       is not sent in one whole chunk.

       MIN_RTP_PORT - When ZoneMinder communicates with MPEG4 capable cameras using RTP with  the
       unicast  method  it  must  open  ports  for  the camera to connect back to for control and
       streaming purposes. This setting specifies the minimum port number  that  ZoneMinder  will
       use.  Ordinarily  two adjacent ports are used for each camera, one for control packets and
       one for data packets. This port should be set to an even number, you may also need to open
       up a hole in your firewall to allow cameras to connect back if you wish to use unicasting.

       MAX_RTP_PORT  - When ZoneMinder communicates with MPEG4 capable cameras using RTP with the
       unicast method it must open ports for the camera  to  connect  back  to  for  control  and
       streaming  purposes.  This  setting specifies the maximum port number that ZoneMinder will
       use. Ordinarily two adjacent ports are used for each camera, one for control  packets  and
       one for data packets. This port should be set to an even number, you may also need to open
       up a hole in your firewall to allow cameras to connect back if you wish to use unicasting.
       You  should  also  ensure that you have opened up at least two ports for each monitor that
       will be connecting to unicasting network cameras.

   Options - Email
       [image]

       OPT_EMAIL - In ZoneMinder you can create event filters that specify  whether  events  that
       match  certain  criteria  should  have  their details emailed to you at a designated email
       address. This will allow you to be notified of events as soon as they occur  and  also  to
       quickly  view the events directly. This option specifies whether this functionality should
       be available. The email created with this option can be any size and  is  intended  to  be
       sent to a regular email reader rather than a mobile device.

       EMAIL_ADDRESS - This option is used to define the email address that any events that match
       the appropriate filters will be sent to.

       EMAIL_SUBJECT - This option is used to define the subject of the email that  is  sent  for
       any events that match the appropriate filters.

       EMAIL_BODY  -  This option is used to define the content of the email that is sent for any
       events that match the appropriate filters.

                              ┌───────┬──────────────────────────────────┐
                              │Token  │ Description                      │
                              ├───────┼──────────────────────────────────┤
                              │%EI%   │ Id of the event                  │
                              ├───────┼──────────────────────────────────┤
                              │%EN%   │ Name of the event                │
                              ├───────┼──────────────────────────────────┤
                              │%EC%   │ Cause of the event               │
                              ├───────┼──────────────────────────────────┤
                              │%ED%   │ Event description                │
                              ├───────┼──────────────────────────────────┤
                              │%ET%   │ Time of the event                │
                              ├───────┼──────────────────────────────────┤
                              │%EL%   │ Length of the event              │
                              ├───────┼──────────────────────────────────┤
                              │%EF%   │ Number of frames in the event    │
                              ├───────┼──────────────────────────────────┤
                              │%EFA%  │ Number of alarm  frames  in  the │
                              │       │ event                            │
                              ├───────┼──────────────────────────────────┤
                              │%EST%  │ Total score of the event         │
                              ├───────┼──────────────────────────────────┤
                              │%ESA%  │ Average score of the event       │
                              ├───────┼──────────────────────────────────┤
                              │%ESM%  │ Maximum score of the event       │
                              ├───────┼──────────────────────────────────┤
                              │%EP%   │ Path to the event                │
                              ├───────┼──────────────────────────────────┤
                              │%EPS%  │ Path to the event stream         │
                              ├───────┼──────────────────────────────────┤
                              │%EPI%  │ Path to the event images         │
                              ├───────┼──────────────────────────────────┤
                              │%EPI1% │ Path  to the first alarmed event │
                              │       │ image                            │
                              ├───────┼──────────────────────────────────┤
                              │%EPIM% │ Path to the (first) event  image │
                              │       │ with the highest score           │
                              ├───────┼──────────────────────────────────┤
                              │%EI1%  │ Attach first alarmed event image │
                              ├───────┼──────────────────────────────────┤
                              │%EIM%  │ Attach  (first) event image with │
                              │       │ the highest score                │
                              ├───────┼──────────────────────────────────┤
                              │%EV%   │ Attach event mpeg video          │
                              ├───────┼──────────────────────────────────┤
                              │%MN%   │ Name of the monitor              │
                              ├───────┼──────────────────────────────────┤
                              │%MET%  │ Total number of events  for  the │
                              │       │ monitor                          │
                              ├───────┼──────────────────────────────────┤
                              │%MEH%  │ Number of events for the monitor │
                              │       │ in the last hour                 │
                              ├───────┼──────────────────────────────────┤
                              │%MED%  │ Number of events for the monitor │
                              │       │ in the last day                  │
                              ├───────┼──────────────────────────────────┤
                              │%MEW%  │ Number of events for the monitor │
                              │       │ in the last week                 │
                              ├───────┼──────────────────────────────────┤
                              │%MEM%  │ Number of events for the monitor │
                              │       │ in the last month                │
                              └───────┴──────────────────────────────────┘

                              │%MEA%  │ Number  of  archived  events for │
                              │       │ the monitor                      │
                              ├───────┼──────────────────────────────────┤
                              │%MP%   │ Path to the monitor window       │
                              ├───────┼──────────────────────────────────┤
                              │%MPS%  │ Path to the monitor stream       │
                              ├───────┼──────────────────────────────────┤
                              │%MPI%  │ Path to the monitor recent image │
                              ├───────┼──────────────────────────────────┤
                              │%FN%   │ Name of the current filter  that │
                              │       │ matched                          │
                              ├───────┼──────────────────────────────────┤
                              │%FP%   │ Path  to the current filter that │
                              │       │ matched                          │
                              ├───────┼──────────────────────────────────┤
                              │%ZP%   │ Path to your ZoneMinder console  │
                              └───────┴──────────────────────────────────┘

       OPT_MESSAGE - In ZoneMinder you can create event filters that specify whether events  that
       match certain criteria should have their details sent to you at a designated short message
       email address. This will allow you to be notified of events as soon as  they  occur.  This
       option specifies whether this functionality should be available. The email created by this
       option will be brief and is intended to be sent to an SMS gateway or a minimal mail reader
       such as a mobile device or phone rather than a regular email reader.

       MESSAGE_ADDRESS  -  This option is used to define the short message email address that any
       events that match the appropriate filters will be sent to.

       MESSAGE_SUBJECT - This option is used to define the subject of the message  that  is  sent
       for any events that match the appropriate filters.

       MESSAGE_BODY  -  This option is used to define the content of the message that is sent for
       any events that match the appropriate filters.

       NEW_MAIL_MODULES - Traditionally ZoneMinder has  used  the  MIME::Entity  perl  module  to
       construct  and  send  notification emails and messages. Some people have reported problems
       with this module not being present at all or flexible enough for their needs. If  you  are
       one of those people this option allows you to select a new mailing method using MIME::Lite
       and Net::SMTP instead. This method was contributed by  Ross  Melin  and  should  work  for
       everyone but has not been extensively tested so currently is not selected by default.

       EMAIL_HOST - If you have chosen SMTP as the method by which to send notification emails or
       messages then this option allows you to choose which SMTP server to use to send them.  The
       default  of  localhost may work if you have the sendmail, exim or a similar daemon running
       however you may wish to enter your ISP’s SMTP mail server here.

       FROM_EMAIL - The emails or messages that will be sent to you informing you of  events  can
       appear  to  come  from  a designated email address to help you with mail filtering etc. An
       address of something like ZoneMinder@your.domain is recommended.

       URL - The emails or messages that will be sent to you informing you of events can  include
       a  link  to the events themselves for easy viewing. If you intend to use this feature then
       set this option to the url of your installation as it would appear  from  where  you  read
       your email, e.g. http://host.your.domain/zm.php.

   Options - Upload
       [image]

       OPT_UPLOAD  -  In ZoneMinder you can create event filters that specify whether events that
       match certain criteria should be uploaded to a remote server for  archiving.  This  option
       specifies whether this functionality should be available

       UPLOAD_ARCH_FORMAT  -  Uploaded  events  may be stored in either .tar or .zip format, this
       option specifies which. Note that to use this you  will  need  to  have  the  Archive::Tar
       and/or Archive::Zip perl modules installed.

       UPLOAD_ARCH_COMPRESS  - When the archive files are created they can be compressed. However
       in general since the images are compressed already this saves only  a  minimal  amount  of
       space  versus  utilising  more CPU in their creation. Only enable if you have CPU to waste
       and are limited in disk space on your remote server or bandwidth.

       UPLOAD_ARCH_ANALYSE - When the archive files are created they can contain either just  the
       captured  frames  or  both  the  captured frames and, for frames that caused an alarm, the
       analysed image with the changed area highlighted. This option controls files are included.
       Only  include analysed frames if you have a high bandwidth connection to the remote server
       or if you need help in figuring out what caused an alarm in the first  place  as  archives
       with these files in can be considerably larger.

       UPLOAD_PROTOCOL  -  ZoneMinder  can  upload  events to a remote server using either FTP or
       SFTP. Regular FTP is widely supported but not necessarily very secure whereas SFTP (Secure
       FTP) runs over an ssh connection and so is encrypted and uses regular ssh ports. Note that
       to use this you will need  to  have  the  appropriate  perl  module,  either  Net::FTP  or
       Net::SFTP installed depending on your choice.

       UPLOAD_HOST  -  You  can  use  filters to instruct ZoneMinder to upload events to a remote
       server. This option indicates the name, or ip address, of the server to use.

       UPLOAD_PORT - You can use filters to instruct ZoneMinder to  upload  events  to  a  remote
       server.  If  you  are  using  the  SFTP  protocol then this option allows you to specify a
       particular port to use for connection. If this option is left blank then the default, port
       22, is used. This option is ignored for FTP uploads.

       UPLOAD_USER  -  You  can  use  filters to instruct ZoneMinder to upload events to a remote
       server. This option indicates the username that  ZoneMinder  should  use  to  log  in  for
       transfer.

       UPLOAD_PASS  -  You  can  use  filters to instruct ZoneMinder to upload events to a remote
       server. This option indicates the password that  ZoneMinder  should  use  to  log  in  for
       transfer.  If  you  are using certificate based logins for SFTP servers you can leave this
       option blank.

       UPLOAD_LOC_DIR - You can use filters to instruct ZoneMinder to upload events to  a  remote
       server. This option indicates the local directory that ZoneMinder should use for temporary
       upload files. These are files that are created from events, uploaded and then deleted.

       UPLOAD_REM_DIR - You can use filters to instruct ZoneMinder to upload events to  a  remote
       server.  This  option  indicates the remote directory that ZoneMinder should use to upload
       event files to.

       UPLOAD_TIMEOUT - You can use filters to instruct ZoneMinder to upload events to  a  remote
       server.  This  option indicates the maximum inactivity timeout (in seconds) that should be
       tolerated before ZoneMinder determines that the transfer has failed and  closes  down  the
       connection.

       UPLOAD_FTP_PASSIVE  -  You  can  use  filters to instruct ZoneMinder to upload events to a
       remote ftp server. This option indicates that ftp transfers  should  be  done  in  passive
       mode.  This  uses  a single connection for all ftp activity and, whilst slower than active
       transfers, is more robust and likely to work from behind filewalls. This option is ignored
       for SFTP transfers.

       UPLOAD_DEBUG  -  You  can  use filters to instruct ZoneMinder to upload events to a remote
       server. If you are having (or expecting) troubles with uploading events then setting  this
       to ‘yes’ permits additional information to be generated by the underlying transfer modules
       and included in the logs.

   Options - X10
       [image]

       OPT_X10 - If you have an X10 Home Automation setup in your home you can use ZoneMinder  to
       initiate  or  react  to  X10  signals  if  your  computer  has  the  appropriate interface
       controller. This option indicates whether X10 options will be  available  in  the  browser
       client.

       X10_DEVICE  - If you have an X10 controller device (e.g. XM10U) connected to your computer
       this option details which port it is connected on,  the  default  of  /dev/ttyS0  maps  to
       serial or com port 1.

       X10_HOUSE_CODE  - X10 devices are grouped together by identifying them as all belonging to
       one House Code. This option details what that is. It should be a single letter  between  A
       and P.

       X10_DB_RELOAD_INTERVAL  -  The  zmx10  daemon periodically checks the database to find out
       what X10 events trigger, or result from, alarms. This  option  determines  how  frequently
       this  check  occurs,  unless  you  change  this area frequently this can be a fairly large
       value.

   Options - High, Medium and Low B/W
       [image]

       There are now a number of options that are grouped into bandwidth categories, this  allows
       you  to  configure the ZoneMinder client to work optimally over the various access methods
       you might to access the client. The following options are available in H, M and L options.
       These  3  groups  control  what happens when the client is running in ‘high’, ‘medium’ and
       ‘low’ bandwidth mode respectively. In most cases the default values will be suitable as  a
       starting point.

       High  - You should set these options for when accessing the ZoneMinder client over a local
       network or high speed link.

       Medium -  You should set these options for when accessing the  ZoneMinder  client  over  a
       slower cable or DSL link.

       Slow  -  You  should  set  these  options for when accessing Zoneminder client over a slow
       network link.

       WEB_H_REFRESH_MAIN, WEB_M_REFRESH_MAIN, WEB_L_REFRESH_MAIN - How often  (in  seconds)  the
       main  console window should refresh itself. The main console window lists a general status
       and the event totals for all monitors. This is not  a  trivial  task  and  should  not  be
       repeated too frequently or it may affect the performance of the rest of the system.

       WEB_H_REFRESH_CYCLE, WEB_M_REFRESH_CYCLE, WEB_L_REFRESH_CYCLE - How often (in seconds) the
       cycle watch window swaps to the next monitor. The  cycle  watch  window  is  a  method  of
       continuously  cycling between images from all of your monitors. This option determines how
       often to refresh with a new image.

       WEB_H_REFRESH_IMAGE, WEB_M_REFRESH_IMAGE, WEB_L_REFRESH_IMAGE - How often (in seconds) the
       watched  image  is  refreshed  (if  not  streaming). The live images from a monitor can be
       viewed in either streamed or stills mode. This option determines how often a stills  image
       is refreshed, it has no effect if streaming is selected.

       WEB_H_REFRESH_STATUS,  WEB_M_REFRESH_STATUS, WEB_L_REFRESH_STATUS - How often (in seconds)
       the status refreshes itself in the watch window. The monitor window is actually made  from
       several  frames.  The  one  in  the middle merely contains a monitor status which needs to
       refresh fairly  frequently  to  give  a  true  indication.  This  option  determines  that
       frequency.

       WEB_H_REFRESH_EVENTS,  WEB_M_REFRESH_EVENTS, WEB_L_REFRESH_EVENTS - How often (in seconds)
       the event listing is refreshed in the watch window. The monitor window  is  actually  made
       from  several  frames. The lower framme contains a listing of the last few events for easy
       access. This option determines how often this is refreshed.

       WEB_H_CAN_STREAM, WEB_M_CAN_STREAM, WEB_L_CAN_STREAM - If you know that your  browser  can
       handle  image  streams  of  the  type  ‘multipart/x-mixed-replace’ but ZoneMinder does not
       detect this correctly you can set this option to ensure that the stream is delivered  with
       or without the use of the Cambozola plugin. Selecting ‘yes’ will tell ZoneMinder that your
       browser can handle the streams nativ

       WEB_H_STREAM_METHOD,  WEB_M_STREAM_METHOD,  WEB_H_STREAM_METHOD  -   ZoneMinder   can   be
       configured  to use either mpeg encoded video or a series or still jpeg images when sending
       video streams. This option defines which is used. If you choose  mpeg  you  should  ensure
       that you have the appropriate plugins available on your browser whereas choosing jpeg will
       work natively on Mozilla and related browsers and with a Java applet on Internet Explorer

       WEB_H_DEFAULT_SCALE, WEB_M_DEFAULT_SCALE, WEB_L_DEFAULT_SCALE - Normally  ZoneMinder  will
       display  ‘live’ or ‘event’ streams in their native size. However if you have monitors with
       large dimensions or a slow link you may prefer to  reduce  this  size,  alternatively  for
       small  monitors you can enlarge it. This options lets you specify what the default scaling
       factor will be. It is expressed as a percentage so 100 is normal size, 200 is double  size
       etc.

       WEB_H_DEFAULT_RATE,  WEB_M_DEFAULT_RATE,  WEB_L_DEFAULT_RATE  -  Normally  ZoneMinder will
       display ‘event’ streams at their native rate, i.e. as  close  to  real-time  as  possible.
       However if you have long events it is often convenient to replay them at a faster rate for
       review. This option lets you specify what the default replay rate will be. It is expressed
       as a percentage so 100 is normal rate, 200 is double speed etc.

       WEB_H_VIDEO_BITRATE,  WEB_M_VIDEO_BITRATE,  WEB_L_VIDEO_BITRATE - When encoding real video
       via the ffmpeg library a bit rate can  be  specified  which  roughly  corresponds  to  the
       available  bandwidth  used  for  the  stream.  This  setting  effectively corresponds to a
       ‘quality’ setting for the video. A low value will result in a blocky image whereas a  high
       value  will produce a clearer view. Note that this setting does not control the frame rate
       of the video however the quality of the video produced is affected both  by  this  setting
       and  the frame rate that the video is produced at. A higher frame rate at a particular bit
       rate result in individual frames being at a lower quality.

       WEB_H_VIDEO_MAXFPS, WEB_M_VIDEO_MAXFPS, WEB_L_VIDEO_MAXFPS - When using streamed video the
       main  control  is the bitrate which determines how much data can be transmitted. However a
       lower bitrate at high frame rates results in a lower quality image. This option allows you
       to  limit the maximum frame rate to ensure that video quality is maintained. An additional
       advantage is that encoding video at high frame rates is a processor  intensive  task  when
       for  the  most  part a very high frame rate offers little perceptible improvement over one
       that has a more manageable resource requirement. Note, this option is implemented as a cap
       beyond  which binary reduction takes place. So if you have a device capturing at 15fps and
       set this option to 10fps then the video is not produced at 10fps, but rather at 7.5fps (15
       divided by 2) as the final frame rate must be the original divided by a power of 2.

       WEB_H_SCALE_THUMBS,  WEB_M_SCALE_THUMBS,  WEB_L_SCALE_THUMBS - If unset, this option sends
       the whole image to the browser which resizes it in the window. If set the image is  scaled
       down  on  the  server  before  sending  a  reduced  size  image to the browser to conserve
       bandwidth at the cost of cpu on the server. Note that ZM can only perform the resizing  if
       the  appropriate PHP graphics functionality is installed. This is usually available in the
       php-gd package.

       WEB_H_EVENTS_VIEW, WEB_M_EVENTS_VIEW, WEB_L_EVENTS_VIEW - Stored events can be  viewed  in
       either an events list format or in a timeline based one. This option sets the default view
       that will be used. Choosing one view here does not prevent the other view being used as it
       will always be selectable from whichever view is currently being used.

       WEB_H_SHOW_PROGRESS,  WEB_M_SHOW_PROGRESS,  WEB_L_SHOW_PROGRESS  -  When viewing events an
       event navigation panel and progress bar is shown below the event itself. This  allows  you
       to  jump  to  specific points in the event, but can can also dynamically update to display
       the current progress of the event replay itself. This  progress  is  calculated  from  the
       actual  event  duration  and  is  not  directly linked to the replay itself, so on limited
       bandwidth connections may be out of step with the replay. This option allows you  to  turn
       off  the  progress  display,  whilst  still keeping the navigation aspect, where bandwidth
       prevents it functioning effectively.

       WEB_H_AJAX_TIMEOUT, WEB_M_AJAX_TIMEOUT, WEB_L_AJAX_TIMEOUT - The  newer  versions  of  the
       live feed and event views use Ajax to request information from the server and populate the
       views dynamically. This option allows you to specify a timeout  if  required  after  which
       requests are abandoned. A timeout may be necessary if requests would overwise hang such as
       on a slow connection. This would tend to consume a lot of  browser  memory  and  make  the
       interface  unresponsive.  Ordinarily  no requests should timeout so this setting should be
       set to a value greater than the slowest expected response. This value is  in  milliseconds
       but if set to zero then no timeout will be used.

   Options - Users
       [image]

       In  this  section  you will see a list of the current users defined on the system. You can
       also add or delete users from here. It is recommended you do not  delete  the  admin  user
       unless  you  have  created  another fully privileged user to take over the same role. Each
       user is defined with a name and password (which is hidden) as well as an  enabled  setting
       which  you  can  use  to temporarily enable or disable users, for example a guest user for
       limited time access. As well as that there is a language setting that allows you to define
       user  specific  languages.  Setting  a  language  here  that  is different than the system
       language will mean that when that user logs in they will have the web interface  presented
       in their own language rather than the system default, if it is available.

       There are also five values that define the user permissions, these are ‘Stream’, ‘Events’,
       ‘Control’, ‘Monitors’ and ‘System’ Each can have values of ‘None’, ‘View’ or ‘Edit’  apart
       from  ‘Stream’  which  has  no  ‘Edit’ setting. These values cover access to the following
       areas; ‘Stream’ defines whether a user is allowed to view the ‘live’  video  feeds  coming
       from  the  cameras.  You  may wish to allow a user to view historical events only in which
       case this setting should be ‘none’. The ‘Events’ setting determines  whether  a  user  can
       view and modify or delete any retained historical events. The ‘Control’ setting allows you
       to indicate whether the user is able to control any Pan/Tilt/Zoom  type  cameras  you  may
       have  on  your system. The ‘Monitors’ setting specifies whether a user can see the current
       monitor settings and change them. Finally the ‘System’ setting determines whether  a  user
       can  view  or  modify  the  system  settings  as  a  whole,  such  as options and users or
       controlling the running of the system as a whole.

       As well as these settings there is also a ‘Bandwidth’ setting which can be used  to  limit
       the maximum bandwidth that a user can view at and a ‘Monitor Ids’ setting that can be used
       for non-’System’ users to restrict them to only being able to access  streams,  events  or
       monitors  for  the  given monitors ids as a comma separated list with no spaces. If a user
       with ‘Monitors’ edit privileges is limited to specific monitors here they will not be able
       to  add  or delete monitors but only change the details of those they have access to. If a
       user has ‘System’ privileges then the  ‘Monitors  Ids’  setting  is  ignored  and  has  no
       effect.’

   Camera Control
       ZoneMinder  provides  the  facility  to control cameras from the web interface and to some
       extent automatically. Pan/Tilt/Zoom (PTZ) cameras have a wide range  of  capabilities  and
       use  a  large  number  of  different protocols making any kind of generic control solution
       potentially very difficult. To address this ZoneMinder uses  two  key  approaches  to  get
       around this problem.

       Definition of Capabilities
              For  each  camera  model you use, an entry in the camera capabilities table must be
              created. These indicate what functions the camera  supports  and  ensure  that  the
              interface  presents  only  those capabilities that the camera supports. There are a
              very large number of capabilities that may be supported and it  is  very  important
              that  the entries in this table reflect the actual abilities of the camera. A small
              number of example capabilities are included in ZoneMinder, these can  be  used  ‘as
              is’ or modified.

       Control Scripts
              ZoneMinder  itself  does  not  generally  provide  the  ability to send commands to
              cameras or receive responses. What it does is mediate motion requests from the  web
              interface  into  a standard set of commands which are passed to a script defined in
              the control capability. Example scripts are provided in ZoneMinder which support  a
              number  of  serial  or network protocols but it is likely that for many cameras new
              scripts will have to be created. These can be modelled on the example ones,  or  if
              control  commands  already  exist from other applications, then the script can just
              act as a ‘glue’ layer between ZoneMinder and those commands.

       It should be emphasised that the control and capability elements  of  ZoneMinder  are  not
       intended  to be able to support every camera out of the box. Some degree of development is
       likely to be required for many cameras.

   Controlling Monitors
       If you have defined your system as having controllable monitors and you are looking  at  a
       monitor  that is configured for control, then clicking on the ‘Control’ link along the top
       of the window will change the short event listing area to a control area. The capabilities
       you have defined earlier determine exactly what is displayed in this window. Generally you
       will have a Pan/Tilt control area along with one or subsidiary areas such as zoom or focus
       control  to the side. If you have preset support then these will be near the bottom of the
       window. The normal method of controlling the monitor is by  clicking  on  the  appropriate
       graphics  which  then send a command via the control script to the camera itself. This may
       sometimes take a noticeable delay before the camera responds.

       It is usually the case that the control arrows are sensitive to where you click  on  them.
       If  you  have  a camera that allows different speeds to be used for panning or zooming etc
       then clicking near the point of the arrow will invoke the  faster  speed  whilst  clicking
       near  the  base  of  the  arrow will be slower. If you have defined continuous motion then
       ongoing activities can be stopped by clicking on the area between the arrows,  which  will
       either  be  a  graphic  in the case of pan/tilt controls or a word in the case of zoom and
       focus controls etc.

       Certain control capabilities such as mapped motion allow direct control by clicking on the
       image  itself  when  used in browsers which support streamed images directly. Used in this
       way you can just click on the area of the image that interests you  and  the  camera  will
       centre  on  that  spot. You can also use direct image control for relative motion when the
       area of the image you click on defines the direction and the distance away from the centre
       of  the  image  determines  the speed. As it is not always very easy to estimate direction
       near the centre of the image, the active area does not start until a short  distance  away
       from the centre, resulting in a ‘dead’ zone in the middle of the image.

   Control Flow
       Having  a basic understanding of how camera control works in ZoneMinder will go a long way
       in debugging issues in the future. It is important  to  note  that  many  of  the  ‘camera
       control’  scripts  are  user  contributed and it is entirely possible that they break in a
       future version upgrade.

       · ZoneMinder relies on ‘control protocols’ for specific  camera  models.  These  ‘control’
         protocols  are nothing but perl packages located in /usr/share/perl5/ZoneMinder/Control/
         (in Ubuntu distributions) that are invoked by ZoneMinder when you invoke a PTZ operation

       · When you associate a ‘protocol’ for PTZ  for  a  camera,  you  are  effectively  letting
         ZoneMinder  know  where  to locate the perl file that will eventually control the camera
         movement

       · Let’s for example, assume that you are  configuring  a  Foscam  9831W  camera  and  have
         associated  the  ‘9831w’ protocol to that camara. This basically means when you move the
         camera  via  ZoneMinder,  it   will   pass   on   the   movements   to   FI9831w.pm   in
         /usr/share/perl5/ZoneMinder/Control/

       · ZoneMinder  also  maintains protocol configuration parameters in a table called Controls
         in the DB. This table is used to store  parameters  like  whether  the  camera  supports
         continuous move, zoom etc.

       · The Controls table is used by ZoneMinder to build its PTZ web interface. For example, an
         FI9831W camera does not support Zoom –> so when you open the PTZ interface of ZoneMinder
         via  the  Web  Console  and  navigate to the FI9831W camera, the Zoom option will not be
         shown. It knows not to show this because the Control table entry for  FI9831W  specifies
         it    does   not   support   Zoom.   Note   that   you   edit   these   parameters   via
         Source->Control->Control Type->Edit in the web console

       · If you ever look at any of the control protocol files, you will notice it has  functions
         like  moveRelUp  or  moveConLeft  etc.  ->  these  are the functions that eventually get
         invoked to move the camera around and it is expected  that  contributors  who  implement
         missing  camera  profiles  fill  in these functions with the appropriate camera specific
         commands. This way, the core ZoneMinder  code  does  not  need  to  worry  about  camera
         specific  commands.  All  it  needs  to know is the features of a camera and accordinfly
         invoke abstract commands in the protocol perl file and it is the responsibility  of  the
         perl  file  for  that  camera to implement the specifics. So, if you are facing problems
         with PTZ not working, these protocol files are what you should be debugging.

   Control Capabilities
       If you have a camera that supports PTZ controls and wish to use it  with  ZoneMinder  then
       the first thing you need to do is ensure that it has an accurate entry in the capabilities
       table. To do this you need to go to the Control tab of the  Monitor  configuration  dialog
       and select ‘Edit’ where it is listed by the Control Type selection box. This will bring up
       a new window which lists, with a brief summary, the  existing  capabilities.  To  edit  an
       existing  capability  to  modify  select  the Id or Name of the capability in question, or
       click on the Add button to add a new control capability. Either of these  approaches  will
       create a new window, in familiar style, with tabs along the top and forms fields below. In
       the case of the capabilities table there are a large number of settings and tabs, the mean
       and use of these are briefly explained below.

   Main Tab
       Name   This  is  the  name  of  the control capability, it will usually make sense to name
              capabilities after the camera model or protocol being used.

       Type   Whether the capability uses a local (usually serial) or network control protocol.

       Command
              This is the full path to a script or application that will map the standard set  of
              ZoneMinder control commands to equivalent control protocol command. This may be one
              of the shipped example zmcontrol-*.pl scripts or something else entirely.

       Can Wake
              This is the first of the actual capability definitions. Checking this box indicates
              that a protocol command exists to wake up the camera from a sleeping state.

       Can Sleep
              The camera can be put to sleep.

       Can Reset
              The camera can be reset to a previously defined state.

   Move Tab
       Can Move
              The camera is able move, i.e. pan or tilt.

       Can Move Diagonally
              The  camera  can  move  diagonally.  Some  devices  can  move  only  vertically  or
              horizontally at a time.

       Can Move Mapped
              The camera is able internally map a point on an image to a precise degree of motion
              to centre that point in the image.

       Can Move Absolute
              The camera can move to an absolute location.

       Can Move Relative
              The camera can more to a relative location, e.g. 7 point left or up.

       Can Move Continuous
              The  camera  can move continuously in a defined direction until told to stop or the
              movement limits are reached, e.g. left.

   Pan Tab
       Can Pan
              The camera can pan, or move horizontally.

       Min/Max Pan Range
              If the camera supports  absolute  motion  this  is  the  minimum  and  maximum  pan
              co-ordinates that may be specified, e.g. -100 to 100.

       Min/Man Pan Step
              If  the  camera supports relative motion, this is the minimum and maximum amount of
              movement that can be specified.

       Has Pan Speed
              The camera supports specification of pan speeds.

       Min/Max Pan Speed
              The minimum and maximum pan speed supported.

       Has Turbo Pan
              The camera supports an additional turbo pan speed.

       Turbo Pan Speed
              The actual turbo pan speed.

   Tilt Tab
       Definition of Tilt capabilities, fields as for ‘Pan’ tab.

   Zoom Tab
       Can Zoom
              The camera can zoom.

       Can Zoom Absolute
              The camera can zoom to an absolute position.

       Can Zoom Relative
              The camera can zoom to a relative position.

       Can Zoom Continuous
              The camera can zoom continuously in or out until told to stop or  the  zoom  limits
              are reached.

       Min/Max Zoom Range
              If  the  camera supports absolute zoom this is the minimum and maximum zoom amounts
              that may be specified.

       Min/Man Zoom Step
              If the camera supports relative zoom, this is the minimum  and  maximum  amount  of
              zoom change that can be specified.

       Has Zoom Speed
              The camera supports specification of zoom speed.

       Min/Max Zoom Speed
              The minimum and maximum zoom speed supported.

   Focus Tab
       Definition  of  Focus  capabilities,  fields  as  for  ‘Zoom’  tab, but with the following
       additional capability.

       Can Auto Focus
              The camera can focus automatically.

   White Tab
       Definition of White Balance capabilities, fields as for ‘Focus’ tab.

   Iris Tab
       Definition of Iris Control capabilities, fields as for ‘Focus’ tab.

   Presets Tab
       Has Presets
              The camera supports preset positions.

       Num Presets
              How many presets the camera supports. If the  camera  supports  a  huge  number  of
              presets then it makes sense to specify a more reasonable number here, 20 or less is
              recommended.

       Has Home Preset
              The camera has a defined ‘home’ position, usually in the mid point of its range.

       Can Set Presets
              The camera supports setting preset locations via its control protocol.

   Control Scripts
       The second key element  to  controlling  cameras  with  ZoneMinder  is  ensuring  that  an
       appropriate control script or application is present. A small number of sample scripts are
       included with ZoneMinder and can be used directly or as the basis for development. Control
       scripts  are  run  atomically,  that  is  to  say  that  one requested action from the web
       interface results in one execution of the script and no state information  is  maintained.
       If  your  protocol  requires state information to be preserved then you should ensure that
       your scripts do this as ZoneMinder has no concept of the state of the  camera  in  control
       terms.

       If  you  are  writing  a  new  control script then you need to ensure that it supports the
       parameters that ZoneMinder will pass to it. If you already have  scripts  or  applications
       that  control your cameras, the ZoneMinder control script will just act as glue to convert
       the parameters passed into a form that your existing application understands. If  you  are
       writing  a  script  to support a new protocol then you will need to convert the parameters
       passed into the script to equivalent protocol commands. If you have carefully defined your
       control  capabilities  above then you should only expect commands that correspond to those
       capabilities.

       The standard set of parameters passed to control scripts is defined below,
          –device=<device> : This is the control device from the monitor definition. Absent if no
          device  is  specified.   —  address=<address>  :  This  is the control address from the
          monitor definition. This will usually be a hostname or ip address for  network  cameras
          or a simple numeric camera id for other cameras.
          –autostop=<timeout>  : This indicates whether an automatic timeout should be applied to
          ‘’‘stop’‘’ the given command. It will only be included for  ‘’‘continuous’‘’  commands,
          as  listed  below,  and  will  be a timeout in decimal seconds, probably fractional.  —
          command=<command> : This specifies the command that the script  should  execute.  Valid
          commands are given below.
          –xcoord=<x>, –ycoord=<y> : This specifies the x and/or y coordinates for commands which
          require them. These will normally be absolute or mapped commands.   —  width=<width>’‘,
          ‘’–height=<height>  :  This  specifies  the  width and height of the current image, for
          mapped motion commands where the coordinates values passed must have a context.
          –speed=<speed> : This specifies the speed that the command should use, if  appropriate.
          —  panspeed=<speed>’‘,  ‘’–tiltspeed=<speed> : This indicates the specific pan and tilt
          speeds for diagonal movements which may allow a different motion  rate  for  horizontal
          and vertical components.
          –step=<step>  :  This  specifies  the  amount of motion that the command should use, if
          appropriate.  Normally  used  for  relative   commands   only.    —   panstep=<step>’‘,
          ‘’–tiltstep=<step>  :  This  indicates  the  specific  pan  and tilt steps for diagonal
          movements which may allow a different amount of  motion  for  horizontal  and  vertical
          components.
          –preset=<preset>  :  This specifies the particular preset that relevant commands should
          operate on.

       The command option listed above may take one of the following commands as a parameter.

       wake   Wake the camera.

       sleep  Send the camera to sleep.

       reset  Reset the camera.

       move_map
              Move mapped to a specified location on the image.

       move_pseudo_map
              As move_map above. Pseudo-mapped motion can be  used  when  mapped  motion  is  not
              supported  but  relative  motion  is  in  which  case  mapped motion can be roughly
              approximated by careful calibration.

       move_abs_<direction>
              Move to a specified absolute location. The direction element gives a  hint  to  the
              direction  to  go  but  can  be omitted. If present it will be one of “up”, “down”,
              “left”, “right”, “upleft”, “upright”, “downleft” or “downright”.

       move_rel_<direction>
              Move a specified amount in the given direction.

       move_con_<direction>
              Move continuously in the given direction until told to stop.

       move_stop
              Stop any motion which may be in progress.

       zoom_abs_<direction>
              Zoom to a specified absolute zoom position. The direction element gives a  hint  to
              the  direction  to  go  but  can be omitted. If present it will be one of “tele” or
              “wide”.

       zoom_rel_<direction>
              Zoom a specified amount in the given direction.

       zoom_con_<direction>
              Zoom continuously in the given direction until told to stop.

       zoom_stop
              Stop any zooming which may be in progress.

       focus_auto
              Set focusing to be automatic.

       focus_man
              Set focusing to be manual.

       focus_abs_<direction>
              Focus to a specified absolute focus position. The direction element gives a hint to
              the  direction  to  go  but  can be omitted. If present it will be one of “near” or
              “far”.

       focus_rel_<direction>
              Focus a specified amount in the given direction.

       focus_con_<direction>
              Focus continuously in the given direction until told to stop.

       focus_stop
              Stop any focusing which may be in progress.

       white_<subcommand>
              As per the focus commands, except that direction may be “in” or “out”.

       iris_<subcommand>
              As per the focus commands, except that direction may be “open” or “close”.

       preset_set
              Set the given preset to the current location.

       preset_goto
              Move to the given preset.

       preset_home
              Move to the “home” preset.

   Mobile Devices
       Here are some options for using ZoneMinder on Mobile devices:

   Third party mobile clients
       ·

         zmNinja (source code, needs APIs to be installed to work)

                · Available in App Store and Play Store - website

       ·

         zmView (limited, free) and zmView Pro (more features, paid)

                · Available in App Store and Play Store, relies on ZM skins website

   Using the existing web console
       · You can directly use the ZoneMinder interface by launching a browser and  going  to  the
         ZoneMinder server just like you do on the Desktop

       · ZoneMinder also has a “mobile skin” that offers limited functionality (not all views are
         present   in   this    skin).    You    can    point    your     mobile    browser    to
         http://yourzoneminderip/zm/index.php?skin=mobile   and  bookmark  it.  Note however that
         1.29 is the last release that will support the mobile skin. It’s use is deprecated

   Discontinued clients
       The following are a list of clients that do not work and have not been updated:

       · eyeZM

   Logging
       Most components of ZoneMinder can emit informational, warning, error and debug messages in
       a  standard  format. These messages can be logged in one or more locations. By default all
       messages produced by scripts are logged in <script name>.log files which are placed in the
       directory defined by the ZM_PATH_LOGS configuration variable. This is initially defined as
       ‘/tmp’ though it can be overridden (see the Options  and  Users  section  above).  So  for
       example,  the  zmpkg.pl  script will output messages to /tmp/zmpkg.pl, an example of these
       messages is:

          03/01/06 13:46:00.166046 zmpkg[11148].INF [Command: start]

       where the first part refers to the date and time of the entry, the  next  section  is  the
       name  (or  an  abbreviated  version)  of  the script, followed by the process id in square
       brackets, a severity code (INF, WAR, ERR or DBG) and the debug text.  If  you  change  the
       location  of  the  log  directory, ensure it refers to an existing directory which the web
       user has permissions to write to. Also ensure that no logs are present in  that  directory
       the  web  user  does  not  have permission to open. This can happen if you run commands or
       scripts as the root user for testing  at  some  point.  If  this  occurs  then  subsequent
       non-privileged runs will fails due to being unable to open the log files.

       As  well  as  specific  script  logging above, information, warning and error messages are
       logged via the system syslog service. This is a standard component on  Linux  systems  and
       allows  logging of all sorts of messages in a standard way and using a standard format. On
       most systems, unless otherwise configured, messages produced by ZoneMinder will go to  the
       /var/log/messages file. On some distributions they may end up in another file, but usually
       still in /var/log. Messages in this file are similar to those in the script log files  but
       differ slightly. For example the above event in the system log file looks like:

          Jan  3 13:46:00 shuttle52 zmpkg[11148]: INF [Command: start]

       where  you can see that the date is formatted differently (and only to 1 second precision)
       and there is an additional field for the hostname (as syslog can operate over a  network).
       As  well  as  ZoneMinder  entries in this file you may also see entries from various other
       system components. You should ensure that  your  syslogd  daemon  is  running  for  syslog
       messages to be correctly handled.

       A  number  of  users  have  asked how to suppress or redirect ZoneMinder messages that are
       written to this file. This most often occurs due to not wanting other system  messages  to
       be  overwhelmed  and obscured by the ZoneMinder produced ones (which can be quite frequent
       by default). In order to  control  syslog  messages  you  need  to  locate  and  edit  the
       syslog.conf  file  on  your  system.  This  will often be in the /etc directory. This file
       allows configuration of syslog so that certain classes  and  categories  of  messages  are
       routed  to  different  files or highlighted to a console, or just ignored. Full details of
       the format of this file is outside the scope of this document  (typing  ‘man  syslog.conf’
       will  give  you  more  information)  but  the  most  often  requested  changes are easy to
       implement.

       The syslog service uses the concept of priorities and facilities where the  former  refers
       to  the  importance  of  the message and the latter refers to that part of the system from
       which it originated. Standard priorities include ‘info’, ‘warning’, ‘err’ and ‘debug’  and
       ZoneMinder  uses  these  priorities  when  generating  the corresponding class of message.
       Standard facilities include ‘mail’, ‘cron’ and ‘security’ etc but as well this, there  are
       eight  ‘local’  facilities  that  can  be  used  by  machine  specific message generators.
       ZoneMinder produces it’s messages via the ‘local1’ facility.

       So armed with the knowledge of the priority and facility of  a  message,  the  syslog.conf
       file can be amended to handle messages however you like.

       So  to  ensure  that  all  ZoneMinder  messages  go to a specific log file you can add the
       following line near the top of your syslog.conf file:

          # Save ZoneMinder messages to zm.log
          local1.*                        /var/log/zm/zm.log

       which will ensure that all messages produced with the local1 facility are  routed  to  fhe
       /var/log/zm/zm.log  file.  However  this does not necessarily prevent them also going into
       the standard system log. To do this you will need to modify the line that determines which
       messages are logged to this file. This may look something like:

          # Log anything (except mail) of level info or higher.
          # Don't log private authentication messages!
          *.info;mail.none;news.none;authpriv.none;cron.none      /var/log/messages

       by  default.  To  remove ZoneMinder messages altogether from this file you can modify this
       line to look like:

          *.info;local1.!*;mail.none;news.none;authpriv.none;cron.none     /var/log/messages

       which instructs syslog to ignore any messages from the local1  facility.  If  however  you
       still want warnings and errors to occur in the system log file, you could change it to:

          *.info;local1.!*;local1.warning;mail.none;news.none;authpriv.none;cron.none     /var/log/messages

       which follows the ignore instruction with a further one to indicate that any messages with
       a facility of local1 and a priority of warning or above should still go into the file.

       These recipes are just examples of how you can modify the logging  to  suit  your  system,
       there  are  a  lot  of  other  modifications you could make. If you do make any changes to
       syslog.conf you should ensure you restart the syslogd process or send it a HUP  signal  to
       force it to reread its configuration file otherwise your changes will be ignored.

       The  discussion  of  logging above began by describing how scripts produce error and debug
       messages. The way  that  the  binaries  work  is  slightly  different.  Binaries  generate
       information,  warning  and  error messages using syslog in exactly the same way as scripts
       and these  messages  will  be  handled  identically.  However  debug  output  is  somewhat
       different.  For  the scripts, if you want to enable debug you will need to edit the script
       file itself and change the DBG_LEVEL constant to have a value of 1. This will  then  cause
       debug  messages  to  be  written  to  the  <script>.log file as well as the more important
       messages. Debug messages however are not routed via syslog. Scripts  currently  only  have
       one level of debug so this will cause any and all debug messages to be generated. Binaries
       work slightly differently and while you can edit the call to zmDbgInit that is present  in
       every  binary’s  ‘main’ function to update the initial value of the debug level, there are
       easier ways.

       The simplest way of collecting debug output is to click on the Options link from the  main
       ZoneMinder  console  view  and  then  go to the Debug tab. There you will find a number of
       debug options. The first thing you should do is ensure that the ZM_EXTRA_DEBUG setting  is
       switched  on.  This  enables  debug generally. The next thing you need to do is select the
       debug target, level and destination file using the relevant options. Click on the  ‘?’  by
       each option for more information about valid settings. You will need to restart ZoneMinder
       as a whole or at least the component in question for logging to take effect. When you have
       finished debugging you should ensure you switch debug off by unchecking the ZM_EXTRA_DEBUG
       option and restarting ZoneMinder. You can leave the other options as you like as they  are
       ignored if the master debug option is off.

       Once you have debug being logged you can modify the level by sending USR1 and USR2 signals
       to the relevant binary (or binaries) to increase or decrease  the  level  of  debug  being
       emitted  with  immediate  effect.  This  modification  will not persist if the binary gets
       restarted however.

       If you wish to run a binary directly from the command line to test specific  functionality
       or scenarios, you can set the ZM_DBG_LEVEL and ZM_DBG_LOG environment variables to set the
       level and log file of the debug you wish to see, and the ZM_DBG_PRINT environment variable
       to 1 to output the debug directly to your terminal.

       All  ZoneMinder  logs  can  now be rotated by logrotate. A sample logrotate config file is
       shown below:

          /var/log/zm/*.log {
              missingok
              notifempty
              sharedscripts
              postrotate
                  /usr/local/bin/zmpkg.pl logrot 2> /dev/null > /dev/null || true
              endscript
          }

API

       This document will provide an overview of ZoneMinder’s API. This is work in progress.

   Overview
       In an effort to further ‘open up’ ZoneMinder, an API was needed.  This  will  allow  quick
       integration with and development of ZoneMinder.

       The  API  is  built  in CakePHP and lives under the /api directory.  It provides a RESTful
       service and supports CRUD (create,  retrieve,  update,  delete)  functions  for  Monitors,
       Events, Frames, Zones and Config.

   Streaming Interface
       Developers  working  on  their  application often ask if there is an “API” to receive live
       streams, or recorded event streams.  It is possible  to  stream  both  live  and  recorded
       streams.  This isn’t strictly an “API” per-se (that is, it is not integrated into the Cake
       PHP based API layer discussed here) and also why we’ve used the term  “Interface”  instead
       of an “API”.

   Live Streams
       What  you need to know is that if you want to display “live streams”, ZoneMinder sends you
       streaming JPEG images (MJPEG) which can easily be rendered in a browser using an  img  src
       tag.

       For example:

          <img src="https://yourserver/zm/cgi-bin/nph-zms?scale=50&width=640p&height=480px&mode=jpeg&maxfps=5&buffer=1000&&monitor=1&auth=b54a589e09f330498f4ae2203&connkey=36139" />

       will  display  a live feed from monitor id 1, scaled down by 50% in quality and resized to
       640x480px.

       · This assumes /zm/cgi-bin is your CGI_BIN path. Change it to  what  is  correct  in  your
         system

       · The  “auth”  token  you  see  above is required if you use ZoneMinder authentication. To
         understand how to get the auth token, please read the “Login,  Logout  &  API  security”
         section below.

       · The  “connkey”  parameter  is  essentially  a  random number which uniquely identifies a
         stream. If you don’t specify a connkey, ZM will generate its own. It is  recommended  to
         generate  a  connkey  because  you can then use it to “control” the stream (pause/resume
         etc.)

       · Instead of dealing with the “auth” token, you can also use  &user=username&pass=password
         where  “username” and “password” are your ZoneMinder username and password respectively.
         Note that this is not recommended because you are transmitting them in a URL and even if
         you use HTTPS, they may show up in web server logs.

   PTZ on live streams
       PTZ  commands  are  pretty  cryptic  in  ZoneMinder. This is not meant to be an exhaustive
       guide, but just something to whet your appetite:

       Lets assume you have a monitor, with ID=6. Let’s further assume you want to pan it left.

       You’d need to send a: POST command to https://yourserver/zm/index.php with  the  following
       data payload in the command (NOT in the URL)

       view=request&request=control&id=6&control=moveConLeft&xge=30&yge=30

       Obviously, if you are using authentication, you need to be logged in for this to work.

       Like  I said, at this stage, this is only meant to get you started. Explore the ZoneMinder
       code and use “Inspect source” as you use PTZ  commands  in  the  ZoneMinder  source  code.
       control_functions.php is a great place to start.

   Pre-recorded (past event) streams
       Similar to live playback, if you have chosen to store events in JPEG mode, you can play it
       back using:

          <img src="https://yourserver/zm/cgi-bin/nph-zms?mode=jpeg&frame=1&replay=none&source=event&event=293820&connkey=77493&auth=b54a58f5f4ae2203" />

       · This assumes /zm/cgi-bin is your CGI_BIN path. Change it to  what  is  correct  in  your
         system

       · This will playback event 293820, starting from frame 1 as an MJPEG stream

       · Like before, you can add more parameters like scale etc.

       · auth  and  connkey  have  the  same  meaning as before, and yes, you can replace auth by
         &user=usename&pass=password as before and the same security concerns cited above apply.

       If instead, you have chosen to use the MP4  (Video)  storage  mode  for  events,  you  can
       directly play back the saved video file:

          <video src="https://yourserver/zm/index.php?view=view_video&eid=294690&auth=33f3d558af84cf08" type="video/mp4"></video>

       · This will play back the video recording for event 294690

   What other parameters are supported?
       The  best  way to answer this question is to play with ZoneMinder console. Open a browser,
       play back live or recorded feed, and do an “Inspect Source” to  see  what  parameters  are
       generated. Change and observe.

   Enabling API
       A default ZoneMinder installs with APIs enabled. You can explictly enable/disable the APIs
       via the Options->System menu by enabling/disabling OPT_USE_API. Note that if you intend to
       use  APIs  with  3rd  party apps, such as zmNinja or others that use APIs, you should also
       enable AUTH_HASH_LOGINS.

   Login, Logout & API Security
       The APIs tie into ZoneMinder’s existing security model. This means if  you  have  OPT_AUTH
       enabled,  you  need to log into ZoneMinder using the same browser you plan to use the APIs
       from. If you are developing an app that relies on the API, you need to  do  a  POST  login
       from the app into ZoneMinder before you can access the API.

       Then,  you  need to re-use the authentication information of the login (returned as cookie
       states) with subsequent APIs for the authentication information to  flow  through  to  the
       APIs.

       This means if you plan to use cuRL to experiment with these APIs, you first need to login:

       Login process for ZoneMinder v1.32.0 and above

          curl -XPOST -d "user=XXXX&pass=YYYY" -c cookies.txt  http://yourzmip/zm/api/host/login.json

       Staring ZM 1.32.0, you also have a logout API that basically clears your session. It looks
       like this:

          curl -b cookies.txt  http://yourzmip/zm/api/host/logout.json

       Login process for older versions of ZoneMinder

          curl -d "username=XXXX&password=YYYY&action=login&view=console" -c cookies.txt  http://yourzmip/zm/index.php

       The equivalent logout process for older versions of ZoneMinder is:

          curl -XPOST -d "username=XXXX&password=YYYY&action=logout&view=console" -b cookies.txt  http://yourzmip/zm/index.php

       replacing XXXX and YYYY with your username and password, respectively.

       Please make sure you do this in a directory where you have  write  permissions,  otherwise
       cookies.txt will not be created and the command will silently  fail.

       What  the  “-c  cookies.txt”  does is store a cookie state reflecting that you have logged
       into ZM. You now need to apply that cookie state to all subsequent APIs. You  do  that  by
       using a ‘-b cookies.txt’ to subsequent APIs if you are using CuRL like so:

          curl -b cookies.txt http://yourzmip/zm/api/monitors.json

       This  would return a list of monitors and pass on the authentication information to the ZM
       API layer.

   A deeper dive into the login process
       As you might have seen above, there are two ways to login, one that  uses  the  login.json
       API  and  the other that logs in using the ZM portal. If you are running ZoneMinder 1.32.0
       and above, it is strongly recommended you use the login.json approach. The “old”  approach
       will still work but is not as powerful as the API based login. Here are the reasons why:

          · The  “old”  approach  basically  uses  the same login webpage (index.php) that a user
            would log into when viewing the ZM console. This is not really using an API and  more
            importantly,  if you have additional components like reCAPTCHA enabled, this will not
            work. Using the API approach is much cleaner and will work irrespective of reCAPTCHA

          · The new login API returns important information that you can use to stream videos  as
            well,  right  after  login. Consider for example, a typical response to the login API
            (/login.json):

          {
              "credentials": "auth=f5b9cf48693fe8552503c8ABCD5",
              "append_password": 0,
              "version": "1.31.44",
              "apiversion": "1.0"
          }

       In this example I have OPT_AUTH enabled in ZoneMinder and it returns  my  credential  key.
       You can then use this key to stream images like so:

          <img src="https://server/zm/cgi-bin/nph-zms?monitor=1&auth=<authval>" />

       Where authval is the credentials returned to start streaming videos.

       The  append_password  field  will contain 1 when it is necessary for you to append your ZM
       password. This is the case when you set AUTH_RELAY in ZM options to “plain”, for  example.
       In  that  case, the credentials field may contain something like &user=admin&pass= and you
       have to add your password to that string.

       NOTE:
          It is recommended you invoke the login API once every  60  minutes  to  make  sure  the
          session stays alive. The same is true if you use the old login method too.

   Examples (please read security notice above)
       Please  remember, if you are using authentication, please add a -b cookies.txt  to each of
       the commands below if you are using CuRL. If you are not using CuRL and writing  your  own
       app, you need to make sure you pass on cookies to subsequent requests in your app.

       (In all examples, replace ‘server’ with IP or hostname & port where ZoneMinder is running)

   API Version
       To retrieve the API version:

          curl http://server/zm/api/host/getVersion.json

   Return a list of all monitors
          curl http://server/zm/api/monitors.json

       It  is  worthwhile  to  note  that  starting ZM 1.32.3 and beyond, this API also returns a
       Monitor_Status object per monitor. It looks like this:

          "Monitor_Status": {
                  "MonitorId": "2",
                  "Status": "Connected",
                  "CaptureFPS": "1.67",
                  "AnalysisFPS": "1.67",
                  "CaptureBandwidth": "52095"
              }

       If you don’t see this in your API, you are running an older version of ZM. This gives  you
       a  very  convenient  way  to  check  monitor  status  without  calling the daemonCheck API
       described later.

   Retrieve monitor 1
          curl http://server/zm/api/monitors/1.json

   Change State of Monitor 1
       This API changes monitor 1 to Modect and Enabled

          curl -XPOST http://server/zm/api/monitors/1.json -d "Monitor[Function]=Modect&Monitor[Enabled]=1"

   Get Daemon Status of Monitor 1
          curl http://server/zm/api/monitors/daemonStatus/id:1/daemon:zmc.json

   Add a monitor
       This command will add a new http monitor.

          curl -XPOST http://server/zm/api/monitors.json -d "Monitor[Name]=Cliff-Burton\
          &Monitor[Function]=Modect\
          &Monitor[Protocol]=http\
          &Monitor[Method]=simple\
          &Monitor[Host]=usr:pass@192.168.11.20\
          &Monitor[Port]=80\
          &Monitor[Path]=/mjpg/video.mjpg\
          &Monitor[Width]=704\
          &Monitor[Height]=480\
          &Monitor[Colours]=4"

   Edit monitor 1
       This command will change the ‘Name’ field of Monitor 1 to ‘test1’

          curl -XPUT http://server/zm/api/monitors/1.json -d "Monitor[Name]=test1"

   Delete monitor 1
       This command will delete Monitor 1, but will _not_ delete any Events which depend on it.

          curl -XDELETE http://server/zm/api/monitors/1.json

   Arm/Disarm monitors
       This command will force an alarm on Monitor 1:

          curl http://server/zm/api/monitors/alarm/id:1/command:on.json

       This command will disable the  alarm on Monitor 1:

          curl http://server/zm/api/monitors/alarm/id:1/command:off.json

       This command will report the status of the alarm  Monitor 1:

          curl http://server/zm/api/monitors/alarm/id:1/command:status.json

   Return a list of all events
          http://server/zm/api/events.json

       Note that events list can be quite large and this API (as with all other APIs in ZM)  uses
       pagination.  Each  page  returns a specific set of entries. By default this is 25 and ties
       into WEB_EVENTS_PER_PAGE in the ZM options menu.

       So the logic to iterate through all events should be  something  like  this  (pseudocode):
       (unfortunately there is no way to get pageCount without getting the first page)

          data = http://server/zm/api/events.json?page=1 # this returns the first page
          # The json object returned now has a property called data.pagination.pageCount
          count = data.pagination.pageCount;
          for (i=1, i<count, i++)
          {
            data = http://server/zm/api/events.json?page=i;
             doStuff(data);
          }

   Retrieve event Id 1000
          curl -XGET http://server/zm/api/events/1000.json

   Edit event 1
       This command will change the ‘Name’ field of Event 1 to ‘Seek and Destroy’

          curl -XPUT http://server/zm/api/events/1.json -d "Event[Name]=Seek and Destroy"

   Delete event 1
       This command will delete Event 1, and any Frames which depend on it.

          curl -XDELETE http://server/zm/api/events/1.json

   Return a list of events for a specific monitor Id =5
          curl -XGET http://server/zm/api/events/index/MonitorId:5.json

       Note that the same pagination logic applies if the list is too long

   Return a list of events for a specific monitor within a specific date/time range
          http://server/zm/api/events/index/MonitorId:5/StartTime >=:2015-05-15 18:43:56/EndTime <=:2015-05-16 18:43:56.json

       To try this in CuRL, you need to URL escape the spaces like so:

          curl -XGET  "http://server/zm/api/events/index/MonitorId:5/StartTime%20>=:2015-05-15%2018:43:56/EndTime%20<=:2015-05-16%2018:43:56.json"

   Return a list of events for all monitors within a specified date/time range
          curl -XGET "http://server/zm/api/events/index/StartTime%20>=:2015-05-15%2018:43:56/EndTime%20<=:208:43:56.json"

   Return event count based on times and conditions
       The API also supports a handy mechanism to return a count of events for a period of time.

       This returns number of events per monitor that were recorded in the last one hour

          curl "http://server/zm/api/events/consoleEvents/1%20hour.json"

       This  returns  number of events per monitor that were recorded in the last day where there
       were atleast 10 frames that were alarms”

          curl "http://server/zm/api/events/consoleEvents/1%20day.json/AlarmFrames >=: 10.json"

   Configuration Apis
       The APIs allow you to access all the configuration parameters of ZM that you typically set
       inside the web console.  This returns the full list of configuration parameters:

          curl -XGET http://server/zm/api/configs.json

       Each  configuration parameter has an Id, Name, Value and other fields. Chances are you are
       likely only going to focus on these 3.

       The edit function of the Configs API is a little quirky at the moment. Its format deviates
       from the usual edit flow of other APIs. This will be fixed, eventually. For now, to change
       the “Value” of ZM_X10_HOUSE_CODE from A to B:

          curl -XPUT http://server/zm/api/configs/edit/ZM_X10_HOUSE_CODE.json  -d "Config[Value]=B"

       To validate changes have been made:

          curl -XGET http://server/zm/api/configs/view/ZM_X10_HOUSE_CODE.json

   Run State Apis
       ZM API can be used to start/stop/restart/list states of  ZM as well Examples:

          curl -XGET  http://server/zm/api/states.json # returns list of run states
          curl -XPOST  http://server/zm/api/states/change/restart.json #restarts ZM
          curl -XPOST  http://server/zm/api/states/change/stop.json #Stops ZM
          curl -XPOST  http://server/zm/api/states/change/start.json #Starts ZM

   Create a Zone
          curl -XPOST http://server/zm/api/zones.json -d "Zone[Name]=Jason-Newsted\
          &Zone[MonitorId]=3\
          &Zone[Type]=Active\
          &Zone[Units]=Percent\
          &Zone[NumCoords]=4\
          &Zone[Coords]=0,0 639,0 639,479 0,479\
          &Zone[AlarmRGB]=16711680\
          &Zone[CheckMethod]=Blobs\
          &Zone[MinPixelThreshold]=25\
          &Zone[MaxPixelThreshold]=\
          &Zone[MinAlarmPixels]=9216\
          &Zone[MaxAlarmPixels]=\
          &Zone[FilterX]=3\
          &Zone[FilterY]=3\
          &Zone[MinFilterPixels]=9216\
          &Zone[MaxFilterPixels]=230400\
          &Zone[MinBlobPixels]=6144\
          &Zone[MaxBlobPixels]=\
          &Zone[MinBlobs]=1\
          &Zone[MaxBlobs]=\
          &Zone[OverloadFrames]=0"

   PTZ Control Meta-Data APIs
       PTZ controls associated with a monitor are stored  in  the  Controls  table  and  not  the
       Monitors  table  inside  ZM. What that means is when you get the details of a Monitor, you
       will only know if it is controllable (isControllable:true) and the control ID.  To be able
       to retrieve PTZ information related to that Control ID, you need to use the controls API

       Note  that  these APIs only retrieve control data related to PTZ. They don’t actually move
       the camera. See the “PTZ on live streams” section to move the camera.

       This returns all the control definitions:

          curl http://server/zm/api/controls.json

       This returns control definitions for a specific control ID=5

          curl http://server/zm/api/controls/5.json

   Host APIs
       ZM APIs have various APIs that help you in determining host (aka ZM) daemon  status,  load
       etc. Some examples:

          curl -XGET  http://server/zm/api/host/getLoad.json # returns current load of ZM

          # Note that ZM 1.32.3 onwards has the same information in Monitors.json which is more reliable and works for multi-server too.
          curl -XGET  http://server/zm/api/host/daemonCheck.json # 1 = ZM running 0=not running

          # The API below uses "du" to calculate disk space. We no longer recommend you use it if you have many events. Use the Storage APIs instead, described later
          curl -XGET  http://server/zm/api/host/getDiskPercent.json # returns in GB (not percentage), disk usage per monitor (that is,space taken to store various event related information,images etc. per monitor)

   Storage and Server APIs
       ZoneMinder    introduced    many    new    options   that   allowed   you   to   configure
       multiserver/multistorage configurations. While a part of this was  available  in  previous
       versions,  a  lot  of rework was done as part of ZM 1.31 and 1.32. As part of that work, a
       lot of new and useful APIs were added. Some of these are part of ZM 1.32 and  others  will
       be part of ZM 1.32.3 (of course, if you build from master, you can access them right away,
       or wait till a stable release is out.

       This returns storage data for my single server install. If you  are  using  multi-storage,
       you’ll see many such “Storage” entries, one for each storage defined:

          curl http://server/zm/api/storage.json

       Returns:

          {
              "storage": [
                  {
                      "Storage": {
                          "Id": "0",
                          "Path": "\/var\/cache\/zoneminder\/events",
                          "Name": "Default",
                          "Type": "local",
                          "Url": null,
                          "DiskSpace": "364705447651",
                          "Scheme": "Medium",
                          "ServerId": null,
                          "DoDelete": true
                      }
                   }
                 ]
          }

       “DiskSpace”  is  the disk used in bytes. While this doesn’t return disk space data as rich
       as  /host/getDiskPercent, it is much more efficient.

       Similarly,

          curl http://server/zm/api/servers.json

       Returns:

          {
                "servers": [
                    {
                        "Server": {
                            "Id": "1",
                            "Name": "server1",
                            "Hostname": "server1.mydomain.com",
                            "State_Id": null,
                            "Status": "Running",
                            "CpuLoad": "0.9",
                            "TotalMem": "6186237952",
                            "FreeMem": "156102656",
                            "TotalSwap": "536866816",
                            "FreeSwap": "525697024",
                            "zmstats": false,
                            "zmaudit": false,
                            "zmtrigger": false
                        }
                    }
                ]
            }

       This only works if you have a multiserver setup in place. If you don’t it will  return  an
       empty array.

   Further Reading
       As  described  earlier, treat this document as an “introduction” to the important parts of
       the API and streaming interfaces.   There  are  several  details  that  haven’t  yet  been
       documented. Till they are, here are some resources:

       · zmNinja, the open source mobile app for ZoneMinder is 100% based on ZM APIs. Explore its
         source code to see how things work.

       · Launch up ZM console in a browser, and do an “Inspect source”. See how images are  being
         rendered.  Go  to  the  networks  tab  of the inspect source console and look at network
         requests that are made when you pause/play/forward streams.

       · If you still can’t find an answer, post your question in  the  forums  (not  the  github
         repo).

FAQ

       This is the FAQ page. Feel free to contribute any FAQs that you think are missing.

   How can I stop ZoneMinder filling up my disk?
       Recent  versions  of  ZoneMinder  come  with a filter you can use for this purpose already
       included.  The filter is called PurgeWhenFull and to find it,  choose  one  of  the  event
       counts  from  the  console  page,  for  instance  events in the last hour, for one of your
       monitors. Note that this filter is automatically enabled if you  do  a  fresh  install  of
       ZoneMinder including creating a new database. If you already have an existing database and
       are upgrading ZoneMinder, it will retain the settings of  the  filter  (which  in  earlier
       releases  was  disabled  by default). So you may want to check if PurgeWhenFull is enabled
       and if not, enable it.

       To enable it, go to Web Console, click on any of your Events  of  any  of  your  monitors.
       This will bring up an event listing and a filter window.

       In  the filter window there is a drop down select box labeled ‘Use Filter’, that lets your
       select a saved filter. Select ‘PurgeWhenFull’ and it will load that filter.

       Make any modifications you might want, such as the percentage full you want it to kick in,
       or  how many events to delete at a time (it will repeat the filter as many times as needed
       to clear the space, but will only delete this many events each time to get there).

       Then click on ‘Save’ which will bring up  a  new  window.  Make  sure  the  ‘Automatically
       delete’  box  is  checked  and  press  save to save your filter. This will then run in the
       background to keep your disk within those limits.

       After you’ve done that, you changes will automatically be loaded into  zmfilter  within  a
       few minutes.

       Check  the  zmfilter.log file to make sure it is running as sometimes missing perl modules
       mean that it never runs but people don’t always realize.

       Purge By Age To delete events that are older than 7 days, create a new filter with  “Date”
       set  to  “less  than”  and a value of “-7 days”, sort by “date/time” in “asc”ending order,
       then enable the checkbox “delete all matches”. You can also use a value of  week  or  week
       and days: “-2 week”  or “-2 week 4 day”

       Save  with ‘Run Filter In Background’ enabled to have it run automatically.  Optional skip
       archived events:  click on the plus sign next to -7 days to add another condition.   “and”
       “archive status” equal to “unarchived only”.

       Optional  slow  delete:  limit the number of results to 3.  If you have a large backlog of
       events that would be deleted, this can hard spike the CPU usage for a long time.  Limiting
       the  number of results to only the first three each time the filter is run spreads out the
       delete processes over time, dramatically lessening the CPU load.

       There are two methods for ZM to remove files when they are deleted that can  be  found  in
       Options under the System tab ZM_OPT_FAST_DELETE and ZM_RUN_AUDIT.

       ZM_OPT_FAST_DELETE:

       Normally  an  event  created  as the result of an alarm consists of entries in one or more
       database tables plus the various files associated with it. When  deleting  events  in  the
       browser  it  can  take  a long time to remove all of this if you are trying to do a lot of
       events at once. If you are running on an older or under-powered system, you  may  want  to
       set  this  option  which means that the browser client only deletes the key entries in the
       events table, which means the events will no longer appear in the listing, and leaves  the
       zmaudit  daemon  to  clear  up  the rest later. If you do so, disk space will not be freed
       immediately so you will need to run  zmaudit  more  frequently.   On  modern  systems,  we
       recommend that you leave this off.

       ZM_RUN_AUDIT:

       The  zmaudit  daemon exists to check that the saved information in the database and on the
       file system match and are consistent with each other. If an error occurs  or  if  you  are
       using ‘fast deletes’ it may be that database records are deleted but files remain. In this
       case, and similar, zmaudit will remove redundant information to synchronize the  two  data
       stores.  This  option controls whether zmaudit is run in the background and performs these
       checks and fixes continuously. This is recommended for most systems however if you have  a
       very  large number of events the process of scanning the database and file system may take
       a long time and impact performance. In this case  you  may  prefer  to  not  have  zmaudit
       running unconditionally and schedule occasional checks at other, more convenient, times.

       ZM_AUDIT_CHECK_INTERVAL:

       The  zmaudit  daemon exists to check that the saved information in the database and on the
       files system match and are consistent with each other. If an error occurs or  if  you  are
       using ‘fast deletes’ it may be that database records are deleted but files remain. In this
       case, and similar, zmaudit will remove redundant information to synchronize the  two  data
       stores.  The  default  check interval of 900 seconds (15 minutes) is fine for most systems
       however if you have a very large number of events the process of scanning the database and
       file  system  may  take a long time and impact performance. In this case you may prefer to
       make this interval much larger to reduce the impact on your system. This option determines
       how often these checks are performed.

   Math for Memory: Making sure you have enough memory to handle your cameras
       One  of  the  most  common issues for erratic ZoneMinder behavior is you don’t have enough
       memory to handle all your cameras. Many users often configure multiple HD cameras at  full
       resolution  and  15FPS or more and then face various issues about processes failing, blank
       screens and other completely erratic behavior. The core reason for  all  of  this  is  you
       either  don’t  have  enough  memory or horsepower to handle all your cameras. The solution
       often is to reduce FPS, reduce cameras or bump up your server capabilities.

       Here are some guidelines with examples on how you can figure out how much memory you need.
       With  respect to CPU, you should benchmark your server using standard unix tools like top,
       iotop and others to make sure your CPU load is manageable. ZoneMinder also  shows  average
       load on the top right corner of the Web Console for easy access.

       In general a good estimate of memory required would be:

          Min Bits of Memory = 20% overhead * (image-width*image-height*image buffer size*target color space*number of cameras)

       Where:  * image-width and image-height are the width and height of images that your camera
       is configured for (in my case, 1280x960). This value is in the Source tab for each monitor
       *  image buffer size is the # of images ZM will keep in memory (this is used by ZM to make
       sure it has pre and post images before detecting an alarm - very  useful  because  by  the
       time  an  alarm is detected, the reason for the alarm may move out of view and a buffer is
       really useful for this, including for  analyzing  stats/scores).  This  value  is  in  the
       buffers  tab  for  each  monitor  * target color space is the color depth - 8bit, 24bit or
       32bit. It’s again in the source tab of each monitor The 1.2  at  the  start  is  basically
       adding  20%  on  top  of the calculation to account for image/stream overheads (this is an
       estimate)

       The math breakdown for 4 cameras running at 1280x960 capture,  50  frame  buffer,  24  bit
       color space:

          1280*960 = 1,228,800 (bytes)
          1,228,800 * (3 bytes for 24 bit) = 3,686,400 (bytes)
          3,686,400 * 50 = 184,320,000 (bytes)
          184,320,000 * 4 = 737,280,000 (bytes)
          737,280,000 / 1024 = 720,000 (Kilobytes)
          720,000 / 1024 = 703.125 (Megabytes)
          703.125 / 1024 = 0.686 (Gigabytes)

       Around 700MB of memory.

       So if you have 2GB of memory, you should be all set. Right? Not, really:

          · This  is  just the base memory required to capture the streams. Remember ZM is always
            capturing streams irrespective of whether you are actually recording or not - to make
            sure its image ring buffer is there with pre images when an alarm kicks in.

          · You also need to account for other processes not related to ZM running in your box

          · You  also  need  to account for other ZM processes - for example, I noticed the audit
            daemon takes up a good amount of memory when it runs, DB updates also take up memory

          · If you are using H264 encoding, that buffers a lot of frames in memory as well.

       So a good rule of thumb is to make sure you have twice the memory as the calculation above
       (and  if  you  are  using  the ZM server for other purposes, please factor in those memory
       requirements as well)

       Also remember by default ZM only uses 50% of your available memory unless you change it

       As it turns out, ZM uses mapped memory and by default, 50% of your physical memory is what
       this will grow to. When you reach that limit , ZM breaks down with various errors.

       (Note: Mapped memory is applicable when you install ZoneMinder with mapped memory support,
       which is the default mode. If you have specifically disabled mapped memory then please see
       the next FAQ enty on how to increase shared memory)

       A good way to know how much memory is allocated to ZM for its operation is to do a df -h

       A sample output on Ubuntu:

          pp@camerapc:~$ df -h|grep "Filesystem\|shm"
          Filesystem                 Size  Used Avail Use% Mounted on
          tmpfs                      2.6G  923M  1.7G  36% /run/shm

       The  key  item  here  is tmpfs –> the example above shows we have allocated 1.7G of mapped
       memory space of which 36% is used which is a healthy number. If you are seeing Use%  going
       beyond 70% you should probaby increase the mapped memory.

       For  example,  if you want to increase this limit to 70% of your memory, add the following
       to /etc/fstab tmpfs SHMPATH tmpfs defaults,noexec,nosuid,size=70% 0 0 where SHMPATH is the
       Mounted on path.  Here, that would be /run/shm.  Other systems may be /dev/shm.

   What  does  a  ‘Can’t shmget: Invalid argument’ error in my logs mean? (and my camera does not
       display at higher resolutions)
       (Note: This is applicable for systems that have mapped memory disabled in  ZoneMinder.  By
       default,  Mapped  memory is enabled and unless you have disabled it manually, please refer
       to the “Math for Memory” question above and how to increase mapped memory limits)

       This error is discussed in the README in the following excerpt:- ‘’…this is caused  by  an
       attempt  to  allocate  an amount of shared memory greater than your system can handle. The
       size it requests is based on the following formula, ring buffer size x image width x image
       height x 3 (for 24 bit images) + a bit of overhead.

       So, for example:

          384x288 capture resolution, that makes: 110 592 pixels
          in 24 bit color that's x 3 = 331,776 bytes per frame
          by 80 frames ring buffer x80 = 26,542,080 bytes per camera
          by 4 cameras x4 = 106,168,320 bytes.
          Plus 10% overhead = 116,785,152 bytes
          Thats 114,048 kB, respectively 111.38 MB.
          If my shared memory is set to 134,217,728, which is exactly 128MB,
          that means I shouldn't have any problem.
          (Note that 1kbyte = 1024bytes, 1MB = 1024 kB)

       If for instance you were using 24bit 640x480 then this would come to about 92Mb if you are
       using the default buffer size of 100. If this is too large then you can either reduce  the
       image  or  buffer  sizes or increase the maximum amount of shared memory available. If you
       are using RedHat then you can get details on how to change these settings here

       You should be able to use a similar procedure  with  other  distributions  to  modify  the
       shared  memory  pool  without  kernel  recompilations  though  in  some  cases this may be
       necessary. Note, this error also sometimes occurs if you have an old shared memory segment
       lying around from a previous run that is too small. Use the ipcs and ipcrm system commands
       to check and remove it if necessary.’”

       You can often find out how many 4KB shared  memory  pages  are  available  by  typing  the
       following :-

          # cat /proc/sys/kernel/shmall
          2097152

       In  recent  kernels the shmall is set to 2097152 memory pages multiplied by 4096 bytes per
       page for a total of 8 GB of shared memory available.  You only need to increase the shmall
       value  if  you have a computer with more than 8GB of memory and wish to use more of it for
       shared memory usage, such as large databases.

       The most shared memory bytes you can allocate in one go :-

          # cat /proc/sys/kernel/shmmax
          33554432

       In recent kernels the shmmax is set to 33554432 bytes for only 32  MB  of  maximum  shared
       memory  allocatable at a time, hardly enough for ZoneMinder to go above 320 x 240 x 24-bit
       resolution at 40 frames in the buffer if it is using the /dev/shm shared memory device, so
       this  value  needs  to  be  increased.  If you are using ZoneMinder with the memory mapped
       (mmap) compile time option then this doesn’t affect you.

       To change the value to 128 MB temporarily during this kernel execution type (for  example)
       :- echo 536870912 >/proc/sys/kernel/shmmax

       Be sure to restart ZoneMinder after this.

       However be aware that sometimes you will only need to change the shmmax value as shmall is
       often large enough. Also changing these values in this way is only  effective  until  your
       machine is rebooted.

       To  change  them  permanently you will need to edit /etc/sysctl.conf and add the following
       lines (for example) :- kernel.shmmax = 536870912

       Or if your distribution has the /etc/sysctl.d/ folder you can create a file in this folder
       without  modifying  the /etc/sysctl.d so you won’t lose the changes during distro upgrades
       :- `echo kernel.shmmax = 536870912 >/etc/sysctl.d/60-kernel-shm.conf`

       To load these settings in the sysctl.conf file type: sysctl -p

       To check your shared memory settings type: ipcs -l

       Note that with Megapixel cameras like the Axis 207mw becoming cheaper and more attractive,
       the  above  memory  settings  are  not  adequate.  To  get  Zoneminder working with a full
       1280x1024 resolution camera in full color, increase 134217728 (128 MB)  to,  for  example,
       268435456 (256 MB) and multiple this value by each camera.

       These changes will now also be set the next time your machine is restarted.

       Versions  1.24.x of ZoneMinder also allows you to use an alternate method of shared memory
       allocation, Mmap mapped memory . This requires less configuration and can  be  simpler  to
       use.  Mapped  memory  allows you to use a special type of file as the placeholder for your
       memory and this file is ‘mapped’ into memory space for easy and fast access.

       To enable mapped memory in ZoneMinder you need add add the –enable–mmap=yes switch to your
       configure  line.  By  default  mapped  memory  files are created in /dev/shm which on most
       distributions is a dedicated pseudo-partition containing memory formatted as a filesystem.
       If  your  system  uses  a  different  path  then  this  can  be  changed  in ZoneMinder in
       Options->paths->PATH_MAP. It uses a filesystem type called tmpfs. If you type  df  -h  you
       should  see  this  area  and  the size of memory it currently allows. To increase size for
       tmpfs you need to  edit  /etc/default/tmpfs.  Search  for:  SHM_SIZE=128M  and  change  to
       something  like  SHM_SIZE=1G  then  reboot  the  system. You could possibly need to change
       RUN_SIZE, too.

       It is important that you do not use a disk based filesystem for your memory  mapped  files
       as  this  will  cause  memory access to be extremely slow. ZoneMinder creates files called
       .zm.mmap.<monitor id> in the mapped memory filesystem.

       Mapped memory is subject to the same limitations in terms of total memory  as  using  more
       traditional  shared memory but does not require any configuration per allocation or chunk.
       In future versions of ZoneMinder this will be the default shared memory storage method.

       Another good article about shared memory settings can be found here .

       The essential difference was that the kernel.shmall setting is  NOT  in  a  direct  memory
       setting in KB but in pages of memory. it is Max Pages of memory

       For  example:  If you want to allocate a maximum memory setting to 8GB you have to convert
       it to the number of pages (or segments).  with a  page  size  of  4096.   kernel.shmall  =
       8000x1024x1024/4096  kernel.shmall  =  2097152 NOT 8388608000 as would be suggested in the
       RedHat article linked above.

       shmmax is the max amount to allocate in one request - this is is an actual memory size (as
       opposed to pages) set to 4GB kernel.shmmax = 4294967296

       The /etc/sysctl.conf would have these lines

          kernel.shmall = 2097152
          kernel.shmmax = 4294967296</pre>

       As  above,  reload your sysctl.conf with sysctl -p and check that the settings are correct
       with ipcs -l.

   I have enabled motion detection but it is not always being triggered when things happen in the
       camera view
       ZoneMinder  uses zones to examine images for motion detection. When you create the initial
       zones you can choose from a number of preset values for sensitivity etc. Whilst these  are
       usually a good starting point they are not always suitable for all situations and you will
       probably need to tweak the values for your specific circumstances.  The  meanings  of  the
       various settings are described in the documentation (here) however if you believe you have
       sensible settings configured then there are two diagnostic approaches you can use.

       Another user  contributed  illustrated  Zone  definition  guide  can  be  found  here:  An
       illustrated guide to Zones

   Event Statistics
       The  first  technique  is  to  use  event  statistics.  Firstly you should ensure they are
       switched on in Options->Logging->RECORD_EVENT_STATS. This will then cause the  raw  motion
       detection  statistics for any subsequently generated events to be written to the DB. These
       can then be accessed by first clicking on the Frames or Alarm Frames values of  the  event
       from  any  event list view in the web gui. Then click on the score value to see the actual
       values that caused the event. Alternatively the stats can be accessed by clicking  on  the
       ‘Stats’ link when viewing any individual frame. The values displayed there correspond with
       the values that are used in the zone configuration and give you  an  idea  of  what  ‘real
       world’ values are being generated.

       Note that if you are investigating why events ‘do not’ happen then these will not be saved
       and so won’t be accessible. The best thing to do in that circumstance is to make your zone
       more sensitive so that it captures all events (perhap even ones you don’t want) so you can
       get an idea of what values are being generated and then  start  to  adjust  back  to  less
       sensitive  settings  if  necessary.  You  should  make sure you test your settings under a
       variety of lighting conditions (e.g. day and night, sunny or dull) to get  the  best  feel
       for that works and what doesn’t.

       Using  statistics will slow your system down to a small degree and use a little extra disk
       space in the DB so once you are happy you  can  switch  them  off  again.  However  it  is
       perfectly  feasible  to keep them permanently on if your system is able to cope which will
       allow you to review your setting periodically.

   Diagnostic Images
       The second approach is to use diagnostic images which are saved copies of the intermediate
       images that ZM uses when determining motion detection. These are switched on and off using
       Options->Logging->RECORD_DIAG_IMAGES.

       There are two kinds of diagnostic images which  are  and  are  written  (and  continuously
       overwritten)  to  the top level monitor event directory. If an event occurs then the files
       are additionally copied to the event directory and  renamed  with  the  appropriate  frame
       number as a prefix.

       The first set are produced by the monitor on the image as a whole. The diag-r.jpg image is
       the current reference image against which all  individual  frames  are  compared  and  the
       diag-d.jpg  image  is  the  delta  image highlighting the difference between the reference
       image and the last analysed image. In this images identical pixels will be black  and  the
       more  different  a  pixel is the whiter it will be. Viewing this image and determining the
       colour of the pixels is a good way of getting a feel for the pixel differences  you  might
       expect (often more than you think).

       The  second  set  of diag images are labelled as diag-<zoneid>-<stage>.jpg where zoneid is
       the id of the zone in question (Smile) and the stage is where in the alarm  check  process
       the  image  is generated from. So if you have several zones you can expect to see multiple
       files. Also these files are only interested in what is happening in their  zone  only  and
       will  ignore anything else outside of the zone. The stages that each number represents are
       as follows,

       # Alarmed Pixels - This image shows all pixels in the  zone  that  are  considered  to  be
       alarmed  as  white  pixels  and all other pixels as black.  # Filtered Pixels - This is as
       stage one except that all pixels removed by the filters are now black.  The  white  pixels
       represent  the  pixels that are candidates to generate an event.  # Raw Blobs - This image
       contains all alarmed pixels from stage 2 but aggrageted into blobs. Each blob will have  a
       different  greyscale  value  (between 1 and 254) so they can be difficult to spot with the
       naked eye but using a colour picker or photoshop will make it easier to see what  blob  is
       what.   #  Filtered  Blobs - This image is as stage 3 but under (or over) sized blobs have
       been removed. This is the final step before determining if an  event  has  occurred,  just
       prior  to  the  number  of  blobs  being  counted.  Thus  this  image  forms the basis for
       determining whether an event is generated and outlining on alarmed images is done from the
       blobs in this image.

       Using  the  above  images  you  should  be  able to tell at all stages what ZM is doing to
       determine if an event should happen or not. They are useful diagnostic  tools  but  as  is
       mentioned  elsewhere  they  will  massively slow your system down and take up a great deal
       more space. You should never leave ZM running for  any  length  of  time  with  diagnostic
       images on.

   Why  can’t  ZoneMinder capture images (either at all or just particularly fast) when I can see
       my camera just fine in xawtv or similar?
       With capture cards ZoneMinder will pull images as fast as it possibly can  unless  limited
       by  configuration.  ZoneMinder  (and  any  similar  application)  uses  the  frame grabber
       interface to copy frames from video memory into user memory. This takes some time, plus if
       you  have  several inputs sharing one capture chip it has to switch between inputs between
       captures which further slows things down.

       On average a card that can capture at 25fps per chip PAL  for  one  input  will  do  maybe
       6-10fps for two, 1-4fps for three and 1-2 for four. For a 30fps NTSC chip the figures will
       be correspondingly higher. However sometimes it is necessary to  slow  down  capture  even
       further  as  after  an  input switch it may take a short while for the new image to settle
       before it can be captured without corruption.

       When using xawtv etc to view the stream you are not looking at an image captured using the
       frame  grabber  but  the  card’s  video  memory  mapped onto your screen. This requires no
       capture or processing unless you do an explicit capture via  the  J  or  ctrl-J  keys  for
       instance.  Some  cards or drivers do not support the frame grabber interface at all so may
       not work with ZoneMinder even though you can view the stream in xawtv. If you can  grab  a
       still  using  the  grab  functionality  of  xawtv then in general your card will work with
       ZoneMinder.

   Why can’t I see streamed images when I can see stills in the Zone window etc?
       This issue is normally down to one of two causes

       1. You are using Internet Explorer and are trying to view multi-part jpeg streams. IE does
          not  support  these  streams  directly,  unlike  most  other browsers. You will need to
          install Cambozola or another multi-part jpeg aware plugin to view them. To do this  you
          will  need  to  obtain the applet from the Downloads page and install the cambozola.jar
          file in the same directory as the  ZoneMinder  php  files.  Then  find  the  ZoneMinder
          Options->Images  page  and  enable  ZM_OPT_CAMBOZOLA and enter the web path to the .jar
          file in  ZM_PATH_CAMBOZOLA.  This  will  ordinarily  just  be  cambozola.jar.  Provided
          (Options  / B/W tabs) WEB_H_CAN_STREAM is set to auto and WEB_H_STREAM_METHOD is set to
          jpeg then Cambozola should be loaded next time you try and view a stream.

       ‘’‘NOTE’‘’: If you find that the Cambozola applet loads in IE but the applet just displays
       the  version  #  of  Cambozola  and  the author’s name (as opposed to seeing the streaming
       images),  you  may  need  to  chmod  (‘’-rwxrwxr-x’‘)   your   (‘’usr/share/zoneminder/’‘)
       cambozola.jar:

          sudo chmod 775 cambozola.jar

       Once I did this, images started to stream for me.

       2. The  other common cause for being unable to view streams is that you have installed the
          ZoneMinder cgi binaries (zms and nph-zms) in a different directory than your web server
          is  expecting.  Make  sure  that  the  –with-cgidir  option  you  use to the ZoneMinder
          configure script is the same as the CGI directory configure for your web server. If you
          are  using  Apache,  which  is  the most common one, then in your httpd.conf file there
          should be  a  line  like  ScriptAlias  /cgi-bin/  "/var/www/cgi-bin/"  where  the  last
          directory  in  the  quotes is the one you have specified. If not then change one or the
          other to match. Be warned that configuring apache can be complex so  changing  the  one
          passed   to  the  ZoneMinder  configure  (and  then  rebuilding  and  reinstalling)  is
          recommended in the first instance. If you change the apache config  you  will  need  to
          restart  apache for the changes to take effect. If you still cannot see stream reliably
          then try changing Options->Paths->ZM_PATH_ZMS to just use zms if nph-zms is  specified,
          or vice versa. Also check in your apache error logs.

       Also,  please  check the value of the ZM_PATH_ZMS setting under the Paths Options tab.  It
       is where you configure the  URL  to  the  zms  or  nph-zms  CGI  executable.   Under  most
       Debian-based  distros  this  value  should be /zm/cgi-bin/nph-zms but in the past may have
       been /cgi-bin/nph-zms or you may have configured it to be something else.

       Lastly, please look for errors created by the zmc processes.  If zmc isn’t  running,  then
       zms will not be able to get an image from it and will exit.

   I  have several monitors configured but when I load the Montage view in FireFox why can I only
       see two? or, Why don’t all my cameras display when I use the Montage view in FireFox?
       By default FireFox only supports a small number of  simultaneous  connections.  Using  the
       montage  view usually requires one persistent connection for each camera plus intermittent
       connections for other information such as statuses.

       You will need to increase the number of allowed connections to use the montage  view  with
       more  than  a  small  number of cameras.  Certain FireFox extensions such as FasterFox may
       also help to achieve the same result.

       To resolve this situation, follow the instructions below:

       Enter about:config in the address bar

       scroll down to browser.cache.check_doc_frequency 3 change the 3 to a 1

          browser.cache.disk.enable True -> False
          network.http.max-connections-per-server -> put a value of 100
          network.http.max-persistent-connections-per-proxy -> 100 again
          network.http.max-persistent-connections-per-server -> 100 again

   Why is ZoneMinder using so much CPU?
       The various elements of ZoneMinder can be involved  in  some  pretty  intensive  activity,
       especially  while analysing images for motion. However generally this should not overwhelm
       your machine unless it is very old or underpowered.

       There are a number of specific reasons why processor loads can be high either by design or
       by accident. To figure out exactly what is causing it in your circumstances requires a bit
       of experimentation.

       The main causes are.

          · Using a video palette other than greyscale or RGB24.  This  can  cause  a  relatively
            minor  performance  hit,  though  still  significant. Although some cameras and cards
            require using planar palettes ZM currently doesn’t support this format internally and
            each frame is converted to an RGB representation prior to processing. Unless you have
            compelling reasons for using YUV or reduced RGB type palettes  such  as  hitting  USB
            transfer  limits I would experiment to see if RGB24 or greyscale is quicker. Put your
            monitors into ‘Monitor’ mode so that only the capture daemons are running and monitor
            the  process  load  of  these  (the  ‘zmc’  processes) using top. Try it with various
            palettes to see if it makes a difference.

          · Big image sizes. A image of 640x480 requires at least four times the processing of  a
            320x240  image.  Experiment  with  different  sizes  to  see what effect it may have.
            Sometimes a large image is just two interlaced smaller frames so has no real  benefit
            anyway.  This  is  especially  true for analog cameras/cards as image height over 320
            (NTSC) or 352 PAL) are invariably interlaced.

          · Capture frame rates. Unless there’s a compelling reason in your case there  is  often
            little  benefit  in running cameras at 25fps when 5-10fps would often get you results
            just as good. Try changing your monitor settings to limit your cameras to lower frame
            rates.  You  can  still  configure  ZM  to ignore these limits and capture as fast as
            possible when motion is detected.

          · Run function. Obviously running in Record or Mocord modes or in Modect with  lots  of
            events generates a lot of DB and file activity and so CPU and load will increase.

          · Basic  default  detection zones. By default when a camera is added one detection zone
            is added which covers the whole image with a  default  set  of  parameters.  If  your
            camera  covers a view in which various regions are unlikely to generate a valid alarm
            (ie the sky) then I would experiment with reducing the zone sizes or adding  inactive
            zones  to blank out areas you don’t want to monitor. Additionally the actual settings
            of the zone themselves may not be optimal. When doing motion detection the number  of
            changed  pixels  above  a threshold is examined, then this is filter, then contiguous
            regions are calculated to see if an alarm is generated. If  any  maximum  or  minimum
            threshold  is  exceeded  according  to your zone settings at any time the calculation
            stops. If your settings always result in the calculations going through to  the  last
            stage  before  being failed then additional CPU time is used unnecessarily. Make sure
            your maximum and minimumzone thresholds are set to sensible values and experiment  by
            switching  RECORD_EVENT_STATS  on and seeing what the actual values of alarmed pixels
            etc are during sample events.

          · Optimise your settings. After  you’ve  got  some  settings  you’re  happy  with  then
            switching  off  RECORD_EVENT_STATS  will  prevent the statistics being written to the
            database which saves some time. Other settings which  might  make  a  difference  are
            ZM_FAST_RGB_DIFFS and the JPEG_xxx_QUALITY ones.

       I’m  sure  there are other things which might make a difference such as what else you have
       running on the box and memory sizes (make sure there’s no swapping going on).  Also  speed
       of  disk  etc  will make some difference during event capture and also if you are watching
       the whole time then you may have a bunch of zms processes running also.

       I think the biggest factors are image size, colour depth and  capture  rate.  Having  said
       that  I  also don’t always know why you get certains results from ‘top’. For instance if I
       have a ‘zma’ daemon running for a monitor that is capturing an image. I’ve  commented  out
       the  actual  analysis  so  all  it’s doing is blending the image with the previous one. In
       colour mode this takes ~11 milliseconds per frame on my system and the camera is capturing
       at  ~10fps.  Using  ‘top’  this reports the process as using ~5% of CPU and permanently in
       R(un) state. Changing to greyscale mode the blending takes ~4msec (as you would expect  as
       this  is  roughly  a  third  of  11)  but  top  reports the process as now with 0% CPU and
       permanently in S(leep) state. So an actual CPU resource usage change  of  a  factor  of  3
       causes huge differences in reported CPU usage. I have yet to get to the bottom of this but
       I suspect it’s to do with scheduling somewhere along the line and that maybe the greyscale
       processing will fit into one scheduling time slice whereas the colour one won’t but I have
       no evidence of this yet!

   Why is the timeline view all messed up?
       The timeline view is a new view allowing you to see a graph of alarm  activity  over  time
       and  to  quickly  scan  and  home in on events of interest. However this feature is highly
       complex and still in beta. It is based extensively on HTML div  tags,  sometimes  lots  of
       them.  Whilst  FireFox is able to render this view successfully other browsers, particular
       Internet Explorer do not seem able to cope and so present a messed up view, either  always
       or when there are a lot of events.  Using the timeline view is only recommended when using
       FireFox, however even then there may be issues.

       This function has from time to time been corrupted in the SVN release  or  in  the  stable
       releases, try and reinstall from a fresh download.

   How much Hard Disk Space / Bandwidth do I need for ZM?
       Please  see  this excel sheet or  this online excel sheet (both are user contributed excel
       sheets)

       Or go to this link for the Axis bandwidth calculator.  Although  this  is  aimed  at  Axis
       cameras it still produces valid results for any kind of IP camera.

       As  a  quick  guide  I have 4 cameras at 320x240 storing 1 fps except during alarm events.
       After 1 week 60GB of space in the volume where the events  are  stored  (/var/www/html/zm)
       has been used.

   When  I  try and run ZoneMinder I get lots of audit permission errors in the logs and it won’t
       start
       Many Linux distributions nowadays are built with security  in  mind.  One  of  the  latest
       methods  of achieving this is via SELinux (Secure Linux) which controls who is able to run
       what in a more precise way then traditional accounting and file based permissions  (link).
       If you are seeing entries in your system log like:
          Jun  11  20:44:02  kernel: audit(1150033442.443:226): avc: denied { read } for pid=5068
          comm=”uptime”              name=”utmp”              dev=dm-0               ino=16908345
          scontext=user_u:system_r:httpd_sys_script_t   tcontext=user_u:object_r:initrc_var_run_t
          tclass=file

       then it is likely that your system has SELinux enabled and  it  is  preventing  ZoneMinder
       from  performaing  certain  activities.  You  then  have  two choices. You can either tune
       SELinux to permit the required operations or you can disable SELinux entirely  which  will
       permit ZoneMinder to run unhindered. Disabling SELinux is usually performed by editing its
       configuration file (e.g., /etc/selinux/config) and then rebooting. However if  you  run  a
       public server you should read up on the risks associated with disabled Secure Linux before
       disabling it.

       Note that SELinux may cause errors other than those listed above. If you are in any  doubt
       then  it  can  be  worth  disabling SELinux experimentally to see if it fixes your problem
       before trying other solutions.

   How do I enable ZoneMinder’s security?
       In the console, click on Options. Check  the  box  next  to  “ZM_OPT_USE_AUTH”.  You  will
       immediately  be  asked  to  login.  The  default  username  is ‘admin’ and the password is
       ‘admin’.

       To Manage Users: In main console, go to Options->Users.

       You may also consider to use the web server security, for example,  htaccess  files  under
       Apache  scope;  You  may  even  use  this  as  an  additional/redundant security on top of
       Zoneminders built-in security features;

   Why does ZM stop recording once I have 32000 events for my monitor?
       Storing more than 32k files in a single folder is a limitation  of  some  filesystems.  To
       avoid this, enable USE_DEEP_STORAGE under Options.

       USE_DEEP_STORAGE  is  now the default for new ZoneMinder systems so this limitation should
       only apply to users upgrading from a previous version of ZoneMinder.

       Versions of ZM from 1.23.0 onwards allow you to have a deeper filesystem with fewer  files
       per  individual directory. As well as not being susceptible to the 32k limit, this is also
       somewhat faster.

       If you have upgraded from a previous version of ZoneMinder and this option is not  already
       enabled,  it  is  very  important  to  follow  the steps below to enable it on an existing
       system. Failure to properly follow these steps WILL RESULT IN LOSS OF YOUR DATA!

          # Stop ZoneMinder
          # Backup your event data and the dB if you have the available storage
          # Enable USE_DEEP_STORAGE under Options.
          # From the command line, run "sudo zmupdate.pl --migrate-events"
          # Monitor the output for any events that fail to convert.
          # After the conversion completes, you can restart ZoneMinder

       Note that you can re-run the migrate-events command if any error messages scroll  off  the
       screen.

       You  can  read  about  the  lack  of  a limit in the number of sub-directories in the ext4
       filesystem at: this link and see what tools may assist in your use of this filesystem here
       If  you  search  for  ext3 or reiserfs on the forums you will find various threads on this
       issue with guidance on how to convert.

   Managing system load (with IP Cameras in mind)
   Introduction
       Zoneminder is a superb application in every way, but it does a job that  needs  a  lot  of
       horsepower  especially  when  using multiple IP cameras. IP Cams require an extra level of
       processing to analogue cards as the  jpg  or  mjpeg  images  need  to  be  decoded  before
       analysing. This needs grunt. If you have lots of cameras, you need lots of grunt.

       Why  do ZM need so much grunt?  Think what Zoneminder is actually doing. In modect mode ZM
       is: 1. Fetching a jpeg from the camera. (Either in single part  or  multipart  stream)  2.
       Decoding  the  jpeg  image.   3.  Comparing  the zoned selections to the previous image or
       images and applying rules.  4. If in alarm state, writing  that  image  to  the  disk  and
       updating the mysql database.

       If  you’re  capturing  at  five  frames per second, the above is repeated five times every
       second, multiplied by the number of cameras. Decoding the images is what  takes  the  real
       power from the processor and this is the main reason why analogue cameras which present an
       image ready-decoded in memory take less work.

   How do I know if my computer is overloaded?
       If your CPU is running at 100% all the time, it’s probably overloaded (or running at exact
       optimisation).  If  the  load is consistently high (over 10.0 for a single processor) then
       Bad Things happen - like lost frames, unrecorded events etc. Occasional  peaks  are  fine,
       normal and nothing to worry about.

       Zoneminder  runs  on  Linux, Linux measures system load using “load”, which is complicated
       but gives a rough guide on what the computer is doing at any given time. Zoneminder  shows
       Load  on  the  main page (top right) as well as disk space. Typing “uptime” on the command
       line will give a similar guide, but with three figures to give a fuller measure of  what’s
       happening  over  a  period of time but for the best guide to see what’s happening, install
       “htop” - which gives easy to read graphs for load, memory and cpu usage.

       A load of 1.0 means the processor has “just enough to do right  now”.  Also  worth  noting
       that  a  load  of  4.0  means  exactly the same for a quad processor machine - each number
       equals a single processor’s workload. A very high load can be fine on a computer that  has
       a stacked workload - such as a machine sending out bulk emails, or working its way through
       a knotty problem; it’ll just keep churning away until  it’s  done.  However  -  Zoneminder
       needs  to  process information in real time so it can’t afford to stack its jobs, it needs
       to deal with them right away.

       For a better and full explanation of Load: Please read this

   My load is too high, how can I reduce it?
       (The previous documentation explained how to use turbo jpeg libraries as  an  optimization
       technique.  These  libraries  have  long  been  part  of standard linux distros since that
       article was authored and hence that section has been removed)

       Zoneminder is very tweakable and it’s possible to tune it to compromise. The following are
       good things to try, in no particular order;

          · If  your  camera allows you to change image size, think whether you can get away with
            smaller images. Smaller pics = less load. 320x240 is usually ok for close-up corridor
            shots.

          · Go  Black  and  White.  Colour  pictures use twice to three times the CPU, memory and
            diskspace but give little benefit to identification.

          · Reduce frames per second. Halve the fps, halve the workload. If your camera  supports
            fps  throttling  (Axis  do), try that - saves ZM having to drop frames from a stream.
            2-5 fps seems to be widely used.

          · Experiment with using jpeg instead of mjpeg. Some users have reported it gives better
            performance, but YMMV.

          · Tweak  the zones. Keep them as small and as few as possible. Stick to one zone unless
            you really need more. Read this for an easy to understand explanation along with  the
            official Zone guide.

          · Schedule.  If  you  are running a linux system at near capacity, you’ll need to think
            carefully about things like backups and scheduled tasks. updatedb - the process which
            maintains  a  file  database so that ‘locate’ works quickly, is normally scheduled to
            run once a day and if on a busy system can create a heavy increase on the  load.  The
            same  is  true  for  scheduled  backups,  especially  those which compress the files.
            Re-schedule these tasks to a time when the cpu is less likely to be busy, if possible
            -   and  also  use  the  “nice”  command  to  reduce  their  priority.  (crontab  and
            /etc/cron.daily/ are good places to start)

          · Reduce clutter on your PC. Don’t run X unless you really need it, the GUI is  a  huge
            overhead in both memory and cpu.

       More expensive options:

          · Increase  RAM.  If  your  system  is  having  to  use disk swap it will HUGELY impact
            performance in all areas. Again, htop is a good monitor  -  but  first  you  need  to
            understand  that  because  Linux is using all the memory, it doesn’t mean it needs it
            all - linux handles ram very differently to Windows/DOS and caches stuff.  htop  will
            show  cached  ram  as  a different colour in the memory graph. Also check that you’re
            actually using a high memory capable kernel - many kernels don’t enable  high  memory
            by default.

          · Faster  CPU.  Simple  but  effective.  Zoneminder  also works very well with multiple
            processor systems out of the box (if SMP is enabled in  your  kernel).  The  load  of
            different cameras is spread across the processors.

          · Try  building  Zoneminder  with processor specific instructions that are optimised to
            the system it will be running on, also  increasing  the  optimisation  level  of  GCC
            beyond -O2 will help.

          ./configure CFLAGS="-g -O3 -march=athlon-xp -mtune=athlon-xp" CXXFLAGS="-g -O3 -march=athlon-xp -mtune=athlon-xp"

       The  above  command is optimised for an Athlon XP cpu so you will need to use the specific
       processor tag for your cpu, also the compiler optimisation has been increased to -O3.

       You also need to put in your normal ./configure commands as if you were compiling with out
       this optimisation.

       A further note is that the compile must be performed on the system that Zoneminder will be
       running on as this optimisation will make it hardware specific code.

       Processor specific commands can be found in the GCC manual along with  some  more  options
       that                      may                     increase                     performanc.
       http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

       The below command has been used to compile Zoneminder on a Athlon XP system running CentOS
       5.5 and along with the  libjpeg-turbo  modification  to  reduce  the  CPU  load  in  half,
       libjpeg-turbo reduced the load by 1/3 before the processor optimisation.

          ./configure --with-webdir=/var/www/html/zm --with-cgidir=/var/www/cgi-bin CFLAGS="-g -O3 -march=athlon-xp -mtune=athlon-xp" CXXFLAGS="-D__STDC_CONSTANT_MACROS -g -O3 -march=athlon-xp -mtune=athlon-xp" --enable-mmap --sysconfdir=/etc/zm

       The following command has been used to compile Zoneminder 1.25 on a CentOS 6.0 system, the
       native command should choose the processor automatically during compile time,  this  needs
       to be performed on the actual system!!.

          CFLAGS="-g -O3 -march=native -mtune=native" CXXFLAGS="-D__STDC_CONSTANT_MACROS -g -O3 -march=native -mtune=native" ./configure  --with-webdir=/var/www/html/zm --with-cgidir=/var/www/cgi-bin --with-webuser=apache --with-webgroup=apache ZM_DB_HOST=localhost ZM_DB_NAME=zm ZM_DB_USER=your_zm_user ZM_DB_PASS=your_zm_password ZM_SSL_LIB=openssl

   What about disks and bandwidth?
       A  typical  100mbit  LAN will cope with most setups easily. If you’re feeding from cameras
       over smaller or internet links, obviously fps will be much lower.

       Disk  and  Bandwidth  calculators  are   referenced   on   the   Zoneminder   wiki   here:
       http://www.zoneminder.com/wiki/index.php/FAQ#How_much_Hard_Disk_Space_.2F_Bandwidth_do_I_need_for_ZM.3F

   Building ZoneMinder
   When running configure I am getting a lot of messages about not  being  able  to  compile  the
       ffmpeg libraries
       If you see output from configure that looks like this

          checking libavcodec/avcodec.h usability... no
          checking libavcodec/avcodec.h presence... yes
          configure: WARNING: libavcodec/avcodec.h: present but cannot be compiled
          configure: WARNING: libavcodec/avcodec.h:     check for missing
          prerequisite headers?
          configure: WARNING: libavcodec/avcodec.h: see the Autoconf documentation
          configure: WARNING: libavcodec/avcodec.h:     section "Present But
          Cannot Be Compiled"
          configure: WARNING: libavcodec/avcodec.h: proceeding with the compiler's
          result
          configure: WARNING:     ## ------------------------------------- ##
          configure: WARNING:     ## Report this to support@zoneminder.com ##
          configure: WARNING:     ## ------------------------------------- ##</pre>

       then it is caused not by the ZoneMinder build system but ffmpeg itself. However there is a
       workaround you can use which is to add CPPFLAGS=-D__STDC_CONSTANT_MACROS

       to the ZoneMinder ./configure command which should solve the issue. However this is not  a
       proper ‘fix’ as such, which can only come from the ffmpeg project itself.

   I cannot build ZoneMinder and am getting lots of undefined C++ template errors
       This  is  almost  certainly  due  to  the  ‘ccache’  package  which  attempts  to speed up
       compilation by caching compiled objects. Unfortunately one of the side effects is that  it
       breaks  the GNU g++ template resolution method that ZoneMinder uses in building by prevent
       files getting recompiled. The simplest way around this is to  remove  the  ccache  package
       using your distros package manager.

   How do I build for X10 support?
       You  do  not  need to rebuild ZM for X10 support. You will need to install the perl module
       and switch on X10 in the options, then restart. Installing the perl module is  covered  in
       the README amongst other places but in summary, do:
          perl -MCPAN -eshell install X10::ActiveHome quit

   Extending Zoneminder
   How can I get ZM to do different things at different times of day or week?
       If  you want to configure ZoneMinder to do motion detection during the day and just record
       at night, for example, you will need to use ZoneMinder ‘run states’.  A  run  state  is  a
       particular configuration of monitor functions that you want to use at any time.

       To  save  a run state you should first configure your monitors for Modect, Record, Monitor
       etc as you would want them during one of the times of day. Then click on the running state
       link  at  the  top  of the Console view. This will usually say ‘Running’ or ‘Stopped’. You
       will then be able to save the current state and give it a name, ‘Daytime’ for example. Now
       configure  your  monitors how you would want them during other times of day and save that,
       for instance as ‘Nighttime’.

       Now you can switch between these two states by selecting them from  the  same  dialog  you
       saved  them, or from the command line from issue the command ‘’zmpkg.pl <run state>’‘, for
       example ‘’zmpkg.pl Daytime’‘.

       The final step you need to take, is scheduling the time the changes take effect. For  this
       you  can  use  cron.  A  simple entry to change to the Daylight state at at 8am and to the
       nighttime state at 8pm would be as follows,

          0 8 * * * root /usr/local/bin/zmpkg.pl Daytime
          0 20 * * * root /usr/local/bin/zmpkg.pl Nighttime

       On Ubuntu 7.04 and possibly others, look in  /usr/bin  not  just  /usr/local/bin  for  the
       zmpkg.pl file.

       Although  the  example above describes changing states at different times of day, the same
       principle can equally be applied to days of the week or other more arbitrary periods.

   How can I use ZoneMinder to trigger something else when there is an alarm?
       ZoneMinder includes a perl API which means you can create a script to interact with the ZM
       shared  memory  data and use it in your own scripts to react to ZM alarms or to trigger ZM
       to generate new alarms. Full details are in the README or  by  doing  perldoc  ZoneMinder,
       perldoc  ZoneMinder::SharedMem  etc.   Below is an example script that checks all monitors
       for alarms and when one occurs, prints a message to the screen. You can add  in  your  own
       code to make this reaction a little more useful.

          #!/usr/bin/perl -w

          use strict;

          use ZoneMinder;

          $| = 1;

          zmDbgInit( "myscript", level=>0, to_log=>0, to_syslog=>0, to_term=>1 );

          my $dbh = DBI->connect( "DBI:mysql:database=".ZM_DB_NAME.";host=".ZM_DB_HOST, ZM_DB_USER, ZM_DB_PASS );

          my $sql = "select M.*, max(E.Id) as LastEventId from Monitors as M left join Events as E on M.Id = E.MonitorId where M.Function != 'None' group by (M.Id)";
          my $sth = $dbh->prepare_cached( $sql ) or die( "Can't prepare '$sql': ".$dbh->errstr() );

          my $res = $sth->execute() or die( "Can't execute '$sql': ".$sth->errstr() );
          my @monitors;
          while ( my $monitor = $sth->fetchrow_hashref() )
          {
              push( @monitors, $monitor );
          }

          while( 1 )
          {
              foreach my $monitor ( @monitors )
              {
                  next if ( !zmMemVerify( $monitor ) );

                  if ( my $last_event_id = zmHasAlarmed( $monitor, $monitor->{LastEventId} ) )
                  {
                      $monitor->{LastEventId} = $last_event_id;
                      print( "Monitor ".$monitor->{Name}." has alarmed\n" );
                      #
                      # Do your stuff here
                      #
                  }
              }
              sleep( 1 );
          }

   Trouble Shooting
       Here  are  some  things  that  will  help you track down whats wrong.  This is also how to
       obtain the info that we need to help you on the forums.

   What logs should I check for errors?
       ZoneMinder creates its own logs and are usually located in the /tmp directory.

       The ZoneMinder logs for the RPM packages are located in /var/log/zm.

       Depending on your problem errors can show up in any of these logs but, usually the logs of
       interest are zmdc.log and zmpkg.log if ZM is not able to start.

       Now since ZM is dependent on other components to work, you might not find errors in ZM but
       in the other components.

          */var/log/messages and/or /var/log/syslog
          */var/log/dmesg
          */var/log/httpd/error_log`` (RedHat/Fedora) or ``/var/log/apache2/error_log
          */var/log/mysqld.log`` (Errors here don't happen very often but just in case)

       If ZM is not functioning, you should always be able to find an error in at  least  one  of
       these logs. Use the [[tail]] command to get info from the logs. This can be done like so:
          tail -f /var/log/messages /var/log/httpd/error_log /var/log/zm/zm*.log

       This  will  append  any  data entered to any of these logs to your console screen (-f). To
       exit, hit [ctrl -c].

       More verbose logging for the ZoneMinder binaries is available by enabling the debug option
       from  the  control  panel and will be placed in the path you have configured for the debug
       logs. Output can be limited to a specific binary as described in the  Debug  options  page
       under the “?” marks.

   How can I trouble shoot the hardware and/or software?
       Here  are  some  commands  to  get  information  about  your  hardware.  Some commands are
       distribution dependent.  * [[lspci]] -vv –  Returns  lots  of  detailed  info.  Check  for
       conflicting  interrupts  or port assignments. You can sometimes alter interrupts/ ports in
       bios. Try a different pci slot to get a clue if it is HW conflict (command provided by the
       pciutils  package).   * [[scanpci]] -v  – Gives you information from your hardware EPROM *
       [[lsusb]] -vv – Returns lots of detail about USB  devices  (camand  provided  by  usbutils
       package).   *  [[dmesg]] – Shows you how your hardware initialized (or didn’t) on boot-up.
       You will get the most use of this.  * [[v4l-info]] – to see how driver is talking to card.
       look for unusual values.  * [[modinfo bttv]] – some bttv driver stats.  * [[zmu]]  -m 0 -q
       -v – Returns various information regarding a monitor configuration.   *  [[ipcs]]  ``   --
       Provides  information on the ipc facilities for which the calling process has read access.
       * ``[[ipcrm]] ``  -- The ipcrm command can be used  to  remove  an  IPC  object  from  the
       kernel.   *  ``cat  /proc/interrupts  – This will dispaly what interrupts your hardware is
       using.

   Why am I getting a  403  access  error  with  my  web  browser  when  trying  to  access  http
       //localhost/zm?
       The  apache web server needs to have the right permissions and configuration to be able to
       read  the  Zoneminder  files.  Check  the  forums  for  solution,  and  edit  the   apache
       configuration  and  change  directory  permissions  to  give  apache the right to read the
       Zoneminder files. Depending on your Zoneminder configuration, you would use  the  zm  user
       and group that Zoneminder was built with, such as wwwuser and www.

   Why am I getting broken images when trying to view events?
       Zoneminder  and the Apache web server need to have the right permissions. Check this forum
       topic and similar ones: http://www.zoneminder.com/forums/viewtopic.php?p=48754#48754

   Why is the image from my color camera appearing in black and white?
       If you recently upgraded to zoneminder 1.26, there is a per camera option that defaults to
       black  and  white and can be mis-set if your upgrade didn’t happen right. See this thread:
       http://www.zoneminder.com/forums/viewtopic.php?f=30&t=21344

       This may occur if you have a  NTSC  analog  camera  but  have  configured  the  source  in
       ZoneMinder  as  PAL  for  the Device Format under the source tab.  You may also be mislead
       because zmu can report the video port as being PAL  when  the  camera  is  actually  NTSC.
       Confirm  the  format  of  your  analog  camera  by checking it’s technical specifications,
       possibly found with the packaging it came in, on the manufacturers website, or even on the
       retail  website  where you purchased the camera.  Change the Device Format setting to NTSC
       and set it to the lowest resolution of 320 x 240.  If you have confirmed that  the  camera
       itself is NTSC format, but don’t get a picture using the NTSC setting, consider increasing
       the shared memory ‘’‘kernel.shmall’‘’ and ‘’‘kernel.shmmax’‘’ settings in /etc/sysctl.conf
       to  a  larger  value such as 268435456.  This is also the reason you should start with the
       320x240 resolution, so as to  minimize  the  potential  of  memory  problems  which  would
       interfere  with  your  attempts  to  troubleshoot  the device format issue.  Once you have
       obtained a picture in the monitor using the NTSC format,  then  you  can  experiment  with
       raising the resolution.

   Why do I only see blue screens with a timestamp when monitoring my camera?
       If  this camera is attached to a capture card, then you may have selected the wrong Device
       Source or Channel when configuring the monitor in the ZoneMinder console.  If you  have  a
       capture  card  with  2  D-sub  style  inputs(looks  like a VGA port) to which you attach a
       provided splitter that splits off multiple cables, then the splitter may  be  attached  to
       the  wrong  port.  For example, PV-149 capture cards have two D-sub style ports labeled as
       DB1 and DB2, and come packaged with a connector for one of these ports that splits into  4
       BNC  connecters.  The initial four video ports are available with the splitter attached to
       DB1.

   Why do I only see black screens with a timestamp when monitoring my camera?
       In the monitor windows where you see the black screen with a  timestamp,  select  settings
       and  enter  the  Brightness,  Contrast, Hue, and Color settings reported for the device by
       ‘’‘zmu -d <device_path> -q -v’‘’.  32768 may  be  appropriate  values  to  try  for  these
       settings.   After  saving  the  settings,  select  Settings  again  to  confirm they saved
       successfully.

   I am getting messages about a backtrace in my logs, what do I do?
       If you are seeing entries in your log like the following

          Jan 11 20:25:22 localhost zma_m2[19051]: ERR [Backtrace: /lib64/libc.so.6 [0x3347230210]]
          Jan 11 20:25:22 localhost zma_m2[19051]: ERR [Backtrace: /lib64/libc.so.6(memset+0xce) [0x334727684e]]
          Jan 11 20:25:22 localhost zma_m2[19051]: ERR [Backtrace: /usr/local/bin/zma [0x40ee9a]]
          Jan 11 20:25:22 localhost zma_m2[19051]: ERR [Backtrace: /usr/local/bin/zma [0x419946]]
          Jan 11 20:25:22 localhost zma_m2[19051]: ERR [Backtrace: /usr/local/bin/zma [0x4213cf]]
          Jan 11 20:25:22 localhost zma_m2[19051]: ERR [Backtrace: /usr/local/bin/zma(cos+0x35c) [0x404674]]
          Jan 11 20:25:22 localhost zma_m2[19051]: ERR [Backtrace: /lib64/libc.so.6(__libc_start_main+0xf4) [0x334721da44]]
          Jan 11 20:25:22 localhost zma_m2[19051]: ERR [Backtrace: /usr/local/bin/zma(cos+0xd1) [0x4043e9]]
          Jan 11 20:25:22 localhost zma_m2[19051]: INF [Backtrace complete]</pre>

       then you can help diagnose the problem by running a special command to translate  the  hex
       addresses into helpful information. This command is called addr2line and you can type ‘man
       addr2line’ for more information.  Basically addr2line takes two sets  of  parameters,  the
       first is the name of the binary file, and the second is a list of addresses. Both of these
       pieces of information are displayed in the logs. The filename is the first part after  the
       ‘Backtrace:’ tag, in this case /usr/local/bin/zma, though it may well be different in your
       case. Some of the lines refer to libraries rather than the zma executable but those can be
       ignored for now, the important part is noting which ZM binary is involved. The binary file
       is passed in following the -e flag. The addresses to pass to addr2line are those contained
       in  the ‘[]’ pairs. Again you can ignore those that are on a line that refers to a library
       but it will not hurt if you include them.  So in the example above, the command  would  be
       addr2line  -e  /usr/local/bin/zma 0x40ee9a 0x419946 0x4213cf 0x404674 0x4043e9 This should
       then dump out a more symbolic list containing source file names and line numbers,  and  it
       is  this  information  which  will be helpful if posted to the forums. Sometimes addr2line
       fails to produce useful output. This is usually because either the problem  is  so  severe
       that  it has corrupted the stack and prevented useful information from being displayed, or
       that you have either compiled ZM without the -g flag for debug, or you have  stripped  the
       binaries  of  symbol  information  after  installation.  This  this case you would need to
       rebuild temporarily with debug enabled for the information to be useful.

       This error some times happens when a linked camera looses its link or it is  corrupted  by
       the user or some other system event, try deleting the affected cameras and recreating them
       in the Zoneminder console.

   How do I repair the MySQL Database?
       There is two ways to go about this. In most cases you can run from the command prompt -> *
       mysqlcheck      –all-databases      –auto-repair     -p’‘’your_database_password’‘’     -u
       ‘’‘your_databse_user’‘’

       If that does not work then you will have to make sure that ZoneMinder is stopped then  run
       the  following  (nothing should be using the database while running this and you will have
       to adjust for your correct path if it is different). -> * myisamchk –silent  –force  –fast
       –update-state  -O  key_buffer=64M  -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M
       /var/lib/mysql//.MYI

   How do I repair the MySQL Database when the cli fails?
       In Ubuntu, the commands listed above do not seem to work.  However, actually doing  it  by
       hand  from  within  MySQL does.  (But that is beyond the scope of this document)  But that
       got me thinking…  And phpmyadmin does work.  Bring up a terminal.   sudo  apt-get  install
       phpmyadmin

       Now    go   to   http://zoneminder_IP/   and   stop   the   ZM   service.    Continue   to
       http://zoneminder_IP/phpmyadmin and select the zoneminder  database.   Select  and  tables
       marked  ‘in use’ and pick the action ‘repare’ to fix.  Restart the zoneminder service from
       the web browser.  Remove or disable the phpmyadmin tool, as it  is  not  always  the  most
       secure  thing  around,  and  opens your database wide to any skilled hacker.  sudo apt-get
       remove phpmyadmin

   I upgraded by distribution and ZM stopped working
       Some possibilities (Incomplete list and  subject  to  correction)  [[/usr/local/bin/zmfix:
       /usr/lib/libmysqlclient.so.15:    version    `MYSQL_5.0'    not    found    (required   by
       /usr/local/bin/zmfix)]]  :: Solution: Recompile and reinstall Zoneminder.   Any  time  you
       update a major version that ZoneMinder depends on, you need to recompile ZoneMinder.

   Zoneminder doesn’t start automatically on boot
       Check  the  list  for  log  entries  like “zmfix[766]: ERR [Can’t connect to server: Can’t
       connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)]  “.   What
       can  happen is that zoneminder is started too quickly after Mysql and tries to contact the
       database server before it’s ready. Zoneminder gets no answer and aborts.   August  2010  -
       Ubuntu  upgrades  seem to be leaving several systems in this state. One way around this is
       to add a delay to the  zoneminder  startup  script  allowing  Mysql  to  finish  starting.
       “Simply  adding ‘sleep 15’ in the line above ‘zmfix -a’ in the /etc/init.d/zoneminder file
       fixed my ZoneMinder startup problems!” - credit to Pada.

   Remote Path setup for Panasonic and other Camera
       On adding or editing the source you can select the preset link for the parameters for  the
       specified  camera  .   In version 1.23.3  presets for BTTV,Axis,Panasonic,GadSpot,VEO, and
       BlueNet are available . Selecting the presets  ZM fills up  the  required  value  for  the
       remote path variable

   Why do I get repeated/ mixed/unstable/ blank monitors on bt878-like cards (a.k.a. PICO 2000)
       Please have a check at [[Pico2000]];

   What causes “Invalid JPEG file structure: two SOI markers” from zmc (1.24.x)
       Some  settings that used to be global only are now per camera.  On the Monitor Source tab,
       if you are using Remote Protocol  “HTTP” and Remote Method “Simple”, try  changing  Remote
       Method to “Regexp”.

   Miscellaneous
   I  see ZoneMinder is licensed under the GPL. What does that allow or restrict me in doing with
       ZoneMinder?
       The ZoneMinder license is described at the end of the documentation and  consists  of  the
       following section
          This program is free software; you can redistribute it and/or modify it under the terms
          of the GNU General Public License as published by the Free Software Foundation;  either
          version 2 of the License, or (at your option) any later version.

          This  program  is  distributed  in  the  hope  that  it will be useful, but WITHOUT ANY
          WARRANTY; without even the  implied  warranty  of  MERCHANTABILITY  or  FITNESS  FOR  A
          PARTICULAR PURPOSE. See the GNU General Public License for more details.

       This  means  that  ZoneMinder  is  licensed  under  the  terms  described here. There is a
       comprehensive FAQ covering the  GPL  at  http://www.gnu.org/licenses/gpl-faq.html  but  in
       essence  you are allowed to redistribute or modify GPL licensed software provided that you
       release your distribution or modifications freely under the same terms. You are allowed to
       sell  systems  based on GPL software. You are not allowed to restrict or reduce the rights
       of GPL  software  in  your  distribution  however.  Of  course  if  you  are  just  making
       modifications  for  your  system  locally  you  are  not  releasing changes so you have no
       obligations in this case. I recommend reading the GPL FAQ for more  in-depth  coverage  of
       this issue.

   Can I use ZoneMinder as part of my commercial product?
       The  GPL  license  allows  you produce systems based on GPL software provided your systems
       also adhere to that license and any modifications you make are  also  released  under  the
       same terms.  The GPL does not permit you to include ZoneMinder in proprietary systems (see
       http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem for details). If you  wish
       to  include  ZoneMinder  in  this  kind of system then you will need to license ZoneMinder
       under different terms. This is sometimes possible and you will  need  to  contact  me  for
       further details in these circumstances.

CONTRIBUTING

       Source hosted at GitHub Report issues/questions/feature requests on GitHub Issues

       Pull  requests  are  very  welcome!  If  you  would  like to contribute, please follow the
       following steps.

       · Fork the repo

       · Open an issue at our GitHub Issues Tracker. Describe the bug that you’ve found,  or  the
         feature which you’re asking for. Jot down the issue number (e.g. 456)

       · Create your feature branch (git checkout -b 456-my-new-feature)

       · Commit  your  changes  (git  commit  -m  'Added  some feature') It is preferred that you
         ‘commit early and often’ instead of bunching all changes into a single commit.

       · Push your branch to your fork on github (git push origin 456-my-new-feature)

       · Create new Pull Request

       · The team will then review, discuss and hopefully merge your changes.

       Welcome to ZoneMinder’s documentation, the following resources are available

       userguide/index
              Guide to setting up ZoneMinder for the first time and detailed guides for using the
              ZoneMinder front end.

       api    Information on using the CakePHP based API for interfacing to ZoneMinder

       faq    Frequently Asked Questions

       contributing
              How  to  contribute  to ZoneMinder. As a community project we always need help, you
              don’t need to be a coder to test or update documentation.

       · genindex

       · modindex

       · search

AUTHOR

       https://github.com/ZoneMinder/ZoneMinder/graphs/contributors

COPYRIGHT

       2019, https://github.com/ZoneMinder/ZoneMinder/graphs/contributors

                                           Feb 11, 2019                             ZONEMINDER(1)