Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £129! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £179! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[Mut@nt] HD51 OpenViX 5.1.032 will not return to standby/deep standby after recording

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?
 
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.
 
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. :(
 
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.
 
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....
 
@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 - 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?
 

OpenViX Feeds Status

Back
Top