recording stops - entry - (r)

[biadco]

I am using ZM for a vehicle DVR.
Occasionally, I see an event entry, appended w/ an (r) extension.
These are recordings that abruptly stopped.
The params are:
Function:record
continuous: 600 sec
Any ideas what this is about?
A box set up in the shop does not exhibit this behavior.
TIA FXS, G.M., Beechhurst Inc.

[zoneminder]

This indicates an event that has been recovered and closed. For some reason the event has not been closed properly when it was originally captured. This can happen for a variety of reasons if a machine gets restarted or a process crashes etc however it is not 'normal' behaviour and is worth checking out the machine logs to see what might have happened.

Phil

[jameswilson]

without knowing more details id look at your power supply config. When starting the vehicle the motor pulls tonnes of current 100ish amps sometimes and can cause the voltage to fluctuate madly and create minor 'brownouts'. I had this issue with 'intelligent' amps when i was younger and modified cars. You could do with a split charge battery and diode config. Basically run another battery for your pc, fit a relay so when the ignition is off its disconnected from the main battery (to stop it dischrging) and have a bigish diode between the batteries to stop current being pulled from your battery when the car pulls serious current. There are lots of nasty noise (electrical wise) things in cars that need filtering. Never having tried putting a pc in a car (yet id love to in my next car) i havnt had to over come them. To test this theory you will need access to a basic say 20 megs scope or just try running the pc from its own source to prove its not the car in anyway

James

[biadco]

I will check /var/log/messages. I did not realize that this might be hardware related.
As for the power, that is not an issue as we are using a power supply designed for just this application.
Noise could definately be an issue - the test mule is a 1946 Ford pickup - we wanted harsh conditions for product evaluation.
Are there any other logs I should be checking?

[jameswilson]

how often is this boxing doing this, if its often id remove it, connect it to a proven supply and run it long enough to prove the hardware. If you check the messages log you should be able to see when its starting up, and then you will have an idea what your looking for, you could also check the 'uptime' and see how long its been running to check that corresponds with wgen you booted it up.

[zoneminder]

It may not be hardware as such. It just indicates that the event was not closed properly. This could be for a variety of reasons but does not usually indicate normal operation.

Phil

[biadco]

Frequency: 3 events out of ~40. Events are generally 12 minutes. (10 +2)
I am aware of one item that we have to fix.
Presently, when the ignition is switched off, the mobo is commanded to do an orderly shutdown. It has 2 minutes to do this before power is removed.
I have seen the setup in the shop take longer than 2 minutes to do a shutdown, however, since ZM is the first thing stopped, I do not see any -r flags in the events log.
This requires a fix as the next reboot takes a bit longer as it reviews the condition of the HD.
I plan to increase this power off time to 3 or 4 minutes.
I also will swap the boxes, and run the truck box in the shop.
Thanks for the suggestions.
Regards, FXS

[jameswilson]

do you need to shut it down after 2 mins could it not just be told to shutdown and always keep power to it, as then it could take as long as it likes. I would have thought 2 mins was enough time to shut down most things what else is running on it

[biadco]

Thanks to Ross for a tip:
checked /vag/log/zm.
This is what I found: in zmdc.log:
zmwatch.pl died signal 14
zmfilter.pl died signal 14.
Ran the box in the shop for ~24 hours - no errors noted.
What is signal 14?
James: you have to remove power because the PS's available draw about 120 mA, which means a dead battery after a week.
And just how we solved that problem I can't disclose.