Argh, I'm having this same issue on a fresh install of Ubuntu server 7.10 and 1.23.3 from Peter's .deb package. And I'm still having the "videos won't play when filter generated" problem I was having with 1.22.x and 7.04.
This is so frustrating. I'll look into your fix...I just can't understand why things always seem to require so much tweaking and fixing in order to get it working at a basic level.
foreach my $image_file ( <$arch_image_path/*.jpg> )
But while my zip files are now bigger (761K, for example) and the files are clearly being added based on tailing zmfilter.log, the zip files still show up as blank from Windows. Need to spend more time on this, but it's partway there.
Ok, the zip is readable from Winzip and Windows XP sp2 says the content is blocked for security. So it looks like the ZM piece is fixed, at least. Thanks too all who responded and Dom_ for the explanation of no directory listing in Perl.
A zip file is generated and emailed. Its big (i.e. 2-3M) and is readable in linux using unzip and windows using winzip 11, but the windows compressed folder option and also ark under linux will not read it?
So the zip file is getting generated, but seems to have some sort of wierd incompatibility.
I gave up; once I realized that zipping jpg files nets you absolutely nothing in terms of compression, I went with this solution that uploads jpgs directly instead of zips:
Now I can just view the "event.html" file (which I link to from my alarm notification emails) and I can see the whole event on one screen with clickable thumbnails.
Then I wrote a quick perl program to go through and periodically delete files and folders older than N days to reclaim disk space on my remote backup server.
Ah, just realised I'm sending as an email attachment, not ftping.
So I cant use this option.
It works, just certain unzippers dont like the file which I find quite baffling.
Kevin, did you try the "alternate mailer" option within ZM? On the email options tab (I believe) near the bottom, there's a checkbox to use newer (?) perl modules for sending the mail. I wonder if that would make a difference?
It didn't seem to work for me (none of my alarms turned into events for some reason), but you might give it a shot and see if it does a better job.
No I hadn't spotted that. Its actually set to the newer ones by default, which might explain why I've not seen this before on previous versions. I've set it back to the old one and will have a look at some of the events later.
Well spotted.
This doesn't make any difference either. Very strange. There has obvioulsy been some incompatibility introduced at some point, but at least I wan use winzip.
I'll agree with you on that, because I used to use the zip option as well and I don't think I ever had problems with it. But I can't say it's not some security patch that Microsoft issued via Windows Update, either - it may not be a "ZM change". There are threads about this issue all over the web, but few concrete solutions.
Since it's a security issue, I can imagine a couple of possibilities. I know that my ZM box sends mail as www-data@<<machine_name>> on behalf of <<email address on the options screen>>. This bothers me, but I can't figure out how to fix it. As I noted above, trying to change the mailer made all my alerts fail completely. So perhaps Windows doesn't like the fact that a ZIP file was sent on behalf of someone else. Try installing some local mail tools on your ZM box and mailing the ZM-generated zip file to yourself using OS mail tools. (On Ubuntu you can install mailutils to get a command line mail app.) If it works, that would isolate the problem to the ZM mailing system.
If that still fails, it is an issue with the zip file itself. Possibly a permissions issue - maybe the files are owned by one user and the zip is created by another user (unlikely, but hey...we're fishing here!). I would do a test by creating a zip file within windows with the same name as an event zip, move that to your box to an event that's already happened (with the same name, overwriting the existing zip with your "fake" zip), removing the "already sent" flag in the ZM event table, and resubmitting the event to zmfilter so that it emails it again. If it works, then you've definitely isolated the ZM zip method as the culprit. (Alternatively you could edit zmfilter.pl to just send the other zip file during an arbitrary alert, but I don't know how comfortable you are with Perl).
There may be other ZIP options within Perl or your OS that you can use, or you could try TAR compression, though it's a pain because Windows can't read TAR files natively.