Arch Linux User Repository

Lol, talk about the perfect timing... OK folks, crisis averted, nothing to see here, move along :P

@baslking thanks, your proposed fix does indeed work nicely. I was about to write a reply asking you to kindly provide some more info (if you have it) on what exactly it is that has introduced this issue, and whether it's something that should be reported to the libmp4v2 Arch package maintainers, or to mp4v2's upstream, or to Zoneminder's upstream...

But then on a hunch I tried to build Zoneminder from the latest master (instead of using the outdated 1.34.xx tagged releases) and what do you know, it actually built without a hitch.

As a result, because this is just the latest in a long list of issues that in these past few months have been traced back to the 1.34.xx codebase itself, I've found an IMHO better solution: for the time being I'm switching this package to using a git(-ish) versioning scheme instead of following the 1.34.xx tagged releases. This should help, as Zoneminder as a project seems to be in a state of flux lately, and Arch is not like Debian where changes in accompanying libraries are slow to come, so using "ancient" releases will just not cut it for us.

If anyone has a better solution to propose (I can understand why this could be an upsetting change for a server acting as an NVR for security purposes) please say so. Also, if anyone finds that this change makes Zoneminder noticeably more buggy (as git-master releases are prone to be) please report it here and if there's no easy fix, I'll switch back to 1.34.xx and use the hack provided by @baslking instead. EDIT: Just realized that after the update to 1.35.xx it will probably be impossible to downgrade your setup back to 1.34.xx due to the database scheme updates, so please MAKE SURE TO BACKUP YOUR DATABASE before updating.

@DaMadOne thanks ;-)

For the build problem of: @zazenhei, I had the same issue. It seems there's an error in the cmake file logic that doesn't handle the /usr/include/mp4v2/mp4v2.h nested include files in the place of /usr/include/mp4v2.h You see it comment that if does not find the header files but it carries on and the compile fails when the header file is needed. Since it never asks to include the header file its normal that the compile fails. A really simple hack to force cmake to chose the right option for the include in the PKGBUILD file in the build section for cmake if you add the define: -DHAVE_MP4V2_MP4V2_H=1 \ The build continues to the end, or it did for me. I'm new to zoneminder and built on a RPI-400 with aarch64 and libpm4v2 4.1.6-1 your mileage may vary.

Thanks @Nocifier. Downgrading libmp4v2 to 4.1.3 and then clean building ZoneMinder fixed it. I am greatly appreciative of your work and I thank you for what you do.

I run Proxmox with various VM/containers and I could only imagine the frustration of those without an easy backup/restore solution. Many of my VMs are Arch based which I prefer because of the control over them. However ZM has been a PITA on Arch for a long time. Thank you for being very tentative of this package!

Updated package to 1.34.24, tried to test build, got the MP4 errors previously reported by @zazenhei, downgraded libmp4v2, got the same errors, decided to not bother and uploaded the new version anyway.

If anyone has found a solution for these errors (as I said, downgrading libmp4v2 didn't work for me) I'd be grateful if they'd post it here, otherwise I'll just bear with it until 1.35 hopefully resolves the issue(s). Well, at least this release should be compatible with PHP 8 according to the changelog.

EDIT: Actually scratch that, turns out that downgrading libmp4v2 to 4.1.3 does fix the issue, it's just that I had to clean my working environment after having already tried to build with 4.1.4. So yeah, downgrading works.

@Mike616, thank you so much for your advice.

@everyone, unfortunately almost all these errors that have been variously plaguing our setups lately stem from the simple fact that ZM hasn't seen a new proper release in (relatively speaking) ages, while at the same time Arch is a fast moving distro that constantly pulls in all the newest versions of x264, x265, ffmpeg, php, dav1d, heif, etc etc, which ZM's latest stable release is obviously not very compatible with.

This isn't solely the devs' fault, because if we'd been using ZM on something like e.g. Debian this would not have been so much of a problem, so this situation is actually a superb example of why a rolling distro is not great for being used as a server for large and complex apps like ZM :)

new build error.

/home/xxx/.cache/yay/zoneminder/src/zoneminder-git/src/zm_video.h:158:2: error: ‘MP4FileHandle’ does not name a type
  158 |  MP4FileHandle mp4h;
      |  ^~~~~~~~~~~~~
/home/xxx/.cache/yay/zoneminder/src/zoneminder-git/src/zm_video.h:159:2: error: ‘MP4TrackId’ does not name a type
  159 |  MP4TrackId mp4vtid;
      |  ^~~~~~~~~~
make[2]: *** [src/CMakeFiles/zm.dir/build.make:104: src/CMakeFiles/zm.dir/zm_camera.cpp.o] error 1
make[1]: *** [CMakeFiles/Makefile2:414: src/CMakeFiles/zm.dir/all] error 2
make: *** [Makefile:156: all] error 2

I have downgraded libmp4. Then the problem was solved.

I also had issues with php not being able to load the php-gd library (causing issues with Nextcloud). It was still looking for the newer version of libx265. Downgrading libheif to 1.11.0-1 got php working again.

@Mike616 Thanks for sharing your steps. I had to downgrade dav1d as well (back to version 0.7.1-1).