OpenViX 5.1.032 will not return to standby/deep standby after recording

[twol]

I know 0 about timers, but just wondered if you were using NTP or transponder to establish the system time (not that it should make a difference I guess)

[Mickkie]

I know 0 about timers, but just wondered if you were using NTP or transponder to establish the system time (not that it should make a difference I guess)

Thanks twol,
The missing log entry "[Navigation] RECTIMER: wakeup to standby detected." is pointing to the mechanism or processes running when the box wakes up from standby. So, something must be amiss with RECTIMER or whatever leads up to it. I have left the system time to sync with the transponder, but can try out an NTP server and see if this makes any difference.

[twol]

Thanks twol,
The missing log entry "[Navigation] RECTIMER: wakeup to standby detected." is pointing to the mechanism or processes running when the box wakes up from standby. So, something must be amiss with RECTIMER or whatever leads up to it. I have left the system time to sync with the transponder, but can try out an NTP server and see if this makes any difference.

Some time ago there were significant changes made to E2 (which Birdman helped to actually work) to resolve system time and thats why I was curious about your use (NTP would avoid any issues in this code)

[Mickkie]

I changed the time setting to sync with NTP and soon discovered that while in Deep Standby the system clock ... stops! So recordings are missed altogether. As soon as I restart the box manually the clock starts again but it won't jump to present time. Consequently, the clock is lagging by how long I left it in Deep Standby. More about this below, but first let me share a recent finding pertinent to the problem at hand:

While experimenting I discovered this behaviour which may be of importance. If I set a timer which is due to start soon, say within the next 10 minutes and place the box in Deep Standby, I get a warning that recordings are imminent. I proceed and place the box in Deep Standby regardless. Well, when it wakes up in a few minutes following such a warning, the box behaves as expected and the "[Navigation] RECTIMER: wakeup to standby detected." is present in the logs. If I set up a timer sometime longer in the future whereby I do not receive a warning when I place it in Deep Standby, the box misbehaves as per my original report.

Regarding the NTP problem, I thought initially the ntp server may be busy so I tried my local router's ntp server using its IP address, then tried 0.pool.ntp.org, 3.uk.pool.ntp.org and all failed to make the box keep up with, or adjust to present time. I haven't noticed such problems when using the transponder to set the system clock. The logs show E2 is obtaining the time from the network NTP server, but it is not drifting to adjust it forward:

< 1854.770> [Console] command: /usr/bin/ntpdate-sync
< 1854.770> [eConsoleAppContainer] Starting /bin/sh
< 1862.919> [Console] finished: /usr/bin/ntpdate-sync
< 1862.920> [NetworkTime] setting E2 time: 1533395566.92
[snip ...]

< 3662.921> [Console] command: /usr/bin/ntpdate-sync
< 3662.921> [eConsoleAppContainer] Starting /bin/sh
< 3671.057> [Console] finished: /usr/bin/ntpdate-sync
< 3671.058> [NetworkTime] setting E2 time: 1533397375.06

but Mut@nt's syslog reports:

Aug 4 18:24:40 mutant51 daemon.err ntpdate[3979]: no server suitable for synchronization found
Aug 4 18:25:16 mutant51 daemon.err ntpdate[4005]: no server suitable for synchronization found
Aug 4 18:26:53 mutant51 daemon.err ntpdate[4064]: no server suitable for synchronization found

despite the fact my router (10.10.10.1) reports synchronisation packets are received from and returned to the Mut@nt (10.10.10.9):

18:30:18: receive: at 5982693 10.10.10.1<-10.10.10.9 VRF: -DEFAULT- flags 1 restrict 000
18:30:18: MRU: interval 101 headway 8 limit 64
18:30:18: receive: at 5982693 10.10.10.1<-10.10.10.9 mode 3/client:AM_FXMIT len 48 org 0000000000.00000000 xmt 0xdf1060c0.2a4c5fc4 NOMAC
18:30:18: sendpkt(38, dst=10.10.10.9, src=10.10.10.1, ttl=0, len=48)
18:30:18: fast_xmit: at 5982693 10.10.10.1->10.10.10.9 mode 4 len 48
18:30:20: receive: at 5982695 10.10.10.1<-10.10.10.9 VRF: -DEFAULT- flags 1 restrict 000
18:30:20: MRU: interval 2 headway 12 limit 64
18:30:20: receive: at 5982695 10.10.10.1<-10.10.10.9 mode 3/client:AM_FXMIT len 48 org 0000000000.00000000 xmt 0xdf1060c2.2a4a9e7d NOMAC
18:30:20: sendpkt(38, dst=10.10.10.9, src=10.10.10.1, ttl=0, len=48)
18:30:20: fast_xmit: at 5982695 10.10.10.1->10.10.10.9 mode 4 len 48
18:30:22: receive: at 5982697 10.10.10.1<-10.10.10.9 VRF: -DEFAULT- flags 1 restrict 000
18:30:22: MRU: interval 2 headway 16 limit 64
18:30:22: receive: at 5982697 10.10.10.1<-10.10.10.9 mode 3/client:AM_FXMIT len 48 org 0000000000.00000000 xmt 0xdf1060c4.2a4a5f16 NOMAC
18:30:22: sendpkt(38, dst=10.10.10.9, src=10.10.10.1, ttl=0, len=48)
18:30:22: fast_xmit: at 5982697 10.10.10.1->10.10.10.9 mode 4 len 48
18:30:24: receive: at 5982699 10.10.10.1<-10.10.10.9 VRF: -DEFAULT- flags 1 restrict 000
18:30:24: MRU: interval 2 headway 20 limit 64
18:30:24: receive: at 5982699 10.10.10.1<-10.10.10.9 mode 3/client:AM_FXMIT len 48 org 0000000000.00000000 xmt 0xdf1060c6.2a4abffe NOMAC
18:30:24: sendpkt(38, dst=10.10.10.9, src=10.10.10.1, ttl=0, len=48)
18:30:24: fast_xmit: at 5982699 10.10.10.1->10.10.10.9 mode 4 len 48

