Bug 299388 - [Patch] Strange behavior in Marble Clock
Summary: [Patch] Strange behavior in Marble Clock
Status: CONFIRMED
Alias: None
Product: marble
Classification: Applications
Component: general (show other bugs)
Version: 1.5 (KDE 4.10)
Platform: Microsoft Windows All
: NOR normal
Target Milestone: some future version
Assignee: marble-bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-04 17:13 UTC by marbledeveloper
Modified: 2021-03-09 22:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description marbledeveloper 2012-05-04 17:13:52 UTC
I have set the speed and the update interval for Marble Clock like this:

    ui->widget->model()->clock()->setSpeed(40);
    ui->widget->model()->clock()->setUpdateInterval(20);

Marble clock advances 40s instead of 20s in each update.

If my code is:

    ui->widget->model()->clock()->setSpeed(10);
    ui->widget->model()->clock()->setUpdateInterval(20);

Marble clock advances at 10s instead of 20 in each update.

Reproducible: Always
Comment 1 Dennis Nienhüser 2012-05-04 20:57:50 UTC
For the 40/20 combination, the behavior is caused by an (undocumented) restriction that the speed cannot be larger than the update interval: Marble will not issue the timeChanged() signal more than once a second. So while one would expect updates at 20 seconds / 40 = 500 ms, instead each 1000 ms an update is issued.

For the 10/20 combination, you're running into another issue: The time between updates should be 20 seconds / 10 = 2 seconds. Marble calculates that timeout sometimes correct, sometimes wrong as 0, where another fallback chimes in and sets it to one second. So you get updates sometimes after 2 seconds (advancing correctly 20 seconds) but often early after 1 second (advancing only 10 seconds).

Note that in both cases the time reported is correct. It's just the announcement of the timeChanged() signal that is emitted at the wrong time.

Here's a log of the 10/20 combination and current master showing the described behavior:

System clock "Fri May 4 20:00:33 2012" , marble internal  "Fri May 4 20:00:59 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:34 2012" , marble internal  "Fri May 4 20:01:09 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:35 2012" , marble internal  "Fri May 4 20:01:20 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:36 2012" , marble internal  "Fri May 4 20:01:30 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:37 2012" , marble internal  "Fri May 4 20:01:40 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:38 2012" , marble internal  "Fri May 4 20:01:50 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:39 2012" , marble internal  "Fri May 4 20:02:00 2012" , MarbleClock: will sleep for  1999 
System clock "Fri May 4 20:00:41 2012" , marble internal  "Fri May 4 20:02:20 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:42 2012" , marble internal  "Fri May 4 20:02:30 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:43 2012" , marble internal  "Fri May 4 20:02:40 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:44 2012" , marble internal  "Fri May 4 20:02:50 2012" , MarbleClock: will sleep for  1000 
System clock "Fri May 4 20:00:45 2012" , marble internal  "Fri May 4 20:03:00 2012" , MarbleClock: will sleep for  1998 
System clock "Fri May 4 20:00:47 2012" , marble internal  "Fri May 4 20:03:20 2012" , MarbleClock: will sleep for  1000

Note how it fails to sleep for the correct timeout (~2000) for all but two times.
The patch at https://git.reviewboard.kde.org/r/104861/ fixes this.
Comment 2 Justin Zobel 2021-03-09 22:51:44 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.