No matter what - streaming not working...

[warpme]

I'm trying to get streaming working last 2 weeks and no matter what I do - it not works.

Environment:

-ArchLinux, ZM 1.29.0, apache 2.4.23, php7.0.3.
-ZM 1.29.0 is source build (build params - see below)
-apache has non standard html doc root ( it is /var/http)
-ZM install script installs:
PHP files in /var/http/zm/www
zms in /var/http/zm/cgi-bin

Situation:

All ZM functions are working except streaming.
When user asks for i.e. event streaming, apache access log says:

Code: Select all

[05/Oct/2016:15:42:57 +0200] "GET /zm/cgi-bin/zms?source=event&mode=jpeg&event=6&frame=1&scale=100&rate=100&maxfps=5&replay=single&connkey=295934&rand=1475674976 HTTP/1.1" 200 943696

I see HTTP code 200 so looks OK.

apache_eror.log - no any errors to report.

PHP erros log says:

Code: Select all

[05-Oct-2016 15:43:00 Europe/Warsaw] ERR [socket_sendto( /var/zm/zms-295934s.sock ) failed: No such file or directory]

User sees event page - but area where streaming picture should be is blank white.

In ZM console options/path I have ZM_PATH_ZMS set to /zm/cgi-bin/zms

My /etc/zm.conf has following:

Code: Select all

....
ZM_PATH_WEB=/var/http/zm/www
ZM_PATH_CGI=/var/http/zm/cgi-bin
.....

my apache extra/httpd-zm.conf is following:

Code: Select all

Alias /zm "/var/http/zm"
<Directory "/var/http/zm">
    Options -Indexes +MultiViews +FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

ScriptAlias /cgi-bin "/var/http/zm/cgi-bin"
<Directory "/var/http/zm/cgi-bin/">
    AllowOverride All
    Options +ExecCGI +FollowSymLinks
    Require all granted
    php_value short_open_tag 1
</Directory>

ZM build params are following:

Code: Select all

#needed by mythzmserver to work OK
echo "ZM_VERSION=$pkgver" >> zm.conf.in

#needed to stop PHP warnings about already defined ZM_VERSION variable
sed -i 's|define( \"ZM_VERSION|\/\/ define( \"ZM_VERSION|' ./web/includes/config.php.in

#needed as in Archlinux having socket in tempfs type dir causes ZM console is not correctly reflecting ZM status
sed -i 's|/var/run/zm|/var/zm|' ./configure.ac

  libtoolize --force
  aclocal
  autoheader
  automake --force-missing --add-missing
  autoconf

  ./configure --prefix=/usr \
    --sysconfdir=/etc \
    --with-webuser=http  \
    --with-webgroup=http \
    --with-mysql=/usr  \
    --with-ffmpeg=/usr/include \
    --with-webdir=/var/http/zm/www  \
    --with-cgidir=/var/http/zm/cgi-bin \
    --enable-mmap=yes \
    LIBS="-lrt"

  make || return 1

I'm starting to have grey hairs about this streaming issue.
Maybe somebody has any clue....

BTW: I also tried ZM 1.30. Issue is exactly the same....

[SteveGilvarry]

In ZM console options/path I have ZM_PATH_ZMS set to /zm/cgi-bin/zms

Code: Select all

ScriptAlias /cgi-bin "/var/http/zm/cgi-bin"

Not archlinux but same thing in Ubuntu looks like below, so strikes me that path_zms is different to scriptalias, remove the /zm.
http://zoneminder.readthedocs.io/en/sta ... -streaming

[knight-of-ni]

While I'm certainly not going to try to stop you, I do need to ask why are you doing this the hard way? Is it because you want to run mythweb and zoneminder on the same box?

The problem with the path you are going down is that, once you finally get it working, you now own this configuration and will have to go through the same pain after each and every zoneminder and/or distribution upgrade. A better approach would be to install zoneminder into a docker container or vm on the same machine. Then just configure a reverse proxy on the primary Apache server to point to the apache server running in the container or vm. This way, you can follow well documented installation and upgrade procedures rather than try to blaze a new trail all on your own.

But if you want to continue down this path, then the first issue is your PATH_ZMS.
It does not match the ScriptAlias directive. While these values are fairly arbitrary, they do have to match. If I choose a PATH_ZMS to be "pinkponies/zms-nph" then your ScriptAlias directive needs to look like -> ScriptAlias /pinkponies "/var/http/zm/cgi-bin"
This does not come from Zoneminder, but the Apache documentation.

You should also likely be using zms-nph, rather than zms.

So change your PATH_ZMS to be /cgi-bin/zms-nph. That way it matches the corresponding ScriptAlias directive.

Lastly, you need to scan your root http config file for a default ScriptAlias directive, which most distros have. If it also points to /cgi-bin (usually does) then it will conflict with the one you are trying to set up. Comment it out and restart Apache.

UPDATE: Steve Ninja'd me

[knight-of-ni]

Just wanted to make sure you were aware of this page, containing instructions for the archlinux zoneminder package:
https://wiki.archlinux.org/index.php/ZoneMinder

[warpme]

so strikes me that path_zms is different to scriptalias, remove the /zm.

that was it. @knnniggett explained this perfectly for me!
many thx

[warpme]

@knnniggett
I really appreciate You found time and replay to this topic. Level of support You are providing is unusuall (in good sense) and makes ZM an really nice project/product to use!.
Thx for this!

