[ViX_Misc] Unable to go into deep standby after a recording.

[ccs]

I've now tried 3.2.007

Image + tuner setup + tune + ABM, but no settings restore worked 5 times out of 5.
The only inconsistency was when booting from deep standby to record - sometimes it went back into standby (as it should), and sometimes it didn't.

After restoring settings, it stopped going into deep standby after recording.

I'll start from scratch again and build up my settings when time permits.

Any ideas which area might be causing the problem, or could it just be the restore process?

It will be a pointless exercise if it stops working again after I've recreated all my settings from scratch.

 

[Joe_90]

I know that you're on a different box to mine (MB Twin HD), but I have had similar symptoms with the box not going into standby on a timer recording. So far, the only solution I have found is to use the egami image for my box. It's not a recommendation as such as I would prefer to be using ViX, but the egami image does work consistently for me. It seems to have specific code to overcome issues with booting from deep standby for the Miraclebox, but, so far, I have been unable to locate the source git for the egami image. One of the other testers on here has also had a look but failed to find anything to point at the source of the issue. I'm going to try the Open-ATV image also to see if it works.

 

[twol]

I know that you're on a different box to mine (MB Twin HD), but I have had similar symptoms with the box not going into standby on a timer recording. So far, the only solution I have found is to use the egami image for my box. It's not a recommendation as such as I would prefer to be using ViX, but the egami image does work consistently for me. It seems to have specific code to overcome issues with booting from deep standby for the Miraclebox, but, so far, I have been unable to locate the source git for the egami image. One of the other testers on here has also had a look but failed to find anything to point at the source of the issue. I'm going to try the Open-ATV image also to see if it works.

https://github.com/a4tech dvbapp2-gui = Enigma 2 code

Updates don't look that recent?

 

[ccs]

I've now tried 3.2.007

Image + tuner setup + tune + ABM, but no settings restore worked 5 times out of 5.
The only inconsistency was when booting from deep standby to record - sometimes it went back into standby (as it should), and sometimes it didn't.

After restoring settings, it stopped going into deep standby after recording.

I'll start from scratch again and build up my settings when time permits.

Any ideas which area might be causing the problem, or could it just be the restore process?

It will be a pointless exercise if it stops working again after I've recreated all my settings from scratch.

Re-flashed with openvix-3.2.010, input all settings from scratch, input all timers from scratch. No power timer.

Yesterday, the last timer of the night set to go into deep standby (the rest set to "do nothing"). Nothing happened at all. Deep standby via remote gave "Recordings are in progress or coming up".
Yes to shutdown, and box wakes up 2 minutes later.

Tonight, all timers set to do nothing. Deep standby via remote gave "Recordings are in progress or coming up".
Yes to shutdown, and box wakes up 2 minutes later.

It never used to do this - I'm pretty sure I'd remember having to switch the box off twice every night.

 

[sticky7]

Still happening with me too both on fresh flash of 09 and 10. Power timers start time just keep moving back and don't initiate. The 'recordings are coming up........' Option def seem to be the problem but I can't work out why it thinks that. Could it be checking for auto timers constantly or something?

 

[ccs]

Openvix-3.2.015 + restored settings.

Box now wakes up from deep standby and records in standby and then goes back to deep standby (as set by the timer).

If I press power on during the "recording in standby" and do nothing else, when the recording ends I'm asked whether to go into deep standby.
Yes gives "Recordings are in progress or coming up". Yes to shutdown, and the box wakes up 2 minutes later.

 

[ccs]

Openvix-3.2.021 + restored settings.

Still happening, and clues anybody?

 

[birdman]

I know that you're on a different box to mine (MB Twin HD), but I have had similar symptoms with the box not going into standby on a timer recording.

