After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 583554 - Slow down or lock if date time is changed to the past
Slow down or lock if date time is changed to the past
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.x
Other Linux
: Normal critical
: 0.10.24
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-22 13:12 UTC by ivan zoli
Modified: 2009-05-25 14:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The output from configure (93.44 KB, text/plain)
2009-05-25 11:21 UTC, ivan zoli
Details

Description ivan zoli 2009-05-22 13:12:39 UTC
I found that setting the time in the past produces a slowdown or a lock in the pipeline. I work on an embedded system that can modify the system time using GPS so the moment and the version of the thime change is unpredictable. The trouble persist even on PC,

for example

gst-launch videotestsrc ! sdlvideosink

then set the time back by 10 seconds (for example). The pipeline slow down for 10 seconds, then come back to normal operation. Off course if the set is back by a couple of hour, the user must wait a couple of hour... I try to kill the pipeline (setting the state to NULL, wait untill the state change to NULL the I use gst_object_unref(pipeline), but building again the same pipeline the ptroblem persist. I can't kill my application, bui if I do it the new pipeline is working great.

I may try to investigate the problem. I Found any solution I will submit it to you.

Thank you,

Ivan Zoli
Comment 1 Wim Taymans 2009-05-23 12:52:38 UTC
This problem should be fixed in versions 0.10.23 and higher where we use monotonic clocks (whan available) and use poll timeouts for the synchronisation.

Please retest and reopen if latest versions don't solve the problem.
Comment 2 ivan zoli 2009-05-25 11:21:29 UTC
Created attachment 135309 [details]
The output from configure
Comment 3 ivan zoli 2009-05-25 11:29:49 UTC
I've tested with 0.10.23 and I have the same problem.
I've attached the log out from my configure; In lines 158 and 159 appears:

checking for posix timers... yes
checking for monotonic clock... yes

So I think anything is good and I can use the monotonic clock source.
I've attached the log out from configure in order to help you to diagnose if I miss something else. Sorry for it in this case.

I can made any kind of test you need.

Thank you, 
Best Regards,

Ivan Zoli
Comment 4 Wim Taymans 2009-05-25 14:25:53 UTC
Oops, we did not enable the monotonic clock when we could. As a workaround, you can manually enable the monotonic clock by changing the property on the clock.

commit cabc9cbbef2fc7df5904c40ef68b8d11cba8e494
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Mon May 25 16:21:55 2009 +0200

    clock: enable monotonic clock when we can
    
    Enable the monotonic clock by default when we can.
    Fixes #583554