[MB Premium Twin HD] Power Timer looping (and eventually crashing enigma2).

[birdman]

I switched the TV today and flipped it over to the MBT input.
There was a po-up present, saying

A finished powertimer wants to set your Miraclebox Premium Twin to standby. Do that now?

and a timer was counting down (with "yes" selected). Out of interest (v.i.) I left it. When the counter reached 0 it just went back to 180 and started again. And when that one reached 0 it went back to 180 again...
So at that point I selected "no" and pressed OK. The box then went straight into standby.
So I presume that what is actually happening is that that when the timer gets to 0 instead of switching the box to standby it is starting another timer: only when I cancelled a timer did a previous one switch it to standby.

The reason that I left it is that yesterday I noticed that the front panel was displaying "A finished..." and I found enigma2 unresponsive with the top left logo spinning. (I was able to login to the box and reboot it.).
Looking at the debug log then wasn't all that helpful as it had been overwritten with a loop of:

< 17285.666273> Backtrace:
< 17285.666706> /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x45E910]
< 17285.666945> /usr/lib/libpython2.7.so.1.0(PyObject_Call) [0x7753BEDA]
< 17285.667085> -------FATAL SIGNAL
< 17285.667191> PC: 7753bed8
< 17285.667253>     00000000 00000001 7767d210 776aa644
< 17285.667323>     00000000 7294cb70 00000000 729e7e2c
< 17285.667389>     80808080 0000004e 00000000 00687461
< 17285.667457>     2e303338 32303234 203e3834 2d2d2d2d
< 17285.667523>     7294cb70 7754f628 72d552d8 7294cb70
< 17285.667587>     740653f4 740652a8 77d09000 005c0000
< 17285.667662>     00000018 7753be9c 00000000 00000000
< 17285.667728>     776ac150 74065040 74065a20 775e68c8

so I was wondering whether the timer was looping until it ran out of stack, resulting in a signal that itself produced a loop...and it looks like I could have been right.

 

[birdman]

Here's the debug log leading up to the shut-down mentioned above: View attachment debug.log

It shows two "Timeout!" messages (from timeoutCallback() in MessageBox.py), then I press Down and OK (to select "No") followed by the immediate switch into standby.

 

[birdman]

PS: my daughter has also (recently) reported having to back out from many MessageBox timer prompts...

 

[Joe_90]

@birdman - I found so many issues with the MB Twin as regards booting from deep standby to record on the ViX image that I tried the OpenATV image for several weeks. Rock solid as regards booting into standby mode for recording and dependable for shutting down afterwards. There are workarounds in the ATV code which are not present in ViX code to handle the quirky behaviour of the MB drivers to allow detection of timer boots and also to handle the front panel icon etc. It's worth a try if you find ViX less than ideal on the Miraclebox.

 

[birdman]

I have no problems at all with it booting up for recordings.
As for the Front Panel; from what I can see one issue is more in the OpenVix code thna any hardware driver - as I have code that drives the recording indicator fine - and it's driven by the code that starts and stops recordings (which is the obvious place to put it, but OpenVix has none there).

