Timer Problem

[ccs]

Quite a few ntp changes 24 days ago...

https://github.com/OpenViX/enigma2/c...branch=Release

I don't think they're in 6.1.004

[Joe_90]

Is this happening at boot time? (Then being corrected by NTP/transponder shortly after, but not before, recording timers are first checked).
If so, perhaps the hardware clock is being written/read incorrectly.

If you recall, I had huge issues on my mutant hd51 several years ago (2018?) after the "fake" hwclock changes were brought in. That box uses wifi and had all sorts of ntp issues with the clock going backwards (if ntpdate sync didn't happen at boot time) or forwards (if ntpdate ran twice at boot time). My use case on that box (and on the ax61 which replaced it), was a daily boot from deep standby at 6pm to run ABM and CrossEPG, followed by a shutdown 20 minutes later. My "solution" on both boxes was to disable the fake-hwclock script and allow the box to boot up to 1/1/1970 date which was the default before fake-hwclock. In that circumstance, timer settings were disabled until a proper clock sync happened. I'm not suggesting to re-visit fake-hwclock, but it doesn't work for me on my wifi machines. It's ok on my GB Quad+ which is hard-wired to the network. All my boxes use ntp for time sync, which is not the default.

[Joe_90]

Quite a few ntp changes 24 days ago...

https://github.com/OpenViX/enigma2/c...branch=Release

I don't think they're in 6.1.004

Yep, I noticed those and I am not sure if they are in the Release images yet. I think the version of ntpdate has been updated as I can see my ntpdate script failing (on the test dev images) to step the time correctly when run initially at boot time. I've had to use the "-b" option to force the step from 1/1/70 to current time. The normal ntpdate slew is working correctly, though.

[birdman]

If you recall, I had huge issues on my mutant hd51 several years ago (2018?) after the "fake" hwclock changes were brought in.

But the time here is out by > 3 days ahead. The fake hwclock sends it backwards (to the last shutdown time).

[Joe_90]

In my situation, ntpdate was running twice at startup and the system was calculating the offset from when it was last shut down (let's say it was 24 hours) and was applying it twice to the fake-hwclock time. So, instead of stepping the clock 24 hours, it stepped it 48 hours. I haven't had that particular issue in a long time, so I'm not saying it happened in this particular instance, particularly as the OP is using transponder time. But, the timer was set on 28th April according to the screenshot, so his clock was in the future at some point.

[Spoof]

Just to update:

My box is set to "transponder time" (default).
I have gone back to 6.0.006 and the same timers (restored from settings) work perfectly.

[Spoof]

This problem persists in 6.2.102

In the timer log, I get this entry:
Mon 30 May 2022 14:45 - record time chnged, start prepare is now Tue May 31... < CORRECT
Wed 1 Jun 2022 05:32 - record time chnged, start prepare is now : Wed Jun 1..... < ROGUE

The box was booted at 08:15, May 31, if that helps, so not sure where the 05:32 comes form.

This seems to happen overnight, booting from a deep standby.

[Joe_90]

We've been testing and have discovered an issue with NTP time during startup which can cause the clock to jump forward temporarily even if you have "time by transponder" set. The software has been changed and tested and I would expect that there will be a Release version available shortly.

[Huevos]

Wthere will be a Release version available shortly.

Yesterday.

[Joe_90]

This problem persists in 6.2.102

In the timer log, I get this entry:
Mon 30 May 2022 14:45 - record time chnged, start prepare is now Tue May 31... < CORRECT
Wed 1 Jun 2022 05:32 - record time chnged, start prepare is now : Wed Jun 1..... < ROGUE

The box was booted at 08:15, May 31, if that helps, so not sure where the 05:32 comes form.

This seems to happen overnight, booting from a deep standby.

Sorry - missed the fact that 6.2.002 was released yesterday

@Spoof - can you confirm that you updated/flashed 6.2.002 (your post says 6.2.102). If so, the time problem should definitely have been fixed. You need to turn on debug logs and attach them.

[Spoof]

Apologies, I am indeed now on 6.2.002 and had the problem this morning.
So will collect logs and post (assuming the problem repeats itself tomorrow morning).

Edit: debug logs already enabled but the log manager is empty.

[twol]

Apologies, I am indeed now on 6.2.002 and had the problem this morning.
So will collect logs and post (assuming the problem repeats itself tomorrow morning).

Edit: debug logs already enabled but the log manager is empty.

If logs are enabled… turn them off, take the reboot then enable and restart…should have debug log …. make sure that you have saved other than in flash

[Spoof]

After a few days of monitoring this, it seems the bug was indeed squashed!
Thanks to all for your help.