Send Motion-user mailing list submissions to
motion-user@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
motion-user-requ...@lists.sourceforge.net
You can reach the person managing the list at
motion-user-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Time going backwards due to NTP update causes motion snapshot
too frequently (Suggested patch) (Berto Furth)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Sep 2021 18:37:10 +1000
From: "Berto Furth" <bertofu...@sent.com>
To: motion-user@lists.sourceforge.net
Subject: [Motion-user] Time going backwards due to NTP update causes
motion snapshot too frequently (Suggested patch)
Message-ID: <c0fc1805-e7d1-47e8-818e-2eba1d886...@www.fastmail.com>
Content-Type: text/plain; charset="us-ascii"
Hi motion-users,
I was wondering if anyone else has seen an issue where the snapshot occurs too
frequently because the system clock is being set backwards by periodic NTP
updates? I suspect the issue applies to time lapse videos as well.
I'm going to post my experience here for the benefit of anyone else who comes
across this rare issue.
I'm running motion 4.3.2 on a very old arm 32 platform called the Seagate
Central. I have "snapshot_interval 3600" configured to take a snapshot photo
once an hour.
This platform keeps time very poorly. Every 30 minutes the NTP update service
runs and the system clock gets set backwards abruptly by up to about 10 seconds!
What this means is, the "snapshot_interval" feature decides it needs to take a
snapshot because it discovers that the current frame's timestamp
(cnt->time_current_frame) is less than the timestamp of the last frame
processed (cnt->time_last_frame). (See mlp_snapshot() )
I have a very simple patch that *seems* to fix the problem. It simply makes
sure that when cnt->currenttime is gathered in mlp_prepare() that it hasn't
gone backwards. The problem is that it may potentially stop video / image
capture for up to a second because if the allotted number of "shots" have
already been taken in the second when the time changes, then the system will
have to wait for the next second to tick over before is starts taking shots
again.
This issue could be completely fixed if motion changed to using something like
clock_gettime(CLOCK_MONOTONIC_RAW, ...) to find the current time.
CLOCK_MONOTONIC_RAW counts the time the system has been up irrespective of NTP
updates or manual system time adjustments. The thing with CLOCK_MONOTONIC_RAW
is that it's not always supported....at least on my very old system it isn't!!
It would also make the code more complicated because you'd have to keep track
of one time stamp for snapshots and another for labelling images with a human
readable timestamp.
I hope this saves someone else the time it took me to troubleshoot this weird
issue!
All the best!
Berto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fix-motion-NTP-update-snapshot.patch
Type: application/octet-stream
Size: 599 bytes
Desc: not available
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
Motion-user mailing list
Motion-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/motion-user
------------------------------
End of Motion-user Digest, Vol 183, Issue 13
********************************************
