ZoneMinder Forums

The issue here is that you have set a root password for mysql instead of allowing it to use /etc/mysql/debian.cnf to auth. So ZM cannot do anything.

The problem is that we exit instead of trying to continue.

I will make it handle this a little more gracefully in .11

Works fine for me. Check for javascript errors.

Changes since 1.36.9 - Set shm->valid to false on disconnect. Fix linked monitors stopping after a while - Documentation update regard WEB_TITLE - Corrections to filters when using row locks. An error would commit, ending the transaction and locks. - Fix monitor type labels by adding an Unknown for...

Changes since 1.36.8 - fixes to do_debian_package.sh - Test for existence of AutoEmail and AutoMessage. Fixes #3369 issue 2. - Improve debug logging of packetqueue cleaning - Improvements to export. Fix tar -v, should be tar --version. make table width:100% and iframe height 100%. Always show thumb...

Need debug logs. With FFMPEG logging on.

You are using video encode? This means that the encoder cannot keep up. Try adding preset=ultrafast in encoder options.

The reason is starts out ok is that the encoder buffers a ton of frames before doing any real work.

Thanks for noticing and reporting! Fixed in master, will be in 1.36.11.

Your logs table is missing.

You can recreate it using the definition in /usr/share/zoneminder/db/zm_create.sql

zmaudit will only delete older events as in more than a day old, controlled by the Options->System->ZM_AUDIT_AGE

The best way is to use a filter and just let it run.

There is an issue where if analysis falls behind, and maximagebuffer is set too low, that none of the processes can continue. So zmwatch kills it and restarts. In 1.34 there was no concept of locking so frames would just be lost. The quick fix is to set MaxImagebuffer = 2*keyframe interval+1 or larg...

For the db connection count to be that high, there has to be that many zm processes accessing it. In 1.34, there was a zmc and a zma for each monitor. Now we just have zmc, so the number should be half of what it was in 1.34. ps ax | grep zm how many processes? I wonder if you have the zmu hanging a...

I wish someone with bootstrap or css skills would take some time and fixup our layout... I can do it, there is just too much to do though. Anyways... you can bump up your db limits.... what is underlying your db, spinning rust or ssd? I've been finding that a lagging db due to spinning rust can real...

Sounds like you are pushing some resource beyond it's limits. Could be space in /dev/shm, could be db connection limits, could be general limited ram/cpu.

You could just have ZM encode using preset=ultrafast, which is basically an mjpeg stream in an mp4. cpu overhead is pretty low.

There are a few tradeoffs, but I will put that button back.

First was easy to fix... not sure where the content for the second went...