The only issue is around the Power Timers (which I wouldn't expect to be hardware-dependent), which seem to work only randomly and, in the case reported here, catastrophically.

 

[judge]

I have no problems at all with it booting up for recordings.
As for the Front Panel; from what I can see one issue is more in the OpenVix code thna any hardware driver - as I have code that drives the recording indicator fine - and it's driven by the code that starts and stops recordings (which is the obvious place to put it, but OpenVix has none there).

The only issue is around the Power Timers (which I wouldn't expect to be hardware-dependent), which seem to work only randomly and, in the case reported here, catastrophically.

Code or patch so? rather than long winded nonsense?

 

[birdman]

Code or patch so? rather than long winded nonsense?

I was told that the problem (for the FP) was in the MBTwin drivers and that the OpenVix code was fine and in no need of any patching.

As for the Power Timers - I'll be adding some debug statements to see whether I can determine the problem.

 

[Joe_90]

@birdman - I recall that you were looking at the recording icon code some time back. I had issues with the icon handling in ViX also and Andy indicated that it was issues with the driver implementation in MB. A year on and still no improvement in the MB drivers. OpenATV has a raft of code hacks and a load of settings tweaks to handle the icons in the MB and also additional code to handle timer recordings in standby after booting from deep.
@judge - I don't think any of these hacks will make their way into ViX due to the priorities of keeping the code clean, so it's really a matter of choice for the end-user to decide if they want the extra features to go with a different image and potentially have stability or support issues.

 

[birdman]

A year on and still no improvement in the MB drivers.

Except I don't see a problem with them. If you tell them what to display they do so (and it should be up to enigma2 to know how many recordings are in progress).. The only issue appears to be that you have to tell it to display nothing when it first boots (which seems reasonable to me).

Anyway - nothing to do with the problem in this thread.

 

[Joe_90]

You quoted me a bit out of context, there birdman It's a ViX dev's view that the drivers are not up to the job. Other images have "worked around" the apparent issues and the end-user experience is fine as regards the FP display icons, so there are alternatives...

 

[birdman]

It's a ViX dev's view that the drivers are not up to the job.

OK. But when i try to find out what drivers should be doing I'm told that vendors should know - a bit odd (to me) since if no-one can tell me, how can anyone tell the vendors so that they can know?
I can't even find the code that sets the "currently recording" status on the front-panel, even though it was doing it (wrongly) in the standard OpenVix image.

I could make my small change check that it's running on a MBTwin (with a check that could be extended to any other box with a similar FP issue) and submit that. The MBTwin actually has 4 different recording icons, so the code is set to display a different one for the number of recording mod 4 (but that 4 could easily be made boxtype-specific).

 

[birdman]

Now, back to Power Timers.

I decided to have a look at was was actually set on my box today. It should have been one for AutoStandby and another for AutoDeepStandby, only active when in Standby.
But what was actually there was 3 of each(?!?).

<timer timertype="autostandby" begin="1446725011" end="1446725011" repeated="0" afterevent="nothing" disabled="1" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autostandby" begin="1446725011" end="1446725011" repeated="0" afterevent="nothing" disabled="1" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autostandby" begin="1446725004" end="1446725004" repeated="0" afterevent="nothing" disabled="1" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446805758" end="1446805759" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446805758" end="1446805759" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446805758" end="1446805759" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">

That was after I'd tried to delete some of the autostandby onesi n the PowerTimer menu (which didn't seem to go away...).
So just to be sure I went to yesterday's backup, and that had a similar set:

<timer timertype="autostandby" begin="1446630039" end="1446630039" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autostandby" begin="1446630039" end="1446630039" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autostandby" begin="1446630039" end="1446630039" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446714278" end="1446714279" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446714278" end="1446714279" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446714278" end="1446714279" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="wakeuptostandby" begin="1438074000" end="1438074000" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="once">
<timer timertype="wakeuptostandby" begin="1438074000" end="1438074000" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="once">
<timer timertype="wakeuptostandby" begin="1438074000" end="1438074000" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="once">

(No idea where those wakeuptostandby ones came from - perhaps I was doing some experimenting in July...).
Odd that everything seems to be in triplicate.

Anyway, I've deleted them all and installed the two I expect to be there. And will see what happens...

 

[Joe_90]

I really think you're wasting your time digging into why the ViX code is not working properly with the MB Twin There would seem to be little appetite to fix issues on the box while there is a perception that the drivers are not up to snuff. Try OpenATV and see how it works out. You might be surprised.

 

[birdman]

I really think you're wasting your time digging into why the ViX code is not working properly with the MB Twin

I know why it isn't working - which is why I've been able to (trivially) fix it (not on my own - someone else, adm?, did the first draft).
The issue is that the support team say that the drivers are broken, while at the same time being unable to give any indication at all as to what the drivers should be doing. Apparently vendors are just "supposed to know".

 

[abu baniaz]

I wish the driver specifications were documented somewhere. Sadly this isn't the case. Maybe check on the PLi site?

Pretty sure the proof that it was a driver issue was posted recently. Hope this is it.

but looks like the driver file /proc/stb/fp/was_timer_wakeup is not being set to 1 at timer box wakeup

Someone tried to look for the modifications added into the openatv image to deal with the issue, but they couldn't be found. If someone can find them, please post them.

 

[birdman]

but looks like the driver file /proc/stb/fp/was_timer_wakeup is not being set to 1 at timer box wakeup

That's an issue with "recording timers". "Should I go back to sleep after a recording?". On an MBTwin you don't know why it woke up - but I can live with that. (A possible workaround would be to assume that if no key has been pressed since boot-up when a recording finishes then it was woken up for a timer).
The issue I have is with the front-panel indicator that a recording is currently running. With the default image this behaves almost randomly on an MBTwin (and will always come on after a standby/wakeup state change). Given that the icon "moves" (it's a rotating disk) it's annoying to have it permanently on when it doesn't mean anything.
I've updated my code to work on any box with a working symbol_record (to store no. of current of recordings) and symbol_circle (active if non-zero - you configure the number of different states that the box has) in /proc/stb/lcd.

 

[Joe_90]

Once again, in case I wasn't clear in previous posts - the OpenATV image has settings for the FP that will manage the icon states. You can turn the icon off permanently, have it rotate while recording (and off when not recording) and some other tweaks. You can manage the wakeup from deep standby behaviour. The code checks (at boot time) to see if there is an upcoming timer event within the next 600 seconds and sets the /proc/stb/fp/was_timer_wakeup flag because the FP microcode/driver does not do it.
From debate in other threads I would think that these workarounds are unlikely to make their way into ViX code.

 

[birdman]

OK. An update...

PowerTimers
Having deleted the weird timers I had and setting up the two I wanted, all now seems to be OK.
I looked through the PowerTimer code and discovered that they aren't implemented the way I thought they were. I'd assumed that an 30min repeating Auto DeepStandby timer set to only run when the box was in Standby would cut-in 30 mins after the box went into Standby. In fact it runs every 30 mins and each time it runs it checks whether the box is in Standby at the time - so 30 mins is the longest time it would take to kick-in. (There is also a back-off time involved here, but that ends up at 30mins as well).
The Auto Standby timer is similar.
Both timers get restarted on any key press.

Whilst looking at the code I discovered that there was nothing in the Auto Standby code path to check whether a recording was being viewed before popping up the prompt to go to standby. This is annoying - so I've added (and tested) code to do the check, and will no longer get prompted during a viewing.
I'll post the code later.

OpenATV and recording icons
Well, at least it makes the attempt; but it still only uses one (of four) settings (oddly it uses the value "3", so it must know there are multiple ones). So I'll stick with what I have (it's not exactly difficult to do).
I'll post the code later.

OpenATV and recording in standby
This isn't too much of an issue.
Oddly - I had a recording this afternoon with OpenVix which was done with a wakeup to standby. No idea how it happened, but it's not the first time I've seen it.
Wait!! I had only shut the box down 10 mins earlier, so it would have woken up at the "expected" time - rather than the normal 30mins early that happens after several hours shutdown - so perhaps OpenVix has a similar kludge to OpenATV aready?

 

[birdman]

Here's a quick link to the code changes...

http://birdman.dynalias.org/OpenVix/

 

[birdman]

Well, someone was reading this and paying attention as the code to skip the Standby request when playing back a recording has gone into 3.2.024. And whomsoever did it also added the test to the Auto Deep Standby branch too (which I'd forgotten, as my AutoDS timers only activate when the box is in Standby).