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. Re: Time going backwards due to NTP update causes motion
snapshot too frequently (Suggested patch) (folkert)
2. Re: Time going backwards due to NTP update causes motion
snapshot too frequently (Suggested patch) (Berto Furth)
3. Re: Time going backwards due to NTP update causes motion
snapshot too frequently (Suggested patch) (tosiara)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Sep 2021 16:44:32 +0200
From: folkert <folk...@vanheusden.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Time going backwards due to NTP update
causes motion snapshot too frequently (Suggested patch)
Message-ID: <20210927144432.gg605...@belle.intranet.vanheusden.com>
Content-Type: text/plain; charset=us-ascii
Or: don't use time() but use clock_gettime(CLOCK_TAI). Only if you
want to *display* time, use e.g. time().
On Mon, Sep 27, 2021 at 06:37:10PM +1000, Berto Furth wrote:
> 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
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
Folkert van Heusden
--
Wintips voor de staatsloterij? http://www.slimwinnen.nl/
Meer weten over Bitcoins? http://www.vanheusden.com/bitcoins/
Meer weten over TOR? http://www.vanheusden.com/tor/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
------------------------------
Message: 2
Date: Tue, 28 Sep 2021 18:59:55 +1000
From: "Berto Furth" <bertofu...@sent.com>
To: folkert <folk...@vanheusden.com>, "Motion discussion list"
<motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Time going backwards due to NTP update
causes motion snapshot too frequently (Suggested patch)
Message-ID: <3b92c9e4-2b16-480d-8c27-8425fdef0...@www.fastmail.com>
Content-Type: text/plain
Thanks for replying.
I did look at CLOCK_TAI, but again it's not supported on my very old system!!!
My reading of the documentation surrounding CLOCK_TAI says it's even more
recent than CLOCK_MONOTONIC_RAW and apparently it's only supported on Linux.
Regardless, it's probably a very rare issue and it's probably not worth the
effort fixing in "proper" motion. It's just something that I'll apply for my
Seagate Central and hopefully if anyone else see it they'll come across this
thread.
Thanks again!
Berto.
On Tue, 28 Sep 2021, at 00:44, folkert wrote:
> Or: don't use time() but use clock_gettime(CLOCK_TAI). Only if you
> want to *display* time, use e.g. time().
>
> On Mon, Sep 27, 2021 at 06:37:10PM +1000, Berto Furth wrote:
>> 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
>
>
>
>> _______________________________________________
>> Motion-user mailing list
>> Motion-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/motion-user
>> https://motion-project.github.io/
>>
>> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>
>
>
> Folkert van Heusden
>
> --
> Wintips voor de staatsloterij? http://www.slimwinnen.nl/
> Meer weten over Bitcoins? http://www.vanheusden.com/bitcoins/
> Meer weten over TOR? http://www.vanheusden.com/tor/
> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
>
>
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
------------------------------
Message: 3
Date: Tue, 28 Sep 2021 12:18:00 +0300
From: tosiara <tosi...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Time going backwards due to NTP update
causes motion snapshot too frequently (Suggested patch)
Message-ID:
<cachtdwrxqpi6hsyswssj0faltmxjadzs8fnjc6mdcy4ofzb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
FYI
Registered an issue in Github:
https://github.com/Motion-Project/motion/issues/1414
On Tue, Sep 28, 2021 at 12:01 PM Berto Furth <bertofu...@sent.com> wrote:
> Thanks for replying.
>
> I did look at CLOCK_TAI, but again it's not supported on my very old
> system!!! My reading of the documentation surrounding CLOCK_TAI says it's
> even more recent than CLOCK_MONOTONIC_RAW and apparently it's only
> supported on Linux.
>
> Regardless, it's probably a very rare issue and it's probably not worth
> the effort fixing in "proper" motion. It's just something that I'll apply
> for my Seagate Central and hopefully if anyone else see it they'll come
> across this thread.
>
> Thanks again!
>
> Berto.
>
> On Tue, 28 Sep 2021, at 00:44, folkert wrote:
> > Or: don't use time() but use clock_gettime(CLOCK_TAI). Only if you
> > want to *display* time, use e.g. time().
> >
> > On Mon, Sep 27, 2021 at 06:37:10PM +1000, Berto Furth wrote:
> >> 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
> >
> >
> >
> >> _______________________________________________
> >> Motion-user mailing list
> >> Motion-user@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/motion-user
> >> https://motion-project.github.io/
> >>
> >> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
> >
> >
> >
> > Folkert van Heusden
> >
> > --
> > Wintips voor de staatsloterij? http://www.slimwinnen.nl/
> > Meer weten over Bitcoins? http://www.vanheusden.com/bitcoins/
> > Meer weten over TOR? http://www.vanheusden.com/tor/
> > ----------------------------------------------------------------------
> > Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
> >
> >
> > _______________________________________________
> > Motion-user mailing list
> > Motion-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/motion-user
> > https://motion-project.github.io/
> >
> > Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>
>
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------
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 14
********************************************
