Force Alarm inside monitor page and fps count , 1.32.1 was working, 1.32.2 not working - BUG - when on virualhost

[multijohn]

Force Alarm inside monitor page and fps count , not working with 1.32.2 ! It was fixed on 1.32.1 !

Ubuntu 16.04

Force Alarm does not do anything, and fps just displaying "- fps"!

In Chrome's developer tools i am seeing the following error !

"Failed to load http://homeserver/zm/index.php/zm/index ... command=99: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://homeserver:8085' is therefore not allowed access."

I am running ZM on a virtual host (: 8085), and the problem was created by upgrading to 1.32.0 version, disappeared with 1.32.1, and came back with 1.32.2 !

Thank you ZM team !

[connortechnology]

I think I have this fixed in master already, will go into 1.32.3.

[SmokeyBR]

is this a small fix ? if so could you point us to the commits or changes so we can try it ?

[connortechnology]

Actually now I'm thinking it was still broken in master. Try out the latest commit: https://github.com/ZoneMinder/zoneminder/commit/e7ec2faccda692735cf2f7739d606eaf41400891

[SmokeyBR]

i am seeing same behavior after replacing the file "watch.js" (assuming replacing it is enough), someone else can confirm?

Failed to load http://domain.name/zm/index.php?view=request&request=status&entity=events&id=1&count=20&sort=Id%20desc: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://domain.name:5101' is therefore not allowed access.

[connortechnology]

I've applied yet another fix for when running on a non-standard port. Please try the latest.

[SmokeyBR]

i can confirm with these changes applied this issue has been resolved https://github.com/ZoneMinder/zoneminder/commit/e7ec2faccda692735cf2f7739d606eaf41400891 https://github.com/ZoneMinder/zoneminder/commit/f9b1453705fef14aa9c67193c2477f74eb739ed6

[Nocifer]

Yup, I can confirm this fixes the erroneous Ajax calls. Nice job. But this issue also affects the Zone view, namely at lines 474 and 549 in skins/classic/views/js/zone.js, which should also be changed accordingly.

EDIT: Hmm, actually I'm getting a 500 error. I suppose this could have something to do with my server configuration, since SmokeyBR reports the issue as resolved, but I find it weird that I get 200 on this request:

http://localhost:8095/index.php?view=request&request=status&entity=navBar

But 500 on this one:

http://localhost:8095/index.php?view=request&request=stream&connkey=435544&command=99

I'd think that a 200 on the first request would mean it's not really an issue with the configuration, since the only difference between them is the parameters given to index.php, but then again I could be wrong. I'll try to do some more tests. But anyway, what's certain is that the Ajax call is being formed correctly, there is no question about that.

EDIT 2: Alright, I think I got it. I found that the URL's parameters string is constructed as

var streamCmdParms = "view=request&request=stream&connkey="+connKey;

But this is only a starting point. Later on there are some other parameters that may be added before the Ajax request is made, e.g. "auth", which is added if authentication is enabled, and "command", which I guess is a command directed at the camera.

I'd already noticed that my URL parameters string is

view=request&request=stream&connkey=435544&command=99

so the problem is obviously this command "99", which as it turns out is the command "CMD_QUERY", which I'll take a guess and say it's a command to query the camera about what commands it can accept. Well, no matter if my guess is correct, the problem is that this "command=99" results in a 500 error, while removing it from the URL results in a 200. I also tried "command=2" (which is CMD_PLAY) and "command=3" (which is CMD_STOP) and neither of them worked, instead producing a 500 error as well.

Then I remembered that the control buttons under the camera stream have never worked for me for some reason. So on a hunch I clicked on them and yes, they produced those exact same 500 errors.

Long story short, and if my findings are correct, ZM is issuing commands to my camera but my camera is having trouble understanding those commands, and so these 500 errors are produced. This would also fit with SmokeyBR's experience, who in their case reported the issue as fixed, which would probably mean their camera is smarter than my dumb piece of junk. So, the real question: is this something that should be fixed on ZM's side, or is this a case of my camera being too old and/or cheap to properly function in a modern environment?

---

I understand that this turned out to be a completely different thing, but I don't know yet if it's something that will need to be investigated further, so for the time I won't be opening a new issue.

Much belated PS: Sorry that the comment is so long and full of useless drable, but I was in the midst of investigating the issue and was just writing down what I did just as I was doing it.

[SmokeyBR]

http://domain.name.ex:5101/zm/index.php i use subfolder /zm, without it seems to break a bunch of things (in my configuration at least)

[Nocifer]

@SmokeyBR

That's because of the problem outlined in issue #2253 - "montagereview.js contains hardcoded links to example.com/zm". There are some hardcoded links in ZM's code that point to a location /zm/, so if you run ZM in a port- or domain-based setup, or even from a different subdir (e.g. /zoneminder/) some things won't be working correctly or at all, including but not limited to the Montage Review.

A temporary fix is to either create a /zm location block in your conf file and redirect that to /, or create a link /zm/ inside your /www/ dir that points back to /www/. In both cases all calls to, say, /zm/index.php will actually call /index.php and voila, problem solved.

IMHO the second solution is better, for various reasons, but both will work so choose whatever suits you.

[Nocifer]

Just a small addendum to my first post - besides the control buttons not working, the camera status variables underneath are also unpopulated, like so:

Mode: Rate: x Delay: s Buffer: % Zoom: x

I'd suggest the script populating these variables could also be used to completely hide one or more of these status entries if the camera doesn't (or is unable to properly inform ZM if it does) support them (e.g. not all cameras have a Zoom function) or at least populate them with default values (e.g. 'x1.0' for Zoom, and maybe 'N/A' for the rest). Even if the script is already capable of that, it seems that failing to get a proper reply to its QUERY command (the aforementioned 500 error) breaks it and so the entries stay visible but unpopulated, just as the camera control buttons stay visible but unusable.

[gkthemac]

@Nocifer I too have non-functional playback control buttons below the video, with a 500 error in the apache logs when I click them. I'm sure if this is caused by a "dumb" camera or not, since all my cameras are Local i.e. analogue composite video connected to a video capture card and accessed via /dev/video*.

This issue also affects replay of past events, but only when the camera source is set to write each frame as an individual JPEG, with the Video Writer turned off. If I turn off Save JPEGs and set the Video Writer to x264 Encode then replay of events recorded from that point on do have working playback controls, with the added "benefit" of not being able to replay the old JPEG-saved events.

But even with x264 Encode switched on, the live camera views still have non-functional playback controls which do nothing except log 500 errors.

[lbdroid]

Those commands have nothing to do with smart vs. dumb cameras. They're just of the nature "play", "pause", "query", etc. Defined here; https://github.com/ZoneMinder/zoneminder/blob/master/web/includes/config.php.in#L106

[lbdroid]

FYI: The problem with command=99 is caused by this commit; https://github.com/ZoneMinder/zoneminder/commit/bc6d8623a6ef7e41cf5134c07c6cd8f449d977b7

It crashes on sem_get(..), which is NOT universally included in php builds. http://fr2.php.net/manual/en/sem.installation.php

Workaround for it is to add the following near the top of web/ajax/stream.php:

if (!function_exists('sem_get')) {
    function sem_get($key) {
        return fopen(__FILE__ . '.sem.' . $key, 'w+');
    }
    function sem_acquire($sem_id) {
        return flock($sem_id, LOCK_EX);
    }
    function sem_release($sem_id) {
        return flock($sem_id, LOCK_UN);
    }
}

if( !function_exists('ftok') )
{
    function ftok($filename = "", $proj = "")
    {
        if( empty($filename) || !file_exists($filename) )
        {
            return -1;
        }
        else
        {
            $filename = $filename . (string) $proj;
            for($key = array(); sizeof($key) < strlen($filename); $key[] = ord(substr($filename, sizeof($key), 1)));
            return dechex(array_sum($key));
        }
    }
}

[connortechnology]

Ok I will add these.

Which distro doesn't compile in semaphore support?

[ASerbinski]

Fedora 25 doesn't. I haven't had the opportunity to look at any other RH, like newer releases or EL.

I added a pull request with the change. Note that lbdroid is my alter ego.

[Nocifer]

Yup, this was the culprit, everything works correctly now. Thanks @ASerbinski !

Arch also does not enable the extension by default, but it's compiled in so it's just a matter of enabling it. Thanks again.

[gkthemac]

Gentoo only compiles semaphore support into PHP when the "sysvipc" USE flag is set; just done that and now my playback controls are working again.

[bradc87]

I am also having this issue on Arch Linux using the AUR package. Is there an eta on 1.32.3?

[lbdroid]

@bradc87 : You can just edit those TEXT files manually in your FS for the time being. Just add the code I attached above.

[connortechnology]

Can we please get an update and have this issue closed if 1.32.3 has fixed this issue?

[Nocifer]

The issues outlined in the OP are the result of two different things:

The malformed "zm/index.php/zm/index.php" URL was fixed by the commits mentioned by SmokeyBR in https://github.com/ZoneMinder/zoneminder/issues/2261#issuecomment-431506022.

The 500 error and the problems with the feed info (state, fps, mode, zoom) not being available and force alarm not working were a result of missing PHP semaphore support. @ASerbinski posted a fix in https://github.com/ZoneMinder/zoneminder/issues/2261#issuecomment-433129559. I don't know if @connortechnology has merged it or not (can't see anything relevant in ajax/stream.php) but in my current 1.32.3 setup disabling semaphore support results in no errors, so I assume it has indeed been fixed.

I think this issue can be safely closed.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[multijohn]

Hello, Issue is back with 1.34.26 on Ubuntu 18.04 php7.3! Force alarm and cancel alarms buttons not working!

[multijohn]

Works when AUTH_RELAY is none!

Thank you!

[connortechnology]

Fix will eventually be released in 1.34.27

[thillRobot]

I am having the same problem with a fresh install of ZoneMinder 1.34.26 and Ubuntu Server 18.04. Everything seems to be working except the Force Alarm and Disable Alarms buttons. Can you elaborate on how to apply the fix shown above? I assume it is something simple, but I cannot locate the file watch.js that is modified in the fix.

[thillRobot]

I have re-installed my system for a different purpose. I had the disk logical names backwards from what is typical, and I wanted a new host name for the server. Either way, the Force Alarm and Disable Alarms buttons are working for me again. I assume this means the issue was related to my configuration (or the issue has been fixed by an update).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.