web gui constantly cycles to permission denied

[bbunge]

I was able to reproduce this on a Ubuntu 18.04-1 server install, LAMP with Mariadb, Zoneminder 1.32.0 from the zoneminder-master PPA.

I suspect it is when my Win 10 PC went to sleep (sleep set for 30 minutes) when the PC woke up Zoneminder had tried to connect (Firefox) and the web connection erred out. The Permission Denied screen showed when I tried to refresh the screen. Zoneminder kept working, though.

Had the console screen "time out" and show a connection error screen but no permission denied screen.

Trying with Chrome.

[knight-of-ni]

I wish I could duplicate this problem.

This morning I grabbed the latest and then installed the resulting package with gdebi:

Code: Select all

~/git/zoneminder/utils/do_debian_package.sh --snapshot=NOW --branch=master --type=local

I have this running on an OdroidHC1 with Armbian (a.k.a. Ubuntu 18.04).

I've had simultaneous chromium & firefox clients open, watching the same camera, for a couple hours now and I have yet to see the problem materialize.

[knight-of-ni]

Okay guys, new information.

Since bbunge mentioned a Windows PC, on a hunch I just fired up a windows 10 vm.
In a matter of minutes I got the infamous no permission error in both IE and Chrome.

Question for everyone who has posted in this thread:
On what operating system are you seeing this error?

[jedix]

The server is an amd64 bionic server with raid 5 storage.

The clients that I use and have I seen the issue are:
1. Debian firefox
2. Debian chrome
3. Android firefox

I was wondering if EDT vs EST may cause this issue somehow?

edit: I do see it on android more often. Could it be with the application/phone going to sleep mode?

[bbunge]

The server is an amd64 bionic server with raid 5 storage.

The clients that I use and have I seen the issue are:
1. Debian firefox
2. Debian chrome
3. Android firefox

I was wondering if EDT vs EST may cause this issue somehow?

edit: I do see it on android more often. Could it be with the application/phone going to sleep mode?

Might be best to let us know the web browser version. Firefox and Chrome both have recently been updated. Entirely possible the upgrade caused the issue. When I get a chance I'll put and older Firefox version on a Windows test machine to see what happens.

[iconnor]

I believe I understand the problem and have pushed a fix to master.

The contents of the navbar get updated in a background ajax call. If you are watching a live view and not really doing any page loads the auth token times out after about on hour. This causes the ajax call to fail with an auth timeout (it probably shouldn't do that). This causes zoneminder to refresh the page. The problem is that we were doing location=currentView and so the url was view=watch without the monitor specification in the url. It should be view=watch&mid=1

So now we will do location.reload() and I think that will fix the problem for now. I'll have to look into improving the error message and seeing why the navbar refresh is counting on the auth token...

[knight-of-ni]

All,
Please make the following change to your system and then see if the problem re-surfaces:
https://github.com/ZoneMinder/zoneminde ... 9e92e6e1a0\


FYI, we are leaning towards releasing 1.32.1 tomorrow, Tuesday, with or without a fix to this problem. It would be very helpful if everyone in this thread would test this and report back their results today if possible. Thank you.

[knight-of-ni]

Oh, I see I got Ninja'ed by iconnor. My bad.

[rockedge]

my setup is slightly different..I am experiencing this on 2 versions of Puppy Linux ..Tahr and Bionic....version 1.30.4 runs rock solid on both. And an attempt with XenialDog and BionicDog (both minimal Ubuntu) and all with a GUI ---jwm is the desktop in all of them.

These are some specs from the Bionic in question.....

Code: Select all

Distro: UPupBB 18.05
Window Manager: JWM v2.3.7
Desktop Start: xwin jwm

Development:
 Bash: 4.4.19
 Geany: 1.29
 Gtkdialog: 0.8.4
 Perl: 5.26.1
 Python: 2.7.15rc1
 --
 busybox: 1.28.3
 dhcpcd: 6.7.1
 GCC: 7.3.0
 Glibc: 2.27
 OpenSSL: 1.1.0g  2 Nov 2017, built on: reproducible build, date unspecified
 wpa_supplicant: 2.6

zmNinja attempting to use the 1.32 server in these cases also loses the stream after a few seconds

[knight-of-ni]

@rockedge Can you try the following change and let us know whether this fixes the issue?

https://github.com/ZoneMinder/zoneminde ... 9e92e6e1a0

[rockedge]

I put in the change and it seems to have worked in preventing the permission denied page from loading. I still am seeing after 2-10 seconds of a smooth stream view of a monitor the page begins to go into this full page refresh cycle. The monitor view disappears and then restarts. It is during that phase of the refresh cycle, the url would end up missing a piece. Now that seems to be fixed.

[knight-of-ni]

Okay so progress at least.

Take a look at the previous line:
https://github.com/ZoneMinder/zoneminde ... in.js#L199

What this tells us is the page only refreshes if there is some kind of error, and the console.log command logs the error message to the web browser debug console.

You should see a corresponding error message appear every 2-10 seconds in your browser's debug console. The format of that message will be "Request Failed: {string of text describing the error}".

We need to see what that string of text is. It should be easy to spot if your browser is refreshing that often.

[rockedge]

I started with a working version of ZM 1.30.4 on Puppy Linux Tahr 6.0.5 32 bit and upgraded to version ZM 1.32.1 from the iconner PPA
zoneminder-master

I discovered the refresh cycling and the stream view disappearing problem was present on this system as well. I have a lot of errors like this ->

Code: Select all

Shared data size conflict in shared_data for monitor Monitor-1, expected 328, got 316.

or similar. So I just for a test applied this fix http://lachlanmiskin.com/blog/2012/06/2 ... r-monitor/

so in /usr/share/perl5/ZoneMinder/Memory.pm on line 139 I commented the line out and added a line

Code: Select all

# New method for determining the bitness
#our $arch = 32 + 32*( qx(uname -m) =~ /64/ );
our $arch = 32

and now the stream views of monitors seems to work without the refresh issue and no permission denied screen (from the fix earlier) and so far smooth live stream views that are not being interrupted by constant refreshing...now the console page is also refreshing at a much more normal rate.

[gsaindon]

Installing 1.32.1~20181002153744-xenial solved the problem on my side.