MB Premium Twin gains time in Deep Standby - debug assistance needed!

[Joe_90]

I think that enigma is not able to determine (in the case of the MB Twin anyway) how the box was booted or the state prior to the start of a timer recording. I don't know if it's a driver issue (they seem to have changed in Feb this year) or something else. I'll raise the issue with the other testers to see if they can shed any light. I just know that my GB Quad+ behaves fine in this regard, even to the extent of trying to force a shutdown after a recording if it was started from deep standby and then the user subsequently uses the remote to start watching a channel while the timer recording is in progress.

I don't think there is a setting for when the box is to boot before a timed recording is due. The default padding on a recording is three minutes before and two minutes after, but the box seems to add another minute or two or three before that if it's booting from deep. This makes sense as the normal boot process will take at least a minute and maybe up to two minutes.

[birdman]

I think that enigma is not able to determine (in the case of the MB Twin anyway) how the box was booted or the state prior to the start of a timer recording.

I'm sure I've seen a recording done with the box booting to Standby, and shutting down afterwards (even if it often doesn't do this).

Difficult to tell on a standard build, as the code to read the wakeup reason immediately clears any flag that was set, so the running box always has the value 0 in /proc/stv/fp/was_timer_wakeup (in lib/python/Tools/StbHardware.py getFPWasTimerWakeup() calls clearFPWasTimerWakeup() - it also contains this line of code:

                 wasTimerWakeup = int(file) and True or False

which I'm still trying to get my head around...but that's not an issue here.

If I can remember how to record log entries I could add a debug line to report what state was read here and run it on my box.

[birdman]

If I can remember how to record log entries I could add a debug line to report what state was read here and run it on my box.

Well, that didn't produce what I expected.

I added this code after wasTimerWakeup is set from reading was_timer_wakeup in getFPWasTimerWakeup():

                try:
                        f = open("/tmp/GML_wakeup_info", "w")
                        f.write("[GML] wasTimerWakeup: %s\n" % wasTimerWakeup)
                        f.write("[GML] file: %s\n" % file)
                        f.close()
                except IOError:
                        print "[GML] wasTimerWakeup:", wasTimerWakeup

(the except clause was just what I tried first, but it seems the log file isn't open when we get here) and it produces this result:

[GML] wasTimerWakeup: True
[GML] file: 1

I get the same result from a command-line reboot, and a OpenVix menu restart.

So it should always think it is starting up from a timer wakeup, and hence should always go into Standby (?). But it definitely doesn't do that.

[birdman]

However - it now occurs to me that this value is irrelevant anyway. Whether the box woke up due to a timer is of no interest. What does matter is whether there has been any interactive action since boot time (remote control) or any concurrent network activity.

Just to add intrigue, though, I did set up a timer and shut the box down to text that code. It produced the same result.
But then I deleted the timer via the Open Webif interface in mid-recording.
The box immediately shut-down (despite the fact that I was logged into it at the time)!

Here's a debug log of that delete-timer->shutdown part. shutdown.log

[birdman]

I just know that my GB Quad+ behaves fine in this regard, even to the extent of trying to force a shutdown after a recording if it was started from deep standby and then the user subsequently uses the remote to start watching a channel while the timer recording is in progress.

To me that is a bug. It should know the box has been used since boot-time and not try to shutdown.
Although it's also the case that there should be an option to allow you to re-instate the shutdown at recording end if you stop watching while a recording is in progress.

[Joe_90]

I agree with you that the GB Quad+ shouldn't be trying to force a shutdown on a completed timer if you are actively using the box, but it does demonstrate a different behaviour than the MB Twin, which just doesn't seem to know what state it's in. Thanks for the investigation, though!

[ccs]

I agree with you that the GB Quad+ shouldn't be trying to force a shutdown on a completed timer if you are actively using the box, but it does demonstrate a different behaviour than the MB Twin, which just doesn't seem to know what state it's in. Thanks for the investigation, though!

My ET10K always prompts me whether or not to shutdown after a timer, which has been set to go into deep standby, has finished.

[Joe_90]

If you explicitly set the timer to go into deep standby, then I can understand that behaviour.

My timer recordings are normally set to the default option (I think auto or standard) which should return the box to the state it was in prior to the timer being executed - deep standby or standby or normal viewing. As it is at the moment I have to set my autotimer defaults to force the box into standby after a recording on my MB Twin. The Quad behaves properly.

[Joe_90]

Here's a snip of the debug log from my GB Quad Plus which has just woken up from deep standby to record:

[PowerTimer] PowerTimerEntry(type=autodeepstandby, begin=Wed Sep 23 06:12:58 2015)
[PowerTimer] PowerTimerEntry(type=wakeuptostandby, begin=Thu Sep 24 06:00:00 2015)
RECTIMER: wakeup to standby detected.        <---------------- this is not present in MB Twin log
[CrossEPG_Auto] AutoStart Enabled
[CrossEPG_Auto] Schedule Enabled at  Wed 23 Sep 2015 13:11:55 IST
[CrossEPG_Auto] Time set to Thu 24 Sep 2015 06:07:00 IST (now=Wed 23 Sep 2015 13:11:55 IST)

Here's a snip from the MB Twin which has woken up from deep standby to record the same programme:

[PowerTimer] PowerTimerEntry(type=autodeepstandby, begin=Wed Sep 23 09:36:56 2015)
[PowerTimer] PowerTimerEntry(type=wakeuptostandby, begin=Wed Sep 23 18:00:00 2015)
[CrossEPG_Auto] AutoStart Enabled
[CrossEPG_Auto] Schedule Enabled at  Wed 23 Sep 2015 13:09:46 IST
[CrossEPG_Auto] Time set to Wed 23 Sep 2015 18:06:00 IST (now=Wed 23 Sep 2015 13:09:46 IST)

The message "RECTIMER: wakeup to standby detected" is not present in the MB Twin log. The GB Quad started up, tuned to its default startup channel and then went into standby, showing just the clock. The MB started up, tuned to its default startup channel and stayed on it.

[Joe_90]

@birdman - the code that generates that RECTIMER message comes from Navigation.py:

	if getFPWasTimerWakeup():
			self.__wasTimerWakeup = True
			if nextRecordTimerAfterEventActionAuto and abs(self.RecordTimer.getNextRecordingTime() - time()) <= 360:
				print 'RECTIMER: wakeup to standby detected.'
				f = open("/tmp/was_rectimer_wakeup", "w")
				f.write('1')
				f.close()
				# as we woke the box to record, place the box in standby.
				self.standbytimer = eTimer()
				self.standbytimer.callback.append(self.gotostandby)
				self.standbytimer.start(15000, True)

Do I take it that the test above checks for wasTimerWakeup to be true AND the "after event" setting in the timer to be "auto" AND the time to the recording to be <= 6 minutes?
The recording is due to start in my case in 194 seconds and the "after event" setting is auto. Bit of a puzzle really.

[Joe_90]

My MB booted from deep at 18.00 with a scheduled powertimer (runs Autobouquets and CrossEPG). This powertimer explicitly has "wake to standby" setting. However, the box booted and zapped to the last channel viewed. I checked the /tmp directory for any files which are supposed to hold timer wakeup flags - nothing there.

I can only think at this point that the last set of drivers (18/02/2015) may have messed up the boot flags or else the front panel code updates did

[birdman]

@birdman - the code that generates that RECTIMER message comes from Navigation.py:
...
Do I take it that the test above checks for wasTimerWakeup to be true AND the "after event" setting in the timer to be "auto" AND the time to the recording to be <= 6 minutes?

That's what the code says, yes.
Arguably the wasTimerWakeup is completely superfluous! If the box is booting and there is a recording starting in <= 6mins then it was woken up by a timer, since the timer reboot should happen around then anyway. The chance of someone shutting down the box (and ignoring the warning about a pending recording start) is surely minimal.

My MBTwin does show this line from time to time - the reason it doesn't always do so is that if there has been a long(ish) time off before the recoding it will wake up "early" and fail the <= 6min test. (It did show it last night for the test timer restart I put in place as it was only 5 mins from shutdown to timer reboot).

So the fact that the MBTwin marks all startups as a timer wakeup doesn't actually matter. All enigma2 really needs to know is "has the remote been used since boot time" for a standby decision and also "is someone using NFS/Samba/command-line login now" for a deep-standby decision.

[birdman]

Note that the 6min grace isn't what the rest of the code uses.

mytest.py (which seems to be some oddly-named startup and shutdown code) sets the timer to start 4 mins early. Might be good candidates for some suitably named parameterizing and global usage rather than 240 and 360 ((PRESTART_SECS = 240, EXTRA_PRESTART_SECS = 120 and add theem together for the 360 usage)?

Also, that code notes (it's unusually well commented code) that GB system start 2 mins earlier than the wakeup time setting anyway, so sets the wakeup time for 2 mins later for enigma2 consistency.

[Joe_90]

Where is mytest.py located in github? Can't seem to find it.

ok - found it!