That will be because the MBTwin hardware doesn't set the flag to say that it was woken up by a timer.
The fact that it sometimes records in standby indicates to me that the OpenVix code has a workaround by checking whether a recording is about to start (but I've never found it). However, that will only work if the box shut-down recently as the FP wakeup timing clock runs a little fast, so the longer the box has been down the earlier before a recording it will wake up.
Or that the switch sometimes works...

 

[ccs]

For me, recordings from deep standby now always record in standby before returning to deep standby when finished.

The sequence is odd, because the box appears to boot up completely (the display is full brightness, and live tv appears via hdmi) for about 10 seconds, before dropping back to standby.

If I then simply interrupt standby by pressing the power button, the box wakes up completely as expected, but deep standby will no longer work.

I reflashed the bootloader a couple of weeks ago, which seems to have helped with recordings in standby.

(The bootloader http://www.openvix.co.uk/index.php/downloads/bootloaders/xtrend-bootloaders/et-10x00-bootloaders download isn't quite right as it's missing the ET10000 directory.)

The fact that

I've now tried 3.2.007

Image + tuner setup + tune + ABM, but no settings restore worked 5 times out of 5.

suggests to me that something I've selected is causing the problem.

I've tried various settings options for autotimers, and have even deleted them all, but no success.

I've not been using powertimers for some time either.

 

[ccs]

That will be because the MBTwin hardware doesn't set the flag to say that it was woken up by a timer.
The fact that it sometimes records in standby indicates to me that the OpenVix code has a workaround by checking whether a recording is about to start (but I've never found it). However, that will only work if the box shut-down recently as the FP wakeup timing clock runs a little fast, so the longer the box has been down the earlier before a recording it will wake up.
Or that the switch sometimes works...

I'm seeing the file "/tmp/was_rectimer_wakeup" being created after booting, and being deleted as soon as the recording starts.

 

[ccs]

Maybe I should summarise.

Unattended, timers work ok, leaving the box in deep standby when they've finished.

If I use the box (any key press, I guess), before or during a timed recording,
after the recording has finished, deep standby gives "Recordings are in progress or coming up", so I have to shutdown twice.

Using the box when there are no timed recordings from switching on to closing down goes into deep standby ok.

 

[birdman]

I'm seeing the file "/tmp/was_rectimer_wakeup" being created after booting, and being deleted as soon as the recording starts.

For a state flag which is entirely internal to the enigma2 process itself it's difficult to see why it ever gets written to an external file anyway.
From what I can see:

• RecordTimer.py deletes it when the recording it's been woken up for starts (as you are seeing), but remembers what the setting was.
• mtest.py (which appears to be nothing to do with testing) looks for it when it's been asked to shutdown (by a Power Key press). It also checks the original setting. If either is true it just goes to standby instead (and enters and entry in the debug log, which has a typo so easy to spot - "PowerOff (timer wakewup)....").
• Navigation.py which writes the original setting as set by the FP at start-up time.

so the only reason for having the file in /tmp would be for you to create one outside of enigma2 for mtest.py to read.
I can't see what that would achieve.

 

[birdman]

If I use the box (any key press, I guess), before or during a timed recording,
after the recording has finished, deep standby gives "Recordings are in progress or coming up", so I have to shutdown twice.

Might be worth checking that "any key" assumption. The Power Key seems to be handled differently.

 

[ccs]

Might be worth checking that "any key" assumption. The Power Key seems to be handled differently.

I'll have a look tomorrow. "Any key" was meant to mean "anything", but clearly that might not be the case.

If the box is in standby and recording, power on is enough to stop deep standby working.

If I power on before a recording starts, which is what I usually do, then deep standby doesn't work, but I will have done others things, like watching a recording, as well.

I'll try powering on before a recording starts, and then powering off after it finishes, but do nothing else.

(The 2 traces I posted on the 1st page of this thread don't have "PowerOff (timer wakewup)....").

 

[birdman]

If the box is in standby and recording, power on is enough to stop deep standby working.

As I'd hope. I'd expect pressing any key to disable the "go back to standby after recording" feature, as you've now interacted with the box, and the "go back to standby" is (I expect) meant for unattended recordings (which this no longer is).

If I power on before a recording starts, which is what I usually do, then deep standby doesn't work, but I will have done others things, like watching a recording, as well.

If there's a recording due to start within the next 5 mins that then that is what is supposed to happen. But if one isn't due (and one isn't already running) then you should be able to shut down to deep standby.

(The 2 traces I posted on the 1st page of this thread don't have "PowerOff (timer wakewup)....").

The first one also doesn't appear to correspond to exactly what you said you did (but it might).

You have this timer entry

[Timer] Record RecordTimerEntry(name=Triathlon: World Series - Chicago -..., begin=Sat Sep 19 14:15:00 2015, serviceref=1:0:1:10BF:104F:233A:EEEE0000:0:0:0:, justplay=0, isAutoTimer=0)

Shortly before the recording was due to start did you press the power button? A log I have of a start-up from and to standby for a single recording has no KEY: entries at all (as I wasn't around to press any).

<   121.888737> [eDVBFrontend] close frontend 0
KEY: 116 POWER
action ->  StandbyActions power
[Standby] leave standby
KEY: 116 POWER
playing 1:0:19:4484:4089:233A:EEEE0000:0:0:0:
getResolvedKey config.usage.remote_fallback failed !! (Typo??)
<   167.116422> [eDVBServicePlay] timeshift
<   167.118711> [eDVBServicePlay] timeshift
<   167.120953> [eDVBServicePlay] timeshift
RemovePopup, id = ZapError
<   167.124129> [eDVBResourceManager] allocate channel.. 4089:233a

The recording started:

[TIMER] Found enough free space to record
[TIMER] Filename calculated as: '/media/hdd/movie/20150919_1415_-_BBC_TWO_-_TRIATHLON__WORLD_SERIES_-_CHICAGO_-___'
recording service: <enigma.eServiceReference; proxy of <Swig Object of type 'eServiceReference *' at 0x728bca28> >
<   207.297096> [eDVBResourceManager] allocate channel.. 104f:233a
<   207.297187> [eDVBResourceManager] available channel.. 4089:233a

the recording stopped (reason unknown - did you only set it up to record for 5m 20s including pre- and post-padding?):

[TIMER] activating state 3
[TIMER] stop recording
<   528.290262> [eDVBServiceRecord] stop recording!

and then you answered the power down query:

KEY: 352 OK
action ->  MsgBoxActions ok
[SKIN] processing screen MessageBoxSimple:
[SKIN] processing screen MessageBoxSimple_summary:
KEY: 352 OK
KEY: 108 DOWN
action ->  DirectionActions down
KEY: 108 DOWN
KEY: 352 OK

The oddity however is this line:

<   210.007252> [eDVBServiceRecord] now running: That's Entertainment, Part 2 (7200 seconds)

well, it was until I looked at one of my own logs. This is actually the programme that was being broadcast on the service you were going to record just before the programme you wanted to record.

 

[ccs]

As I'd hope. I'd expect pressing any key to disable the "go back to standby after recording" feature, as you've now interacted with the box, and the "go back to standby" is (I expect) meant for unattended recordings (which this no longer is).
If there's a recording due to start within the next 5 mins that then that is what is supposed to happen. But if one isn't due (and one isn't already running) then you should be able to shut down to deep standby.

I know I'm effectively overriding unattended mode, but that's the whole point, I cannot then manually get the box into deep standby.
No recordings are due, or running, but it insists there are, and reboots 2 minutes later.
I can't remember what key presses I did when I created the log, but at that time they didn't seem to be relevant.

A very simple test I've just done.....

Switch on box, create a timer which is set for deep standby when finished, shut down to deep standby (which works ok in this situation).
Switch on box, recording starts 5 minutes later, when it ends it has a 180sec countdown asking if ok to go to deep standby.
Ignore this message, and after 3 minutes "Recording(s) are in progress or coming up in a few seconds! Really shutdown now?"

So no key presses apart from switching the box on.

 

[birdman]

I know I'm effectively overriding unattended mode, but that's the whole point, I cannot then manually get the box into deep standby.
No recordings are due, or running, but it insists there are, and reboots 2 minutes later.

OK. I'll test on my system and see what happens there...

 

[birdman]

Ho, hum....oh dear...

Briefly (leaving out the sordid details of testing).

If I set a short recording to go to deep standby when finished , manually bot the box, do not touch the remote (or, indeed, do press a few keys) then when the recording finishes I get the prompt about a Deep Standby request. I let this run to the 180s timeout and....the box gracefully shuts down.
So I am not seeing your problem.

However. in the process of testing this I originally shut down my box about 3 mins before the recoding was due to start (overriding the query about pending timers). It appears that the MBTwin does not like this at all. It went into standby but then hung (totally unresponsive to the remote) displaying the text "miraclebox" on the FP, along with the rotating disk icon from symbol_circle == 1. I needed to use the physical power button to switch to off/on to get it back to life.
This is reproducible.

I have a suspicion that this is caused by setting an FP wakeup time that is earlier than the FP clock (i.e. in the past). It's certainly what happened in the two failures.

I should be able to test this quite easily (set wakeup_time to < rtc and run a command line reboot, so enigma2 doesn't get to do things to the FP).

So, bad news all round. I can't reproduce your problem - and you've made me find one of my own!!

 

[ccs]

A very simple test I've just done.....

Switch on box, create a timer which is set for deep standby when finished, shut down to deep standby (which works ok in this situation).

Switch on box, recording starts 5 minutes later, when it ends it has a 180sec countdown asking if ok to go to deep standby.
Ignore this message, and after 3 minutes "Recording(s) are in progress or coming up in a few seconds! Really shutdown now?"

So no key presses apart from switching the box on.

I've created two debug logs of the above. I removed autotimers.xml to reduce the clutter.
The first one was started after a 5 minute mains power off, in case the fp was involved, but it made no difference.

I'll try again later today with a re-flash and no settings/plugins restore if I get the time.

 

[birdman]

I've created two debug logs of the above.

But both of those logs shows keys being pressed just before shutdown. I presume that's just to force the shutdown (as the default for that prompt is False).
FWIW, both also show that the wakeup timer is being set for less than 1 minute ahead.

I suppose all that can be done is to add a debug print statement to Screens/Standby.py to find out what recording it thinks is about to start,