for rest - pls see inline

While I'm certainly not going to try to stop you, I do need to ask why are you doing this the hard way? Is it because you want to run mythweb and zoneminder on the same box?

yes. this is one from main reasons.
I want to have single 24/7 running host doing all things for my house (PVR/TV/music/streaming, telephony, home automation, surveillance, file/print/RAS/etc). It is simply energy BC driven. Just example: reducing total power of server room by 20W saves for new average mobo after 2-2.5y.
second reason it that going with VM/container will be sing of lost war for me. I'm doinf my own distro and I want to develop it exactly as planned - not as forced by workarounds for things I'm not able to resolve.

The problem with the path you are going down is that, once you finally get it working, you now own this configuration and will have to go through the same pain after each and every zoneminder and/or distribution upgrade.

Right. I'm fully aware of this. This is price for me to having 100% control for server I'm building/maintaining. My experience with of-the-shelf distros is that sometimes fixing subtle post-upgrade issues/instabilities takes more effort than building from source minimally modified upstream sources in 100% controlled environment. I see this indirectly when comparing number/nature of issues users have with heavy modified GNU/Linux milestone distros vs. distros using minimally-as-possible touched upstreams. This is just my experience and probably there are ppl having opposite one...

A better approach would be to install zoneminder into a docker container or vm on the same machine. Then just configure a reverse proxy on the primary Apache server to point to the apache server running in the container or vm. This way, you can follow well documented installation and upgrade procedures rather than try to blaze a new trail all on your own.

Sure. For max effectiveness this is nice approach.

But if you want to continue down this path, then the first issue is your PATH_ZMS.
It does not match the ScriptAlias directive. While these values are fairly arbitrary, they do have to match. If I choose a PATH_ZMS to be "pinkponies/zms-nph" then your ScriptAlias directive needs to look like -> ScriptAlias /pinkponies "/var/http/zm/cgi-bin"
This does not come from Zoneminder, but the Apache documentation.

ahh - this is said simple enough - but believe me: looking on tons of WiKi, mails about "zms.sock failed: No such file or directory" I never found this information.
Probable another factor is 2 week ago decision to move from lighttpd to apache so apache is still learning curve for me...
Any way - thx for clear consistent and simple explanation.
It will be really good to add this to ZM install guide - for all those users which are not install software by blindly following steep-by-steep cookbook style receipts - but want to understand what they are doing.

You should also likely be using zms-nph, rather than zms.

Interesting is that my 1.29.0 building process makes zms-nph as symlink to zms. In such case what is difference between zms and zms-nph?

So change your PATH_ZMS to be /cgi-bin/zms-nph. That way it matches the corresponding ScriptAlias directive.

that was it. now it works!
having 1.29.0 fully working now I can try 1.30.0...

once again: many thanx for Your's outstanding support!

[knight-of-ni]

When we state that building from-source is strongly discouraged, what we mean is that it is not worth the time of the few volunteers of this project to support it. The build steps are entirely distro-specific, and there are far too many pitfalls. It would be a full time job for someone to try to document the steps for each and every distro and then maintain it. Feel like volunteering? The wiki is writeable by all. You can develop your own guide for Archlinux if you are willing. If there already is one, then feel free to update it.

The only method we support is building zoneminder into a package. Anyone who has been with this project for 5 years or more will understand this. Back then, zoneminder packages did not exist, and nearly all forum posts were requests for help building zoneminder. I shudder when I think back to those times. Thankfully those times are behind us.

While I can't help you specifically with building zoneminder into a package on Archlinux, I'm sure there is either existing documentation or someone who can help you over in the Archlinux forum. The package building process would likely require taking apart the official zoneminder package for Archlinux, replacing the zonemnider tarball with the one you want (master branch for example), and then starting the package building process over again. This will produce a package, just like the one you would get from the Archlinux repo, but it would also include whatever changes you desired. Doing it this way avoids many of the pitfalls when building from-source.

Speaking of pitfalls when building from-source, there is another you need to be aware of if/when you chose to upgrade to 1.30. Perl's Make::Maker module no longer supports removal of Perl modules via "make uninstall". Worse off, a "make uninstall" will silently fail, giving you the impression the old modules have been removed when in fact they have not. This effectively breaks zoneminder's legacy uninstall process with no possibility of a direct fix. Instead you have to manually search your filesystem and delete them all by hand. While you are at it, you should search for any zoneminder files left on your filesystem, such as config files and init scripts before you attempt to upgrade to the next version of zoneminder. Failure to do so, will cause the next version of zoneminder to fail spectacularly in very weird ways. The good news is that this makes this kind of problem easy to spot.


Moving on to your other questions, it is by design that zms-nph is a symlink to zms. Thanks to this line of code, zms knows how it was called and will produce different output accordingly: https://github.com/ZoneMinder/ZoneMinde ... ms.cpp#L85

The origins of how to set your ScriptAlias come straight from the Apache documentation. We don't ever plan to include in depth discussion of this in our documentation because it is already documented over on the Apache site. If you build from source, this is just one of the things you've got to read about if you aren't already familiar with.

Lastly, we don't have a large representation of Archilinux in our forums. We could always use people willing to hang out in the forums and our irc channel and participate in the development any way they can. Even writing documentation or just answering questions helps us because that is more time we get to write code if that is not your thing.