View Full Version : MB Premium Twin gains time in Deep Standby - debug assistance needed!
My MB twin has started coming out of Deep Standby at the wrong time - too early! The box is kept in the bedroom and is not used much. I have a PowerTimer set to boot the box from deep standby each day at 18.00. My ABM is set to run at 18.04 and CrossEPG at 18.07. The PowerTimer then shuts the box down and returns to deep standby at 18.10. I also have another PowerTimer which puts the box in deep standby after 15 minutes in normal standby. I do this to minimise electricity consumption as the box is idle most of the time.
I've noticed recently that the box is actually booting at about 17.12 and goes into standby mode. After 15 mins the second PowerTimer kicks in and returns the box to deep standby. The box then boots again about 17.59 and ABM and CrossEPG run as scheduled and the box shuts down to deep standby at 18.10 as it should. It does this every day if I haven't used the box in the interim. I've found out that the clock/ticker in the front panel (which runs when the box is in deep standby) is gaining two minutes every hour. If I use the box at (say) 12.00 and then put it into deep standby manually, it will then wake at 17.48 - 12 minutes early! This is quite repeatable. I've tried various intervals and the box always boots from deep at ( 2 x hour_interval) minutes early. I updated the Front Panel firmware from the Plug-Ins menu some months back. It was on version 2.00.31 of RHS500SV. Thinking that it might be to blame I have updated to 2.00.32 but this has made no difference.
I'd like to rule out a hardware issue with my box and would like some help from MB Premium Twin owners in identifying the issue please:)
What you could do for me is to set a PowerTimer for a time which is a number of hours in the future - at least 6 preferably. Put the box in Deep Standby and then check the time the box actually boots. If it's the same as mine it will boot 6 minutes early for three hours or 10 minutes for five hours etc. I'ts preferable to set a PowerTimer, rather than a recording timer, as recording timers will start earlier than scheduled in any case dependant on your own recording settings. If the PowerTimer boots at the correct time, please respond on the thread and let me know what version your Front Panel firmware is, please. This info is on the box information menu under frontprocessor version. You can also check it by looking at /var/log/messages and searching for MCU. My MCU details from messages is:
{129}[MCU] ver : 2.00.32
{129}[MCU] model : RHS500SV
{129}[MCU] power : RCU
Thanks!
I set one for +6 hours and it woke up ~11 mins early.
{188}[MCU] ver : 2.00.31
{188}[MCU] model : RHS500SV
{188}[MCU] power : WUTIMEAt least waking up early allows it to have another go over a shorter time period. Much better than waking up late.
Ok, thanks for that birdman :thumbsup:. Your micom firmware version is the same as my previous one where I noticed the issue starting. It's almost certainly the firmware/driver then. I'll see if the boss can source an earlier version than 2.00.31. I think that the power parameter must mean RCU = remote control, WUTIME = wake up from deep, or SWITCH = boot up from cold. I've seen all three states in my logs.
Confirmed by Stef also on another MB Twin. Has been reported as a Micom firmware problem. We await a fix...
Confirmed by Stef also on another MB Twin. Has been reported as a Micom firmware problem. We await a fix...As long as any fix doesn't make it wake up too late....
As noted, waking early is not an issue. I once wrote wake-up code which deliberately fired early, allowing the (same) code to make a better estimate - just in case the clock was inaccurate or had been changed.
It's an issue all right. Depends on user configuration. How I noticed it in the first place was that ABM/CrossEPG were not running some days but worked fine on others. It turned out that on the days it failed I had been watching something on the box about six hours previously and had put it in standby afterwards. I have a PowerTimer which puts the box in deep standby after 10 minutes in normal standby. When the box booted from deep about 12 minutes early subsequently, it was sitting in standby waiting for the ABM and CrossEPG jobs to run. Just before the ABM job was due to run, my other PowerTimer shut the box down due to 10 minutes inactivity - result no ABM or CrossEPG!
Probably by changing the "wakeup to standby" setting this issue might be worked around, but you're right in that it would be worse if the clock ran slow.
As regards coding for waking early - the Humax Freesat DVR wakes 15 minutes before a scheduled recording if you have "accurate recording" set. It waits and monitors the EIT now/next data until it receives the trigger that the programme is starting and fires off the recording. Useful if the programme start is delayed for some reason. Totally dependent on accurate EIT data from the broadcaster, though. Works fine for the BBCs/ITVs/C4s. Other broadcasters just trigger the change based on the clock schedule, but the actual programme might have started early or late.
It's an issue all right. ....As a workaround you could put in two Power Timer wakeups - 1 for 17:30 and 1 for 18:00. The second one (the one you want) will then be more accurate.
Thanks for that. I have a workaround strategy, but the issue has been reported and hopefully the ticker will be fixed. I don't know who actually develops the FP code or where it might be available in source format. Nothing much comes up when you google Micom front panel code. Lots of stuff about alarm panels etc. The compiled code all seems to reside in
code-ini.com where it's picked up by the various images as an update.
I noticed a commit to oe-alliance this morning which references a deep standby fix on Ceryon, but I don't know if it's related:
https://github.com/oe-alliance/oe-alliance-core/commit/494e0377c92d953577dcddbd496aaea35302fcc8
@birdman - could you post a screenshot of the ViX Information page from the menu on your MB Twin, please? I'm just trying to cross-check something.
@birdman - could you post a screenshot of the ViX Information page from the menu on your MB Twin, please? I'm just trying to cross-check something.Is this the one you mean?
44829
Thanks birdman. I wanted to check that I wasn't losing my marbles! I am testing a Micom Front Panel upgrade and it has changed some of the details on the info page and I wanted to compare. Seems to have fixed the fast running clock but it's causing slight issues with the characters displayed. Will post a screengrab shortly.
Seems to have fixed the fast running clock....It's not that much of a problem. In fact, since I'm seeing the occasional problem with boots getting stuck the fact that it starts early is useful, as it allows my "boot sanity" script to reboot the system until it succeeds.
How far in advance of a recording is the box "supposed" to wake up? Could it be configurable? (Well, it obviously can be as enigma2 sets the wakeup timer on shutdown, but what would it take to make it so).
My GB Quad+ wakes up about 3 minutes before a scheduled recording. The MB Twin was waking up about the same until the last Front Panel microcode update. The fast running deep standby timer was gaining about 2 minutes per hour, so if you had nothing waking up the box for 24 hours it was booting 48 minutes early. The new code I've just tested sorts that out but it has introduced other issues, which are being checked out.
I've also had an on-going problem where the box doesn't go into standby when it boots up for a timer recording. Instead, it zaps to the channel and performs the recording. The channel name is visible on the display. After the recording it stays on the channel. Therefore the box is not in standby, so my shutdown timer (deep standby after 10 minutes in standby) never kicks in and the box stays on. The box should boot into standby when woken by a timer (as opposed to being woken by the remote when it should zap to the last channel viewed).
My GB Quad+ wakes up about 3 minutes before a scheduled recording. The MB Twin was waking up about the same until the last Front Panel microcode update. Hence the question about whether the advance "wake-up time" is configurable (although, if necessary, I'm sure I can hard-wire a suitable time for myself). It takes almost 3 mins to get to the point where a recording would actually be fired off, so if the boot hangs and a reboot (or two - last night) is needed I might well end up missing the start of the actual programme.
And I don't want to add 10 mins of pre-padding.
The box should boot into standby when woken by a timer....I believe that mine does so, but doesn't always shutdown afterwards. I'll try to keep an eye on the FP to see what state it gets to for recordings.
That didn't take long. Looks like you're right.
The box was definitely off (uptime 43mins) and there.is now a timer recording running.
But the FP is showing the channel name (so the box isn't in Standby).
It also seems that this does happen a lot of the time (so I was wrong in my reporting above) as with the channel name showing it also shows the "changing icon" for a recording (in Standby it only show the time), and I now remember seeing this for most recordings (although some of those, of course, happen when the box was already out of standby).
Perhaps the FP flag indicating that wakeup was from a timer is inaccurate?
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.
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 Falsewhich 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.
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.
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. 44864
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.
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!
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.
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.
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.
@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.
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:confused:
@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.
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.
Where is mytest.py located in github? Can't seem to find it.
ok - found it!
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.