ZMS appears to have timezone issues.

[skidd]

I'm having an odd problem with viewing alarms in ZoneMinder. I'll do my best to provide as much detail as I can. It took a little time, but I think I have managed to find a pattern to why/when this happens.

When clicking an "alarm event" in the web interface, I get a broken image about 9 out of 10 times I try. If I press reload about 6-7 times, it will eventually start to work. Thought not always.
The log messages show the same error every time. That's the oddest part of this error, it usually happens, but I can manage to get it to function when I reload it a bunch.

Code: Select all

2015-10-06 09:50:09.468056	zms	7080	ERR	Can't open /mnt/data/wwwroot/home/htdocs/zm//events/4/15/10/06/14/49/31/00001-capture.jpg: No such file or directory	zm_event.cpp	1254
2015-10-06 09:50:08.133854	zms	7067	ERR	Can't open /mnt/data/wwwroot/home/htdocs/zm//events/4/15/10/06/14/49/31/00001-capture.jpg: No such file or directory	zm_event.cpp	1254
2015-10-06 09:50:07.806374	web_js	6538	ERR	getCmdResponse stream error: socket_sendto( /var/lib/zm/socks/zms-355167s.sock ) failed: No such file or directory - checkStreamForErrors()	?view=event	
2015-10-06 09:50:07.702617	web_php	6538	ERR	socket_sendto( /var/lib/zm/socks/zms-355167s.sock ) failed: No such file or directory	zm/includes/functions.php	2347
2015-10-06 09:50:05.511265	zms	6781	ERR	Can't open /mnt/data/wwwroot/home/htdocs/zm//events/4/15/10/06/14/49/31/00001-capture.jpg: No such file or directory	zm_event.cpp	125

Which is a correct error, that file does not in fact exist. But, here is where I think I found the pattern. The above directory tree suggests it's looking for the event dated
camera 4. 2015-10-06 @ 14:49:31.
But, the event I selected in the webitererface is actually dated
camera 4. 2015-10-06 @ 08:49:31.
exactly 6 hours out of sync.
The timezone of my server is -6 (Central US). Seems like a perfect coincidence to me.
If I look into the events file system, the expected 08:49:31 files DOES exist. Leading me more to think its a TZ issue.

Code: Select all

/mnt/data/wwwroot/home/htdocs/zm/events/5/15/10/06/08/49/31/00001-capture.jpg

My system hardware clock is set to UTC, I have ntp running, and the local timezone is set to "US/Central".

Code: Select all

/etc/localtime -> /usr/share/zoneinfo/US/Central

My php.ini file has it's timezone set to

Code: Select all

date.timezone = "US/Central" 

Viewing live streams of various cameras seems to always work fine the first time. I don't recall ever noticing a broken image on live-streams. Only on historical event viewing.

I've tried both ZM 1.28.1 (official release for my distro) and the latest from git. 1.28.107
I've tried switching nph-zms and normal zms. No change.

Server:
ZoneMinder 1.28.107
Linux castle 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015 x86_64 GNU/Linux
mariadb 10.0.21-3
PHP 5.6.13
Apache 2.4.16-1

Client:
Linux soze 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015 x86_64 GNU/Linux
Chrome(x64) or Firefox(x32) Browsers.

Thanks for any insight or help you can provide.

[knight-of-ni]

"US/Central" is not a valid value for php's date.timezone.

Refer to:
http://php.net/manual/en/timezones.america.php

You probably want "America/Chicago"

[skidd]

So.. so far.. that seems to be working. I say so far, because while I get a proper play-back of events about 19 out of 20 times now. I still get the odd "file not found" but a single refresh seems to fix it now.

Prior to firing up ZM the first time, I followed the instructions, and had set the PHP timezone to "America/Chicago", and I was getting these errors almost all the time.
After I guessed it was a TZ issue, I noticed my PHP TZ was set different to my /etc/localtime. localtime was set to "US/Central". So.. I switched the PHP timezone to also be "US/Central". and that actually made it better, but did not fix the problem. After that, I posted this thread.

So.. it would appear having them BOTH set to the same .. and valid... TZ value seems to have fixed the problem. (fingers crossed)

Thanks

[bbunge]

I was going to question you as to why you messed with timezone in PHP. But I read the Arch WIKI and saw where it told you to set the timezone. I checked my PHP ini file and the timezone settings are commented out and therefore report out as (default).

So, regardless of what your system time zone is set for, what happens when you comment out your timezone settings in php.ini?

bb

[skidd]

Interesting idea... so I tried it. Commented out the TZ setting in my php.ini file.
Same outcome as matching the TZs correctly. It works very well, but still.. sometimes.. tries to load the wrong file.
And is fixed with usually 1 or 2 reloads.

[bbunge]

Thanks for the test!

Possible you have some old events where the time of the database record does not match the file? Not sure why this would matter...

Edit: You may want to check the timezone setting in your database server. MySQL uses an entry of time_zone. My value is set to system.

[skidd]

My @@global.time_zone setting is also set to "SYSTEM".
The fact that making these TZ changes seems to have massively improved the error tells me I'm on the right track. But.. it's still strange that it happens.
At least I pretty much only need to do 1, sometimes 2 refreshes to get the stream to start playing.
I'm contemplating setting my entire system to run on UTC .. just as a short test to see if that fixes it.. but . I don't really want to do that if I can avoid it. My server runs more than just ZoneMinder.

[skidd]

New tidbit of info.
Having my php.ini timezone value commented out.. broke something else.
the web-page interface to ZM showed the time (in the upper left corner of the page using the flat css) 6 hours ahead. It was in UTC.
Resulting in the "hour" column of events being full of zero events. The event were recording correct time (since the zm service is not php) but the php pages were out.
Putting the php.ini timezone back in place fixed.

So.. I'm currently back to both /etc/localtime and my php.ini timezones matching.

[skidd]

Update.. so far.. it seems to be fixed. Though, I don't know what fixed it.
Previously, I'd tried re-compiling and re-installing quite a few times, but the problem remained.
Though, I'd used the old-school method of ./configure to setup the build.
This time, in an effort to get access to ZM Ninja and the necessary API, I went back and built ZM with cmake.
./configure doesn't seem to include the /api stuff in the install.
I didn't touch the database or the zm.conf file, but I rebuilt and re-installed with cmake.
Now.. so far.. everything seems to be fine.

[skidd]

I spoke too soon. It's still doing it. The one where it fixes itself after 1-2 reloads. D'Oh!

[bbunge]

Well, maybe it is time to try Ubuntu?

http://www.zoneminder.com/wiki/index.php/Ubuntu

We even have instructions to upgrade to the latest development version which includes the API:

http://www.zoneminder.com/wiki/index.ph ... _on_Ubuntu

[skidd]

An update to anybody who finds they are having a similar issue.
http://www.zoneminder.com/forums/viewto ... 32&t=23529
In my efforts to fix the issues reported in that thread, my TZ issues are.. almost.. totally gone.
It would appear that it's not a TZ specific issue, but in fact a performance issue. In resolving (almost) the performance issue I am/was fighting, this issue has reduced itself to only once in a while. It does still happen, but a fraction of the times previously.