Web Interface Improvements / Backend minor fixes

If you've made a patch to quick fix a bug or to add a new feature not yet in the main tree then post it here so others can try it out.
Post Reply
mitch
Posts: 169
Joined: Thu Apr 30, 2009 4:18 am

Web Interface Improvements / Backend minor fixes

Post by mitch »

***The below fixes were integrated into 1.24.2 the patch below is outdated***

Another round of various fixes and additions to help the stability of the web interface primarily.


All Live View: Stats would sometimes stop updating when watching events/streams, this should automatically fix itself now (fps/alarm status/new events)
All: Additional error checking and error messages both in the backend and web frontend.
All Live View: Immediately after an event ends the event list will refresh to show the new event rather than waiting for it to refresh on its own
ALL: nph-zms doesn't seem to work but zms does, this may be fixed in certain cases
ALL: zma would crash with certain zone setups, fixed in certain cases
ALL: For ffmpeg remote cameras the Path contains the entire URL and auth str this would get chopped off if > 64 chars
IE: Progress ticker wouldn't always properly update
IE: Alert sound would loop forever
IE: Cambozola applet will no longer cause local disk space to fill up. To enable this under config you should set Cambozola reload under Config->Images to some number of seconds. Generally 6-15 minutes (360-900 seconds) should work well without having your drive fill up too far.




Details:
zma crash - an improperly placed else if was causing, in certain situations, the hi_x variable of a range would not get set and would cause it to segfault.
nph-zms expected argv[0] to contain a full path to itself, however in many situations it would only get its name as argv[0] so changed the search to not require a '/' to be valid.
IE: Progress ticker and a few other text updates were broken due to using getText, a call IE doesn't support. switched to innerHTML which all modern browsers support reading on.
Stats stopping - A new watchdog system that will wait for up to double the timeout for a stream to return data. If it doesn't it will fire another request to get it going again.
IE: Sound loop - having something hidden in IE doesn't cause it not to play, instead IE now uses play/pause commands on the media player.
IE: Cambozola - It writes the mjpeg stream to cache which java stores on your hard drive, even at medium resolution of 640x480 you can very quickly fill up local storage if you keep live view open. To fix this we just reload the applet after a user specified amount of time, there is a quick flicker but it only needs to occur every few minutes. It will only reload the applet if it is playing and live.




Note there are two SQL changes that took place that are NOT automatically applied to your database if you apply this patch, the first is the change in the monitors table for the length of the Path var, this will not harm anything if it isn't done, the second however is more important and thats the addition of the cambozola config variable. Even if you don't want to use this you should apply it, for this reason to do it you should run "mysql zm" or go into the zone minder database and then run:

Code: Select all

insert into Config set Id = 182, Name = 'ZM_RELOAD_CAMBOZOLA', Value = '0', Type = 'integer', DefaultValue = '0', Hint = 'integer', Pattern = '(?-xism:^(\d+)$)', Format = ' $1 ', Prompt = 'After how many seconds should Cambozola be reloaded in live view', Help = '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.', Category = 'images', Readonly = '0', Requires = '';
The patch is at: http://mitchcapper.com/web_fixes_etc.patch
To apply this patch in your ZM checkout folder just do patch -p0 < zm_web_fixes.patch if you want to check if it will work against the dryrun option like: patch -p0 --dry-run < zm_web_fixes.patch . This is meant to be applied against trunk, it builds upon some of the other functions that are only in trunk, however it may also work if you just apply my other patch + this.


I am currently working on a fairly large patchset + external application that should help with exporting more data from ZM/act as a start to an API. In short it will allow for much easier setup and debugging of zones for motion detection. It will show the live video feed next to the motion detection frames, along with the active alarm detection stats (how many pixels the backend is finding etc). The idea being you can in real time have someone or something cause motion in the frame that you want to capture (or not capture) and see what values for threshold, alarm pixels, filter, blob, etc are being caused and just your zones as needed. A screenshot of it is below
Image

all 3 windows are streaming mjpeg feeds and the stats are updated at the same fps so it should make setting up zones easier.

As always feeback is welcomed along with any questions etc.
Last edited by mitch on Sun Jul 05, 2009 12:57 am, edited 1 time in total.
User avatar
rdmelin
Posts: 863
Joined: Wed Oct 29, 2003 2:23 pm
Location: Ellensburg, WA USA

Post by rdmelin »

Thanks mitch. And the new app looks very promising.
User avatar
Normando
Posts: 219
Joined: Sun Aug 17, 2008 5:34 am
Location: Rosario - Argentina

Post by Normando »

Hi Mitch. Good job!

I was tried the same using mjpeg streamer and inotify to get debuging images, but it is not easy. Your big patch look very good.
mitch
Posts: 169
Joined: Thu Apr 30, 2009 4:18 am

Post by mitch »

Yea I ran into a similar problem, primarily the fact that as they are constantly overwritten its very hard to grab the complete frames before they are written to again, the only way around it is to actually add code to the backend to export them after geration prior to being overwritten (thats how the events grab them), unfortunately this slows down an already overloaded zma even further. In addition its very intensive on the system as its a lot of additional IO writing that occurs. I think I solved both of these problems pretty well it should probably be ready within a week.
User avatar
Normando
Posts: 219
Joined: Sun Aug 17, 2008 5:34 am
Location: Rosario - Argentina

Post by Normando »

Yes, I have the same issues. I think this feature should be activated only for debug purposes (not continuosly), and one camera at a time.
mitch
Posts: 169
Joined: Thu Apr 30, 2009 4:18 am

Post by mitch »

yes, my modifications in no way add additional processing to the backend, and are only enabled when you have "generate additional debug images" turned on. While I don't support limiting it per camera, I do one better. If you are not actively grabbing the images, they arn't generated at all. This means even with the generation of them turned on there is vritually no load increase on the backend if you are not tapping into them. It is done per image, ie if you are watching the delta image for camera 4 then that is all that is written out, not all of them.
User avatar
zoneminder
Site Admin
Posts: 5215
Joined: Wed Jul 09, 2003 2:07 pm
Location: Bristol, UK
Contact:

Post by zoneminder »

Thanks for the input and fixes. I will apply the changes you have made (or something very similar) to the trunk as soon as possible.

Your other stuff is interesting too. The whole area of motion detection is undergoing something of a rewrite at the moment so that may change how your other app works in the future. Also there may be the possibility of adding dynamic streaming of all the various intermediate images via RTP which may make it easier to display all the simultaneous stages.
Phil
mitch
Posts: 169
Joined: Thu Apr 30, 2009 4:18 am

Post by mitch »

Thanks Phil, may want to wait a few more days I have a few other things I found including an important one that should be applied with the rest of this patch otherwise people can have some undesired results.
Post Reply