Posible bug?

Normando · Post by **Normando** » Sun Jan 25, 2009 4:06 pm

I have 8 cameras recording during the day, from 03:00 to 16:00. Then from 16:00 to 03:00 they switch to modect.

When I look at the timeline I see they are events from the year 1969 at some monitors.

I have two stages. One recording named "day" and one modect named "night". At the 16:00 a cron task switch to night, and at the 03:00 switch to day.

I am doing something wrong? Or maybe I must switch to stop state in between them?

May be a switching "glitch" is the cause

Post by **cordel** » Mon Jan 26, 2009 1:00 am

Can you check and verify if these values are what is being stored in the database?
What timezone do you have configured?
What is your system clock set to TZ wise?
Have you configured TZ in PHP at all?

Normando · Post by **Normando** » Mon Jan 26, 2009 3:17 am

Well, I have deleted those "old" events. When this happens again I will see the db and settings.

Thanks cordel.

Normando · Post by **Normando** » Mon Jan 26, 2009 9:18 am

Well, now occur again!!

yes, the event store in the database:

Code: Select all

Id 	MonitorId 	Name 		Cause 	StartTime 		EndTime 			Width 	Height 	Length 	Frames 	AlarmFrames 	TotScore 	AvgScore 	MaxScore 	Archived 	Videoed 	Uploaded 	Emailed 	Messaged 	Executed 	LearnState 	Notes
10183 	6 		Evento-10183 	Signal 	1969-12-31 21:00:00 	1969-12-31 21:00:00 	384 	288 	0.00 	41 	1 		100 		100 		100 		0 	0 	0 		0 	0 		0 	  			Signal: Lost

No, I have not configures TZ into php.ini
The timezone for my server is /America/Argentina/Cordoba
The clock of my server is automatically updated via internet syncing

I think this happens when switch from night state to day state. Only happens in one monitor, and the comment say: signal, but the monitor never loose the signal.

Can I made some tests?
I have an innodb database.

Post by **cordel** » Tue Jan 27, 2009 4:51 am

Linking this thread to your other thread as I think they might be related.
I sort of answered there.

Normando · Post by **Normando** » Fri Feb 06, 2009 8:57 pm

I think this issue is not related to the optimizing query post, becaue happens again, now with MyISAM engine.
The problem occur only when the states switched from day to night or viceversa, and between them the camera signals are lost and reaquired.

Post by **cordel** » Fri Feb 06, 2009 11:28 pm

Okay so this sounds like maybe the database is not being closed between run state switchs maybe. Do you have zmf enabled and if you do, what happens if you disable it?

I just came across a problem with zmf last week where it's crashing on some newer distros and leaving shared memory segments. I haven't been able to narrow down the cause yet due to lack of information so I have nothing to compare to find out if it's gcc, glibc, libstdc[++], autoconf, mysql, etc, etc...
Anything that zma and zmf links to is rather suspect as this is a new problem specially if they are related.

Normando · Post by **Normando** » Sat Feb 07, 2009 5:27 am

Right Cordel. This is the next step I was issued. I have disabled zmf and look in the syslog and I see there are several crashes from zmf. So I was disabled and now look everything ok. I will back with results the next week when the server are running in fully record mode and switch between states.

Thanks Cordel

Post by **cordel** » Sat Feb 07, 2009 6:54 am

Yeah please let me know. If you have no crashes, I just need to know what distro so I can compare to the rest, or load it myself and debug assuming I can find the time.
It is a new issue though so something has certainly changed with something we link to

dvarapala · Post by **dvarapala** » Mon Feb 21, 2011 6:07 pm

I realize this is an ancient thread, but I ran into a similar problem with one of my IP cameras and I wanted to add some additional data which might benefit future explorers. Every once in a while ZM would record a small burst of events with this bogus timestamp (1969/12/31 16:00) and ridiculous values for the duration (e.g 9 million seconds for an 18-frame event) - no doubt the duration calculation is subtracting the bogus 1969 date from the current date/time, or vice-versa, to get these huge numbers.

Anyway, it turns out that this particular camera, an Arecont Vision AV1310DN, has a bug (or is it a "feature?") where it sometimes drops its frame rate WAAAAAAY down to like 1 frame every 5 seconds or even less. This trips the frame rate watchdog, which assumes that the capture and analysis daemons for that camera have locked up and restarts them. There seems to be a pretty strong correlation between the restarting of zmc/zma and these glitched events.

As a workaround, I have increased the WATCH_MAX_DELAY value to 20 seconds. The real solution will be to figure out why this camera's frame rate drops so low and to stop it from doing that.

Anyway, hope this info helps somebody.