View Full Version : [Mut@nt] HD51 Timer Problem
Hi.
The problem - my timers are failing - the start date keeps advancing to a date in the future. I keep changing them to today's date and every time I re-check they have advanced (seemingly randomly) to a date in the future.
Here's what I did:
Online upgrade using the Vix menu > Image Manager (from 6.0.008 IIRC).
I restored the settings.
I have tried deleting all the timers and re-entering them but still the same problem.
Regards.
Hi.
The problem - my timers are failing - the start date keeps advancing to a date in the future. I keep changing them to today's date and every time I re-check they have advanced (seemingly randomly) to a date in the future.
Here's what I did:
Online upgrade using the Vix menu > Image Manager (from 6.0.008 IIRC).
I restored the settings.
I have tried deleting all the timers and re-entering them but still the same problem.
Regards.
How far in future are the dates? Less than 7 days?
Are the timers being set by an Autotimer that is checking the EPG for any occurrence of that program and setting the timers accordingly? If so, are you excluding repeat showing of the program?
Or, are the dates changing on a one off manual set timer?
If you delete an autotimer you have to press the green button afterwards to save the action that you have deleted an autotimer .
1. Yes, less than 7 days in the future
2. No, these are just "normal" timers.
3. Manual set timer, the timers are set Mon-Fri, every week.
4. Never used auto-timers.
1. Yes, less than 7 days in the future
2. No, these are just "normal" timers.
3. Manual set timer, the timers are set Mon-Fri, every week.
4. Never used auto-timers.
Go to the timer list
Highlight a timer that has changed date
Press the "info" button on your remote
You should get a log of what has happened with the timer
First, thanks for your help.
This morning my timer did NOT start automatically, even though it was set correctly.
I opened the timer, changed nothing and clicked the green button (save). The timer started recording immediately. Here is a screen shot of the timer and the log:
6378663787
Your second screenshot shows a timer being set on 28 Apr at 15.42 - your box must have had the date advanced to that date and it set the next timer for 29 Apr at 07.58. That's why it didn't start automatically. When you opened the timer this morning at 08.06 and saved, then it started immediately.
You must have had some issue with the time setting on the box at some stage which moved the timers into the future.
Your second screenshot shows a timer being set on 28 Apr at 15.42 - your box must have had the date advanced to that date and it set the next timer for 29 Apr at 07.58. That's why it didn't start automatically. When you opened the timer this morning at 08.06 and saved, then it started immediately.
You must have had some issue with the time setting on the box at some stage which moved the timers into the future.
No, I never set a timer for the 28th. Never had an issue with these timers (whch have worked for ages) until I updated the image.
I've gone back to 6.0.006
No, I never set a timer for the 28th. Never had an issue with these timers (whch have worked for ages) until I updated the image.
I've gone back to 6.0.006
No - the timer was set on 28th at 15.42, which means your system clock was set to that date at some stage and it calculated that the next occurrence of the programme would be on the 29th. You get me? I don't know why your system time got moved into the future which is what caused the earlier timers to not kick off once your box got set to the correct time.
No, I never set a timer for the 28th. Never had an issue with these timers (whch have worked for ages) until I updated the image.
I've gone back to 6.0.006
Could it be a timer conflict? Have you any other timers set for that time of day - not necessarily every day but perhaps on just one day? The conflict could just be the overlap period (pre or post padding).
The timer in post #5 doesn't appear to have a name ???
No - the timer was set on 28th at 15.42, which means your system clock was set to that date at some stage and it calculated that the next occurrence of the programme would be on the 29th. You get me?
Yes, I get you now but I never moved the clock forward - it is set permanently to transponder time (default setting). And as I said, these timers have worked flawlesly in the old image for some time.
The timer in post #5 doesn't appear to have a name ???
This is probably because I was fiddling to try and fix the problem. It does indeed have a name.
Could it be a timer conflict? Have you any other timers set for that time of day - not necessarily every day but perhaps on just one day? The conflict could just be the overlap period (pre or post padding).
No, Just three timers, all different times. These worked fine in the old image.
Could it be a timer conflict? Have you any other timers set for that time of day - not necessarily every day but perhaps on just one day? The conflict could just be the overlap period (pre or post padding).
The system clock was moved forward at some time - see screenshot in post #5. That messed up the timers. The $64k question is - how did the clock move forward? There is another thread with a similar issue where the clock is being set in the future.
I have had this problem before with my mutant HD51, which gets its time via NTP (not transponder) and a collision of ntpdate responses forces the system clock forward by double the time interval since the box was previously shut down. I only mention this as it's one way the clock can end up in the future. I'm not saying that it is the reason in this particular case, just exploring possibilities.
The system clock was moved forward at some time - see screenshot in post #5. That messed up the timers. The $64k question is - how did the clock move forward? There is another thread with a similar issue where the clock is being set in the future.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.
Quite a few ntp changes 24 days ago...
https://github.com/OpenViX/enigma2/commits/Release?after=ec4dfeac8fef11a5b15846f37b3ea08db567 b968+34&branch=Release
I don't think they're in 6.1.004
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.
Quite a few ntp changes 24 days ago...
https://github.com/OpenViX/enigma2/commits/Release?after=ec4dfeac8fef11a5b15846f37b3ea08db567 b968+34&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.
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).
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.
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.
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.
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.
Wthere will be a Release version available shortly.Yesterday. ;)
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:D
@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.
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.
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
After a few days of monitoring this, it seems the bug was indeed squashed!
Thanks to all for your help.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.