Open beojan opened 4 years ago
I've no idea how that could happen. There's only 1 Timer instance and it only triggers every 1000ms.
If anything, I'd expect the overhead of the timer would make it take longer (eg: 2h00m30s instead of a clean 2h).
Same issue here, timer for 30 seconds ends in 15 seconds, 1 minute in 30 seconds and so on.
Event Calendar v66 KDE Neon 5.18.5 QT 5.14.2
Does it happen all the time? Even after a reboot?
No, it doesn't happen all the time. Sometimes works fine and other times it is too fast (0.5 seconds instead of 1 second). I can reboot and it works fine after reboot or I reboot and it doesn't work fine, it is a bit erratic in my case. Really weird.
That's exactly what I see too.
The only thing I can think of besides a QML bug is:
Timer {}
is in the popup, it might not be destroyed properly... for god knows what reasonTimer {}
instance.timerView.timerSeconds -= 1
If you pause the timer, does it still count down? Does it still go at double speed when you unpause it?
I could move the Timer {}
to the widget's main.qml
if this is the case. As the main Item/object is never unloaded. I ran into a similar issue when I had the event notifcation code inside the popup.
It goes at double speed from the moment I start the timer, so the popup is never closed. Of course when I go to test it, it works, making it pretty hard to debug.
I should add, I have eventcalendar in a Latte Dock. @sahsanu, what about you?
If you pause the timer, does it still count down?
No, it pauses correctly.
Does it still go at double speed when you unpause it?
Yes, if it started double speed no matters whether I pause/unpause, it continues at double speed.
I should add, I have eventcalendar in a Latte Dock. @sahsanu, what about you?
I've latte-dock installed but Event Calendar is on a normal panel, not a latte-dock panel.
It happens to me too. Here's a video of it: https://streamable.com/49bpuw
Manjaro Linux, Plasma 5.18 (and several versions prior))
What's even weirder: sometimes it works fine. Occasionally I'd use the timer and it's too fast, then I'd use it a few hours later (without restarting anything) and it would work fine.
I'm thinking it might be related to the display refresh rate (or rather, VSync). I have a 144Hz monitor, which is ~2.5x more then 60Hz, and the calendar timer runs ~2.5x faster than it should. In addition there have been issues like that in the past. 1 2
But it's not as easy as just going back to 60Hz. That doesn't fix it- at least not immediately. So I might be on the wrong track. But even just fiddling around a bit right now as I collected information, somehow, the calendar timer once again started working properly.
So apparently this was a bug in Qt 5.4.x. Someone also mentioned on StackOverflow that it's tied to the refresh rate. I guess I will go with (timeStarted + duration) - timeNow = timeLeft
rather than using a QML Timer tick every second...
... Or I could use the time datasource... like the clock uses... I've been an idiot for not using it all this time. I got caught up in trying to figure out what was wrong with QML Timers.
Good to hear. I can help if you need someone to test a patch. I can consistently reproduce the behavior, unfortunately.
It should work now. It still uses QML Timer, and will likely redraw multiple times, but it now uses this logic:
def start():
timeLeft = duration
unpause()
def unpause():
finished = now + timeLeft
def tick():
timeLeft = finished - now
I still need to figure out a "timestamp that isn't affected by timezones" like how many seconds the plasmashell process has been running. Right now I think Daylight Savings Time or physically moving over timezones might break my timer logic. Perhaps I can force the QML Date to use UTC timezone instead of the default local timezone new Date()
probably uses.
(Ignore my last comment if you saw it. I did a ./reinstall but it work; so my previous comment was still about the buggy code.)
I tested it and it does work accurately now.
There's also a KDE Bug report that some of you might be able to reproduce.
Can reproduce the KDE bug with 144+75 Hz displays / 144+60 Hz. They're on the right track, the workaround mentioned there seems to also work.
The timer is running too fast, showing a second elapsed after approximately 0.5 s.