A ZM 1.30.x to 1.34.x Upgrade - In Pictures (Post 1 of 2)

[valid-user]

Attached to this post a series of screen captures showing the 'monitorix' Linux (and Windows?) monitoring utility on the dedicated server that I use for Zoneminder.

I have captured the "Weekly" displays for a time period looking back 7 days from now. My upgrade took place on 9-May-2021; you can see that 'hit' in the graphs.

I have noticed that all of my CPU clocks are not max'd out.

My viewing network load has increased by at least 10 Mbps compared to pre-upgrade. No change in the number of viewing PCs; 2 in my case. No change in the camera settings. No change in the cycles being viewed; each PC looks at a different cycle of different cameras.

My cameras are completely separated (physically and logically) from my viewing network. The camera network is GE-capable, but the cameras are all 10/100 devices. The viewing network is GigE throughout; cabling, switching, NIC cards, and so on.

I have noticed that the Apache CPU load is also substantially increased after the upgrade.

MySQL is making more queries now, but that could be due to ZM DB scripts running in the background; something to check.

The biggest shock to me was the increased load in the viewing network; what the clients have to pull from the server.

Perhaps my upgrade experience is unique or perhaps it is to be expected. Hopefully these graphs will be of interest to others.

[iconnor]

None of this is of any use to us.

Post your config and logs.

[valid-user]

I looked for an "Archive Configs" feature in the web console but did not find it. So I'm not sure what you want.

I do not keep logs to save storage space and because ZM 1.30.x had been "completely trouble free" in the past.

My ZM setup is a basic "out of the box" config from 1.30.x that I upgraded to 1.34.x using ZM's own upgrade process followed by some "bug fixing" in the DB permissions (an issue documented across the web and findable in a web search).

All settings for Apache, PHP, or MySQL are "as specified" in the installation guide. I have not poked around under the hood with phpMySQL or anything like that. You could say that all of that stuff is as stock as it comes from the Linux distribution. In my case that is Devuan, and that is downstream from Debian, like Ubuntu is downstream from Debian (but you probably knew that).

My ZM config avoids using ZM features that ZM Help says are known to slow down the system; I'll sacrifice some accuracy in event capture for keeping system resources available. I applaud the very informative ZM help screens.

Right now I am bordering on reverting (actually it has to be a fresh install) to 1.30.x because of the following issues in 1.34.x:

- The new ZM web UI that is everywhere in ZM 1.34.x and appears to be "resource intensive" on the server side. PHP is server-side code, but it seems to be driving up Apache CPU usage in my case and possibly peaking out 1 CPU core. Contrast with ZM 'core' code that spreads it's work nicely across cores in both 1.30.x and 1.34.x.

- ZM Console claiming there are events, but then saying 0 Bytes of events exist in the downloaded video file. Repeatable problem. yes, I have checked my storage settings and ensured that my storage is available and there is PLENTY of space available. Maybe those settings need to be deleted and then re-saved? I have already verified them and "saved" them.

- ZM 1.34.x capturing far fewer (0.1 to 1 percent of the volume of my 1.30.x setup) events than ZM 1.30.x did, even when I intentionally do things in 1.34.x that were known event triggers in 1.30.x, like blocking a camera view for 15-30 seconds while cleaning it's lens. My cameras (all HikVision) change from color to B&W or the reverse and "visibly settle" (what I see) in a second or 2; it's probably faster than that.

- ZM 1.34.x required that I go through every event zone for every camera, re-select the "Fast vs Best" setting and then re-save it before any events would capture. Seriously, it was like I had added zones but forgot to choose the "Fast vs Best" setting.

- ZM event playback issues; events not playing back...blank (white) screen, but the web GUI is there!! Repeatable event.

- Dedicated ZM server now so resource constrained in Apache and 1 of 8 CPU cores (RAM is not constrained, nor is disk or network IO) that I cannot open up the occasional 3rd viewer to look at a single camera like I used to do.

With all due respect to the ZM developer, and I mean RESPECT with absolute sincerity, I like the 1.30.x product, and I upgraded to remain on a supported Linux version that has ZM in it's repositories, but I find the 1.34.x product to be entirely unacceptable for my simple use at home.

----

Why not use a separate repo for ZM like that of the ZM developer?

I have encountered repo dependency conflicts with some Linux apps; required package versions in conflict with repo-supported packages and sometimes cascading into more and more package version conflicts while attempting to resolve it. I do not wish to deal with that insanity in Linux. Suffering through "DLL expletive" in Windows was bad enough and left a very bad taste for that ugliness.


At least working with apps from the same Linux distro repo assures that dependency conflicts are not an issue. Yes, that means I might be a release or 2 behind on an app version, but I know the app will work, unless I want/need a feature in the most current app version (and then patience is required once you ask the repo maintainer to bump the app version).

That's enough. I think Sunday will be "revert" (actually full reinstall of 1.30.x) day for me. That means reprogramming all of my cameras and zone settings into ZM and what-not. So lots to do in preparation for that.

So if I have to run an "oldstable" Devuan release to get a version of ZM that works for my needs, and then it all becomes a long-running but entirely functional museum piece, like the Computer History Museum in Mountain View, California, then so be it.