Daylight Savings. How did everyone's cameras do?

wittaj said:
When you export, since you are having BI add the time, you are re-encoding the video, and that is inefficient and takes more storage than not re-encoding and depending on the size of the export, could take a long time.

The biggest reason not to use the overlay though is that the attorney and law enforcement members here have said that having BI add the overlay constitutes a manipulation/modification/altering of the video after the fact and in a lawsuit, a good defense lawyer would claim the video has been altered to try to get it dismissed in court.

The reason being you could overlay any time you want on it after the fact.

Sure a camera could have the wrong date and time too, but that cannot be altered after the fact.

It would suck to have great video of a crime and have it tossed on a technicality.
Click to expand...

I guess I know why now that when I turned off all the camera overlay turned off made my cpu usage go up.
 
Yes, this is an old thread.

I gave up on the Astral package for OpenWRT and compiled Sunwait for my hardware as there was no precompiled binary.

Going to run it on two cameras for the next couple days. If that works, we're good to go. Had some small problems with the syntax of the script Sunwait will run but that's on me and my dyslexia.

Compiling Sunwait for my hardware was a relatively simple procedure if the directions are followed. Kind of ironic I needed to download 150MB of OpenWRT source code to compile an 8kb package but it is what it is.
 
No issues this year. All 32 cameras switched without a glitch.

Tip: In UI3 when viewing a single camera full screen, hit the ". >" key on the keyboard to move on to the next camera. Easy to read the time
 
And automated cat feeders. :rolleyes:
 
Mine made it through all good this year too. I usually have one that I've done something too and forgot about. Microwave and one car clock are about all that I have left that don't auto-switch now.
 
Everything updated just fine as there are six local SNTP servers running.

But, what I always forget to (remember) is Julie U.S. calling out the time has been tampered with on a specific network appliance! :facepalm:

Hearing a female voice in the dead of night isn’t really normal at 2:00 AM!

As others noted it’s the stove, microwave, thermostat, and other legacy appliances that take some time walking around changing.

Remember, use this time to inspect, test, and change out the smoke / CO / radon detectors battery.

Along with pressing the test button on all AFCI / GFCI Breakers / Outlets.

It’s going to save you or someone down the road! :headbang:
 
Last edited:
  • Like
Reactions: CanCuba and TonyR
prsmith777 said:
My big PTZ SD8C845FG-HNF did the change fine, but has locked up and won't accept PTZ commands through the web interface. This happened the last DST also, so I am guessing it is a bug. I had to default the camera to get it working again last time. Sigh
Click to expand...

(Yes, I realize I'm replying to an old post here)
I have not had PTZ control problem(s) on mine after any DST time changes (including today).

Just curious- are you still having any SD8C845FG-HNF PTZ control issues right after DST changes?
The firmware I have is system version "V2.820.0000019.0.R, Build Date: 2022-08-05" and PTZ version "V2.401.0000001.40.RHNCC_220803_42438), and FWIW my PTZ's positioning stability has been great..

And yes, all my cams made the DST change properly today. :)
 
You must log in or register to reply here.
Top Bottom