@danielfullmer can we run zmupdate.pl on every service start so the user doesn't have to? Or do we add notes somewhere mentioning this?

@aanderse It looks like we can run zmupdate.pl on startup. I originally thought it might be a problem since the script is interactive by default--but the -nointeractive flag works for our use. The script doesn't do anything if the database is already at the current version.

Just added a commit addressing this. I've tested upgrading from 1.32.3 to 1.34.2 in a VM and it seems to work fine.

I had my reservations about forcing an automatic schema update back when discussed in #54630. However, I'm not using zoneminder on NixOS, so I, personally, don't mind the change.

@danielfullmer sorry my bad. I forgot that automatic database schema updates aren't universally accepted among the team. This is a judgement call that you can make. Keep the schema update or not. I think I'll start a discourse thread to get some feedback on the topic in general.

Any commiters please hold off on merging this for the time being. I've found an issue with the UI being unresponsive when configuring cameras that I would need to debug. (or anyone else interested)

With regard to automatic updating--I'm open to either option. If we do go for automatic schema updates I'd love to have someone else test it as well before this gets merged. One nice feature of manually running zmupdate.pl interactively is that it has optional functionality to make a database backup before updating.

I'm also very busy with my thesis at the moment so I'm not sure if I will get to fixing the UI issue in the next few days.

I've updated this PR with a few changes. It should be ready to merge after review.

Updated to 1.34.3.
Added a fix for improper timezone detection.

As far as automatic schema updates. I think we should do this only if services.zoneminder.database.createLocally is enabled. Zoneminder can be used with multiple instances backed by the same remote database--and we almost surely do not want to do automatic updates in that case. Conditionally updating the schema if it is a local database is also what upstream does in their debian postinstall script.

The UI issue was a result of zoneminder's "cache busting". They create symlinks in /var/cache/zoneminder to the js/css files, where the symlink has the timestamp of the destination file in the filename. This was intended to ensure that newer files would get a different URL. However, in the nix store, the files all have the timestamp "1". So when I upgraded, these symlinks would still point to the old version of zoneminder, and were not replaced. My solution was to patch the symlink filename calculation to replace the timestamp with just the hash of the zoneminder source.

@danielfullmer Please squash the last two commits and edit "zoneminder: 1.32.3 -> zoneminder 1.34.3" to "zoneminder: 1.32.3 -> 1.34.3"

@veprbl Just squashed those commits and fixed the commit title. Thanks!