Is this another bug, or is there something missing from my settings?

[ccs]

I'd use transponder time, that's all I've ever used with freeview, and I haven't seen any issues you are now describing.

[Mickkie]

I'd use transponder time, that's all I've ever used with freeview, and I haven't seen any issues you are now describing.

Thanks css, yes, I've returned the setting to transponder since NTP doesn't seem to play well in the current incarnation of the firmware.

Regarding the buggy behaviour I've reported here with waking up from Deep Standby for a recording, not going back into Standby while recording, and not returning to Deep Standby after the recording is finished, I'm curious if other Mut@ant users have not suffered from such symptoms.

Could it be something in my particular hardware causing the problem? I don't know what tests are performed to produce "RECTIMER: wakeup to standby detected" and why these only work when the box was placed in Deep Standby recently. Could it be that these tests and RECTIMER work if the disk is still spinning from the previous cycle, but fail if a potentially sluggish disk has to start spinning from a standstill? Would a 'sleep 2s' instruction to give a chance to the disk to catch up fix my problem?

[ccs]

It won't be anything to do with the disc.

When the box wakes up from deep standby, if there's a recording due within 6 minutes, it assumes it has woken up for a timer recording, rather than you switching it on with the power button.

When you shutdown, it remembers how long to wait before the next timer is due, not the time when it's due.

There is no real time clock running in deep standby.

On some boxes, the wakeup time isn't very accurate, the longer the wait time the more inaccurate it becomes.

There is a startup delay before autotimer runs after a reboot, mine is set to 3 minutes, if you have it set to run immediately it may cause problems.

[Mickkie]

There is a startup delay before autotimer runs after a reboot, mine is set to 3 minutes, if you have it set to run immediately it may cause problems.

I've got mine set to 3 minutes too and changed timeshift to 5 seconds in case it makes a difference. Nothing I've tried works so far.

[Mickkie]

Just a thought: Could it be something HDMI CEC related is causing this? Is HDMI CEC enabled on your Mut@nt? Mine is disabled, but I think it always had been.

[birdman]

Could it be something in my particular hardware causing the problem? I don't know what tests are performed to produce "RECTIMER: wakeup to standby detected" and why these only work when the box was placed in Deep Standby recently.

ccs has explained the coding logic. If your front-panel clock is running fast* the box will wake up "too early". My MBtwin does this, so it stays on after a recording if there is a gap of more than a few hours since the box shutdown.

*you do not want it to run slow....

[Joe_90]

@Mickkie - I have a Mutant HD51 also and have had ongoing time issues since the implementation of the "fake" HWclock coding back in December last year. Prior to that, I had been using my local NTP server for time setting without an issue. I don't use my Mutant much for timer recording (it's located in a bedroom), but I do have it set to wake from deep standby every afternoon at 5pm to run Autoboquetsmaker and CrossEPG and then shut down again. The time setting changes caused all sorts of issues where the box thought the system time was in the past (due to the fake hwclock setting) and didn't seem to set the correct time from NTP quickly enough, even though the server is on the LAN. @birdman and I thought it was due to my WiFi connection being slow and did all sorts of tweaks to the code and I tested various scenarios at the time. I never did resolve it satisfactorily, except by disabling the fake hwclock. The result is that the logs often are timestamped 1/1/1970, but at least the box gets the correct time after about 25-30 seconds and the various timer checks wait until the date/time is updated from 1/1/1970, so recordings and other power timers work as expected.
Maybe the default setting on a new image flash is to use the fake hwclock? I don't know at this stage as I have disabled it and I generally just run software updates rather than fresh image flashes.
As @ccs has indicated, there is no actual real-time clock in the Mutant. Similar to most of the boxes, the front panel is just given a countdown timer to the next wake-up event, so it just "ticks" away so many seconds and restarts. I found the Mutant front panel timer to be very accurate, though. It will wake up on time even days later. My MBTwin used to run fast (like @birdman's) but I got a firmware update which fixed the tick speed, but unfortunately messed up the display and caused other issues, because it was for another, slightly different, front panel.

[Mickkie]

@Mickkie - I have a Mutant HD51 also and have had ongoing time issues since the implementation of the "fake" HWclock coding back in December last year. Prior to that, I had been using my local NTP server for time setting without an issue.

I bought my Mut@nt HD51 before the HWclock coding change and it worked fine then. Some changes, which assume they had to do with this "fake" HWclock coding have caused this problem. I don't know/understand what was changed or why it was changed in the code, but clearly it has broken some of the desired functionality of this box. Is it possible (and advisable) to reverse this change?