T4: Power Timers - T4 refuses to wake up in the morning...

Grumpy_Geoff · Post by **Grumpy_Geoff** » Sun Dec 13, 2015 16:21

Hi Greg,

ghines wrote:
Grumpy_Geoff wrote:You don't need to use a Power Timer if you're going to use the record-to-trash 'refresh-the-EPG' daily recording timers - as they're just normal recording timers that only differ by recording to the trash folder (so you don't have to cleanup the recordings).
I remember now when I had trouble with my first T4, that turned out to be hardware, that someone mentioned this method. Is there any advantage to using this method instead of say zap timers? Apart from having to get PT's working.

I didn't change to zap timers because I didn't want the zap 'refresh' timers upsetting viewing as I set them to kick-off at 4pm (after broadcasters had updated the programming schedules). I copied this method from "simoncasey" (aplogies to the actual poster if I've attributed this incorrectly).

ghines wrote:

Grumpy_Geoff wrote:Yep most likely, given the EPGRefresh 'info' showed it didn't run and then shut down the T4.
If you haven't deleted the Power Timer, does it have any entries (you can also look in file \\BEYONWIZT4\Root\etc\enigma2\pm_timers.xml)?

pm_timers.xml looks like this:-

Code: Select all

<?xml version="1.0" ?>
<timers>
<timer timertype="wakeuptostandby" begin="1449979200" end="1449979200" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="once">
<log code="15" time="1449740913">time changed, start prepare is now: Fri Dec 11 02:59:40 2015</log>
<log code="15" time="1449807161">time changed, start prepare is now: Sat Dec 12 02:59:40 2015</log>
<log code="15" time="1449865429">time changed, start prepare is now: Sat Dec 12 09:29:40 2015</log>
<log code="5" time="1449872980">activating state 1</log>
<log code="6" time="1449872980">prepare ok, waiting for begin</log>
<log code="5" time="1449873000">activating state 2</log>
<log code="5" time="1449873000">activating state 3</log>
<log code="15" time="1449955642">time changed, start prepare is now: Sun Dec 13 14:59:40 2015</log>
<log code="5" time="1449979180">activating state 1</log>
<log code="6" time="1449979180">prepare ok, waiting for begin</log>
<log code="5" time="1449979200">activating state 2</log>
<log code="5" time="1449979200">activating state 3</log>
</timer>
</timers>

Note how the 2 at 0300 don't work!

Yep, I can see that - no 3am starts on 11-Dec nor 12-Dec.
11-Dec 03:00 wake-up programmed at 20:48 10-Dec (assuming you're in AEST), I assume this was not long before you shut down to deep standby, giving this a circa 6 hour deep standby before the wake-up (that never happened).
12-Dec 03:00 wake-up programmed at 15:12 11-Dec. I assume a similar deep standby period prior to the wake-up that didn't occur.
Both were across midnight.
Compare this to the next two which worked - programmed @ 12-Dec 07:23 for 09:30 (so guessing a 2-hour deep standby), and 13-Dec 08:27 for 15:00 (6.5 hour standby).

So, some long periods of deep standby that on two occasions failed to bring the T4 to standby, but on the other occasion it did.

Cheers,
Geoff

randomcns · Post by **randomcns** » Tue Dec 15, 2015 19:52

[

Grumpy_Geoff wrote: I don't know the ratio of how many users leave their Tx in standy c.f. deep standby, and use an automated EPGRefresh, but I don't recall any reporting an EPGRefresh start issue. I think in all probability those same users won't be using wake-up Power Timers.

Just thought I would weigh in. When not using the T4 I have it in deep standby with a daily power timer to wake to standby for an EPGRefresh at 15:30 and have experienced ongoing issues with the power timer not waking the box. I have also had a manually set regular record timer fail. Autotimer set timers continue to work. I found the power timer would work again (but for only one day) if I did a cold boot. EPGRefresh appeared to work if the power timer did, but there were occasions it seemed not to. Unfortunately I have not had time to systematically troubleshoot these failures.

My power timer log for last 10 days is as follows:

log code="15" time="1449120600">time changed, start prepare is now: Fri Dec 4 15:29:40 2015</log>
<log code="15" time="1449207490">time changed, start prepare is now: Sat Dec 5 15:29:40 2015</log>
<log code="5" time="1449289780">activating state 1</log>
<log code="6" time="1449289780">prepare ok, waiting for begin</log>
<log code="5" time="1449289800">activating state 2</log>
<log code="5" time="1449293400">activating state 3</log>
<log code="15" time="1449293400">time changed, start prepare is now: Sun Dec 6 15:29:40 2015</log>
<log code="5" time="1449376180">activating state 1</log>
<log code="6" time="1449376180">prepare ok, waiting for begin</log>
<log code="5" time="1449376200">activating state 2</log>
<log code="5" time="1449379800">activating state 3</log>
<log code="15" time="1449379800">time changed, start prepare is now: Mon Dec 7 15:29:40 2015</log>
<log code="15" time="1449472667">time changed, start prepare is now: Tue Dec 8 15:29:40 2015</log>
<log code="15" time="1449564560">time changed, start prepare is now: Wed Dec 9 15:29:40 2015</log>
<log code="15" time="1449648754">time changed, start prepare is now: Thu Dec 10 15:29:40 2015</log>
<log code="5" time="1449721780">activating state 1</log>
<log code="6" time="1449721780">prepare ok, waiting for begin</log>
<log code="5" time="1449721800">activating state 2</log>
<log code="5" time="1449725400">activating state 3</log>
<log code="15" time="1449725400">time changed, start prepare is now: Fri Dec 11 15:29:40 2015</log>
<log code="15" time="1449823683">time changed, start prepare is now: Sat Dec 12 15:29:40 2015</log>
<log code="15" time="1449914052">time changed, start prepare is now: Sun Dec 13 15:29:40 2015</log>
<log code="15" time="1449997373">time changed, start prepare is now: Mon Dec 14 15:29:40 2015</log>
<log code="15" time="1450083193">time changed, start prepare is now: Tue Dec 15 15:29:40 2015</log>
<log code="15" time="1450168992">time changed, start prepare is now: Wed Dec 16 15:29:40 2015</log>

The entry for Thu 10th shows it working after I cold-booted on Wed 9th as a test. I plan to run some more tests when I have time. I am using latest public release firmware (not the beta release).

ghines · Post by **ghines** » Thu Dec 17, 2015 06:43

Hi all,

Here's my latest at trying to get this to work.

Reset to factory defaults | restored known good backup that did work. No luck, still the same.

Reloaded latest public firmware | restored known good backup that did work. No luck, still the same.

My only conclusion is this is somehow a hardware issue, but I have no idea what would need to fail to reproduce this problem. Guess it's back to BW.

Greg

Gully · Post by **Gully** » Thu Dec 17, 2015 09:51

ghines wrote:Here's my latest at trying to get this to work.

Reset to factory defaults | restored known good backup that did work. No luck, still the same.

Reloaded latest public firmware | restored known good backup that did work. No luck, still the same.

My only conclusion is this is somehow a hardware issue, but I have no idea what would need to fail to reproduce this problem. Guess it's back to BW.

Greg

Have you tried without restoring a backup?

Just thought given you are trying these options the obvious one to try is factory default with just a standard setup through the wizard, so no plugins, extras or anything and then create a power timer to test.

ghines · Post by **ghines** » Thu Dec 17, 2015 10:42

Gully wrote:
ghines wrote:Here's my latest at trying to get this to work.

Reset to factory defaults | restored known good backup that did work. No luck, still the same.

Reloaded latest public firmware | restored known good backup that did work. No luck, still the same.

My only conclusion is this is somehow a hardware issue, but I have no idea what would need to fail to reproduce this problem. Guess it's back to BW.
Greg

Have you tried without restoring a backup?

Just thought given you are trying these options the obvious one to try is factory default with just a standard setup through the wizard, so no plugins, extras or anything and then create a power timer to test.

OK, will do tonight. I've got nothing to lose

Greg

Gully · Post by **Gully** » Thu Dec 17, 2015 10:48

ghines wrote:OK, will do tonight. I've got nothing to lose

Greg

Great. Might help narrow the factors.

prl · Post by **prl** » Thu Dec 17, 2015 10:54

I'm still doing tests to try to narrow down the conditions where srto2's original scenario fails. Because I can only do one test a day, this is s..l..o..w.

ghines · Post by **ghines** » Thu Dec 17, 2015 10:58

prl wrote:Because I can only do one test a day, this is s..l..o..w.

Tell me about it

Having to wait a day for each change done is very slow indeed.

Greg

ghines · Post by **ghines** » Fri Dec 18, 2015 05:33

Gully wrote:Greg

Have you tried without restoring a backup?

Just thought given you are trying these options the obvious one to try is factory default with just a standard setup through the wizard, so no plugins, extras or anything and then create a power timer to test.

Did this last night and guess what, the power timer worked. Well, Well, Well !!!!!! Sort of rules out a hardware issue, yes/no?

OK, Here's a summary of my story with this T4 and I will try to keep it as short as possible, but without missing out those important points.

This is my second T4 as my first was replaced under warranty due to it changing channels all by itself and various other issues. However before it was removed from service I did a backup, as you do.

When the new barebones T4 arrived, I installed the HDD connected it and turned on. The firmware was not the latest (November this year) so I turned it off, plugged in the USB with the firmware, turned on, installed the firmware, rebooted and when asked if I wanted to install my backup selected yes.

As there was no EPGRefresh I installed that, configured it and everything worked like a dream. EPGRefresh was turning on at 3AM from a Deep Shutdown and automatically Shutting Down as it should. Note, I was not using any Power Timers (PT's) at this stage.

Then EPGRefresh suddenly stopped working and would not wake from a Deep Shutdown. This happened around the same time I did a scan to pick up the new 9HD channel.

In an effort to try and work out what was happening I started to use PT's to turn on the T4 in the wee hours and soon discovered they too would not wake up the T4 from a Deep Shutdown. Further testing showed both EPGRefresh and the PT's would wake the T4 from a Deep Shutdown but only for times before midnight. Any times after midnight and the T4 would not wake from a Deep Shutdown. I tried various times, 00:03, 02:00, 03:00 and 04:00, and all failed. The T4 was put into Deep Shutdown around 9PM each night.

So recently I restored to factory defaults, installed the backup mentioned above from my first T4 and the PT's would not work after midnight nor would EPGRefresh. Next was to reload the same version of firmware (November this year), went through the wizard restoring the backup just as I did when I received this T4. Installed EPGRefresh and made a PT for 3AM. The PT did not wake from a Deep Shutdown and EPGRefresh would not wake the T4 from Deep Shutdown for times past midnight.

Last night, as suggested by @Gully, I reloaded the firmware (November this year), but did not install the backup just ran the wizard. Changed the power button to do a Deep Shutdown for a short press, and setup a PT to wake to standby at 3AM after deleting the disabled PT what was there. Did not install EPGRefresh. And it worked, as this morning the T4 is in standby mode with the current time on the display.

So guys, what's the next step.

Greg

Gully · Post by **Gully** » Fri Dec 18, 2015 09:32

I'd start slowly configuring your T4 and re-testing to see if it still works as you return it to the state you would like.

And as IanSav said, don't assume EPGRefresh is a problem as it works perfectly for me and I shut down every night though into Standby, so it's worth testing still.

Grumpy_Geoff · Post by **Grumpy_Geoff** » Fri Dec 18, 2015 11:37

Gully wrote:I'd start slowly configuring your T4 and re-testing to see if it still works as you return it to the state you would like.

As Peter stated, that will be --

prl wrote: s..l..o..w.

One test a day

Gully · Post by **Gully** » Fri Dec 18, 2015 11:42

Grumpy_Geoff wrote:
Gully wrote:I'd start slowly configuring your T4 and re-testing to see if it still works as you return it to the state you would like.
As Peter stated, that will be --
prl wrote: s..l..o..w.

One test a day

Indeed. Though my point was to ensure that it was done step by step and tested.

ghines · Post by **ghines** » Fri Dec 18, 2015 12:07

Gully wrote:Indeed. Though my point was to ensure that it was done step by step and tested.

Although I understand the reasoning it will not be possible to do this. Just imagine, change one setting, wait a day, change another setting, wait a day etc. etc.

Maybe a better approach would be to use my backup and follow the procedure I used that made the issue occur. That might help @prl with his testing.

Greg

MrQuade · Post by **MrQuade** » Fri Dec 18, 2015 12:15

ghines wrote: Although I understand the reasoning it will not be possible to do this. Just imagine, change one setting, wait a day, change another setting, wait a day etc. etc.

You can do the settings in reasonable sized batches. That way at least you will narrow it down to a subset, and can refine from there.

Gully · Post by **Gully** » Fri Dec 18, 2015 12:24

ghines wrote:
Gully wrote:Indeed. Though my point was to ensure that it was done step by step and tested.
Although I understand the reasoning it will not be possible to do this. Just imagine, change one setting, wait a day, change another setting, wait a day etc. etc.

Maybe a better approach would be to use my backup and follow the procedure I used that made the issue occur. That might help @prl with his testing.

No don't do that otherwise there is no point in what you have just done. You are taking step by step too literally as I was really suggesting a staged configuration.

Or something like MrQuade suggests.

MrQuade wrote:You can do the settings in reasonable sized batches. That way at least you will narrow it down to a subset, and can refine from there.

tonymy01 · Post by **tonymy01** » Fri Dec 18, 2015 13:24

or turn off NTP and then manually set the time to near midnight, although this limits the usefulness as an accurate PVR if you forget to change the time back again after testing....

ghines · Post by **ghines** » Fri Dec 18, 2015 13:27

tonymy01 wrote:or turn off NTP and then manually set the time to near midnight, although this limits the usefulness as an accurate PVR if you forget to change the time back again after testing....

How do you manually set the time? I could find no way of doing this!

tonymy01 · Post by **tonymy01** » Fri Dec 18, 2015 13:43

Whoops, i guess I should have checked that bit first.
You can do it from telnet:

Code: Select all

root@beyonwizt4:~# date
Fri Dec 18 14:43:13 AEDT 2015
root@beyonwizt4:~# date --?
date: unrecognized option '--?'
BusyBox v1.23.1 (2015-11-06 02:46:16 AEDT) multi-call binary.

Usage: date [OPTIONS] [+FMT] [TIME]

Display time (using +FMT), or set time

        [-s,--set] TIME Set time to TIME
        -u,--utc        Work in UTC (don't convert to local time)
        -R,--rfc-2822   Output RFC-2822 compliant date string
        -I[SPEC]        Output ISO-8601 compliant date string
                        SPEC='date' (default) for date only,
                        'hours', 'minutes', or 'seconds' for date and
                        time to the indicated precision
        -r,--reference FILE     Display last modification time of FILE
        -d,--date TIME  Display TIME, not 'now'
        -D FMT          Use FMT for -d TIME conversion

Recognized TIME formats:
        hh:mm[:ss]
        [YYYY.]MM.DD-hh:mm[:ss]
        YYYY-MM-DD hh:mm[:ss]
        [[[[[YY]YY]MM]DD]hh]mm[.ss]
        'date TIME' form accepts MMDDhhmm[[YY]YY][.ss] instead

Yep:

Code: Select all

root@beyonwizt4:~# date -s 14:47:55
Fri Dec 18 14:47:55 AEDT 2015

You might want to leave it at NTP and set NTP synch to a long time (but on boot up it will get time from NTP still). Or set to transponder, and pull out your antenna..

prl · Post by **prl** » Fri Dec 18, 2015 15:29

Turning off NTP simply enables getting time from the broadcast signal, it doesn't allow you to set the system to an arbitrary time

tonymy01 · Post by **tonymy01** » Fri Dec 18, 2015 15:39

Yes, but you can set to broadcaster/transponder, pull out the antenna, and set it thru telnet, as I demonstrated. I noticed when i had set to NTP, I was able to change the time through telnet, and for some time later it didn't update (since the checks are every 30mins on mine). But when I restarted (power to standby and back) of course it update at that point, so that is why I was suggesting to set to transponder and have the antenna out to avoid it getting overwritten.. this may work, hard for me to test at the moment.

peteru · Post by **peteru** » Fri Dec 18, 2015 16:15

Reboot will reset the clock to 1970 and it will remain like that until "something" changes it. That "something" is usually NTP or broadcaster time. The main board does not have an RTC and the front panel is not used as a source of time either, because it won't know after a power failure.

ghines · Post by **ghines** » Sat Dec 19, 2015 09:47

Gully wrote:I'd start slowly configuring your T4 and re-testing to see if it still works as you return it to the state you would like.

Came home last night and the wife was watching TV. Said she turned it on around 4PM and only watched TV.

I decided to make at few changes to the settings to see what happens. Below is a list of the changes I made but not in the order I made them as I cannot remember that. Sorry.

1. Changed the EPG Time to 12 hour format.

2. Used the Network Browser to add my NAS Movies Folder.
3. Added a timer via EPG for a program tomorrow (Saturday).
4. Changed timer in (3) above for an after event of Deep Sleep (DS).
5. Changed the Power Timer (PT) that I'm using for testing for the 19th. It's a once off timer to wake to Standby at 3AM.
6. Watched a movie via the NAS.
7. Placed the T4 into DS around 9PM.

The T4 was NOT in Standby this morning and info in the PT tells me it did not run.

Next Step?

Greg

Gully · Post by **Gully** » Sat Dec 19, 2015 14:24

I guess you need to "undo" a few of those changes, those that you can, to see if it restores the Power Timers to proper operation.

Grumpy_Geoff · Post by **Grumpy_Geoff** » Sat Dec 19, 2015 16:36

Hi Greg,

ghines wrote: 5. Changed the Power Timer (PT) that I'm using for testing for the 20th. It's a once off timer to wake to Standby at 3AM.
...
The T4 was NOT in Standby this morning and info in the PT tells me it did not run.

Was there a Power Timer set for today (19th) as the one listed above is for tomorrow?

If it was set for today, try setting your EPG time to 24-hour format and test a new power timer as there aren't too many changes that you made to revert,

ghines · Post by **ghines** » Sat Dec 19, 2015 17:37

Grumpy_Geoff wrote: Was there a Power Timer set for today (19th) as the one listed above is for tomorrow?

Sorry typo. PT was set for 19th and did not work. Will edit post. Nice pickup!

Greg

ghines · Post by **ghines** » Sun Dec 20, 2015 08:01

Gully wrote:I guess you need to "undo" a few of those changes, those that you can, to see if it restores the Power Timers to proper operation.

You are assuming an "undo" will completely, 100%, reverse what it did in the first place. What if it does not 100% "undo" what it did? eg: Removing EPGRefresh Plugin does not remove it's settings from the settings file.

I think I need to start over again, reload the firmware, run the wizard and do just one thing at a time. I'm lucky there is only a few things to do so should not take longer then a week.

Greg

Grumpy_Geoff · Post by **Grumpy_Geoff** » Sun Dec 20, 2015 10:28

Hi Greg,

ghines wrote:...
I think I need to start over again, reload the firmware, run the wizard and do just one thing at a time. I'm lucky there is only a few things to do so should not take longer then a week.

By that time, we may have a new front panel firmware. and perhaps it might fix your issue

prl · Post by **prl** » Sun Dec 20, 2015 10:34

My testing seems to indicate that the problem of restarting after a shutdown by a power timer does seem to be associated with the midnight rollover. It also doesn't seem to matter whether the timer that will cause it to wake after the power timer shutdown is another (wakeup) power timer or a recording timer, but I need to look into that more closely.

I still don't know why the midnight rollover causes these problems.

Unless the front panel update to the timer code does more than just trimming the clock to keep more accurate time, I'm not sure that it's likely to fix this problem.

Gully · Post by **Gully** » Sun Dec 20, 2015 10:38

ghines wrote:You are assuming an "undo" will completely, 100%, reverse what it did in the first place. What if it does not 100% "undo" what it did? eg: Removing EPGRefresh Plugin does not remove it's settings from the settings file.

No, that's your assumption. I just figured given you had done all those the quickest way forward was to see if removing some changed anything.

prl · Post by **prl** » Sun Dec 20, 2015 10:51

I can reproduce this failure simply with a "wake" timer that goes to deep standby before midnight, and a "wake to standby" timer that starts after midnight. If the second timer starts shortly before midnight, there's no problem.

The second timer of the pair doesn't seem to need to be a power timer; a recording timer seems to fail in the same way (but remember that a recording timer will be set to start the box 4 minutes before the recording timer is due to start, so don't put it too close to midnight). I suspect that a "zap" timer would fail in the same way.

I also doubt that it matters whether the after-midnight power timer is "wake" or "wake to standby", because "wake to standby" fully wakes, and then goes back to standby, and the box doesn't start at all.

I'm trying to go KISS on this problem, and my next test will be without any other timers apart from the single before/after midnight timers. I'm currently starting a record timer shortly after the "after midnight" timer starts.

Grumpy_Geoff · Post by **Grumpy_Geoff** » Sun Dec 20, 2015 10:58

In this thread I've reported 3 tests where my T4 was put to deep standby prior to midnight by a Power Timer, with a post-midnight 'wakeup to standby' Power Timer set 4.5-6.5 hours later. All tests had the T4 in standby when sighted the next morning, with the T4 start time roughly matching the front panel gain.

Cheers
Geoff

srto2 · Post by **srto2** » Sun Dec 20, 2015 11:10

prl wrote:I can reproduce this failure simply with a "wake" timer that goes to deep standby before midnight, and a "wake to standby" timer that starts after midnight. If the second timer starts shortly before midnight, there's no problem.

I have verified this many times now.

I have kept my testing simple by not complicating the issue (yet) by changing any settings. The only glitch was that one deep standby timers at 00:30 failed to put the box into deep standby. Nothing else had changed and I have not been able to reproduce it.

I will be interested to see if the front panel firmware changes this behaviour...

prl · Post by **prl** » Sun Dec 20, 2015 11:16

Grumpy_Geoff wrote:In this thread I've reported 3 tests where my T4 was put to deep standby prior to midnight by a Power Timer, with a post-midnight 'wakeup to standby' Power Timer set 4.5-6.5 hours later. All tests had the T4 in standby when sighted the next morning, with the T4 start time roughly matching the front panel gain.
...

I've never been able to have a power timer start the box when there's a midnight transition between the power timer that shuts it down and the power timer that starts it up. I don't know enough about the front panel timer/clock to know whether a "midnight" transition could even be important.

The timers that fail certainly seem to be setting the front panel wakeup time correctly.

At some stage I'll start adding debug code to the shutdown sequence to try to see if I can see any problems: reading the wakeup timer back, for example, and comparing it to the RTC clock time.

For the moment, though, I'm still working mainly on the EPG navigation and display problems (no, not "now" shading!).

Grumpy_Geoff · Post by **Grumpy_Geoff** » Sun Dec 20, 2015 11:30

Hi Peter,

prl wrote:...
At some stage I'll start adding debug code to the shutdown sequence to try to see if I can see any problems: reading the wakeup timer back, for example, and comparing it to the RTC clock time.

Previously I'd been thinking that some T4s must be 'losing' that wake up time in certain situations. Finding why it only affects some will need to come from that debugging I believe.

peteru · Post by **peteru** » Sun Dec 20, 2015 11:56

One of the last things that will be printed out on the debug serial port as the device shuts down is the next wake up time that is being programmed into the front panel. That should provide a very strong clue as to whether the problem is in the user space code, the driver or the front panel. If you can, please post those details.

prl · Post by **prl** » Sun Dec 20, 2015 12:04

OK, I'll give it a go on my next test.

peteru · Post by **peteru** » Sun Dec 20, 2015 12:07

You can probably speed up the testing cycle by setting time to NTP, then manually setting the clock from command line to just before midnight. As long as NTP does not reset the time on you in the next few minutes, it should be enough to fake the transition.

prl · Post by **prl** » Sun Dec 20, 2015 12:13

peteru wrote:... As long as NTP does not reset the time on you in the next few minutes, it should be enough to fake the transition.

I'll set the update frequency to once a day

prl · Post by **prl** » Mon Dec 21, 2015 10:20

OK, I've tried peteru's suggestion of setting the time from the console, and I seem to be able to reproduce the problem, and I have a serial log.

So I set the time to 23:45 (tonight) through the command-line interface and then set a shutdown (deep standby) timer for 23:50 and a wakeup timer for 00:05 tomorrow (Tues). I did it in that order to avoid the timer system's "next activation" time getting confused.

The shutdown timer shut the system down as expected, but the wakeup timer didn't start the system. At (the equivalent of 00:07 I restarted manually).

The enigma2 log for the shutdown shows the wakeup timer being set:

Code: Select all

dvb time sync disabled... so set RTC now to current linux time! 2015/12/21 23:5
2
set wakeup time to 2015/12/22 00:05
PowerTimerWakeupAuto False
[AutoTimer] No changes in configuration, won't parse
{487}[eDVBDB] ---- saving lame channel db
{487}[eDVBDB] saved 5 channels and 36 services!
{487}[eDVBResourceManager] release cached channel (timer timeout)
{487}[eDVBLocalTimerHandler] remove channel 0x1ff7650
{487}[EPGC] remove channel 0x1ff7650
{517}[EPGC] abort caching events !!
{487}[eDVBResourceManager] stop release channel timer
{487}thread joined 0
{487}set RTC to previous valid time
{487}[eDVBLocalTimerHandler] set RTC Time

And the serial log shows the timer as being set for a minute earlier (!):

Code: Select all

{1857}[fp_mcu_shutdown] Set wakeup time => 2015/12/22 00:04 (rtc_offset = 39600) 
{1857}[fp_mcu_shutdown] RCU (ABCD, 0A)

I'm not sure what the RCU (ABCD, 0A) message is, but I guess it's the command to set the POWERTOGGLE command in the front panel. I included it in case that guess was wrong.

I'll add some debug code to read back and print the wakeup timer in the enigma2 mytest.py code but first I'll have to fix the bug in Tools.StbHardware.getFPWakeuptime()

IanSav · Post by **IanSav** » Mon Dec 21, 2015 10:50

Hi Prl,

prl wrote:I'm not sure what the RCU (ABCD, 0A) message is, but I guess it's the command to set the POWERTOGGLE command in the front panel. I included it in case that guess was wrong.

I believe that "RCU" is logging that the unit was shut down by a remote control and not the front panel etc.
"ABCD" is the device and sub-device identifier for the T3 remote control.
"0A" is the function code associated with the POWER button on the nominated remote control.

Regards,
Ian.

prl · Post by **prl** » Mon Dec 21, 2015 10:55

IanSav wrote:Hi Prl,
prl wrote:I'm not sure what the RCU (ABCD, 0A) message is, but I guess it's the command to set the POWERTOGGLE command in the front panel. I included it in case that guess was wrong.
I believe that "RCU" is logging that the unit was shut down by a remote control and not the front panel etc.
"ABCD" is the device and sub-device identifier for the T3 remote control.
"0A" is the function code associated with the POWER button on the nominated remote control.
...

That's what I thought, too, with the exception that the system was being shut down by a power timer, not the remote. I was testing what happened to the wakeup timer when the system was shut down by a power timer.

prl · Post by **prl** » Mon Dec 21, 2015 10:58

prl wrote:... first I'll have to fix the bug in Tools.StbHardware.getFPWakeuptime()

Fix submitted to the source repository.

IanSav · Post by **IanSav** » Mon Dec 21, 2015 11:01

Hi Prl,

If a timer, not the remote, was used then this could be the logging of the last remote control used to control the unit that PeterU previously mentioned. I assume that this is logging the a T3 remote was used to power on the unit. If the timer shut the unit down then it is unlikely that the last button pressed was the POWER button.

Regards,
Ian.

prl · Post by **prl** » Mon Dec 21, 2015 11:14

Yes, a T3 remote was being used to control the T4, but it wasn't used to shut it down.

tonymy01 · Post by **tonymy01** » Mon Dec 21, 2015 11:31

But I remember PeterU saying that this had to be pushed into the front panel every time, in order to allow a wakeup with the remote, else if you set the remote to anything other than default, the PVR can't be woken up again with the remote control. I can't remember the specifics as I am still in learning stage...

peteru · Post by **peteru** » Mon Dec 21, 2015 11:36

The information sent to the front panel seems correct. The front panel only has one alarm trigger used to wake up the unit, so whatever is programmed last will be used.

I haven't been following closely, is it the case that a normal timer wakes up correctly, but a power timer does not? Or is it a case where a power timer being used to shut down is preventing any timer from waking up the unit?

It may be worthwhile to compare the serial log of the shutdown case that is broken vs a scenario that works correctly.

peteru · Post by **peteru** » Mon Dec 21, 2015 11:38

BTW: Don't worry about the RCU debug output, it has nothing to do with this problem.

Grumpy_Geoff · Post by **Grumpy_Geoff** » Mon Dec 21, 2015 11:38

Hi Peter,

prl wrote:...
The enigma2 log for the shutdown shows the wakeup timer being set:
Code: Select all
dvb time sync disabled... so set RTC now to current linux time! 2015/12/21 23:5
2
set wakeup time to 2015/12/22 00:05
PowerTimerWakeupAuto False
...

Shouldn't the PowerTimerWakeupAuto entry be "True" not "False"?

I did another Power Timer test last night, PowerTimer deep standby set for 23:30, and a Power Timer wake up to standby at 06:00.
When viewed at 06:04 this morning, the T4 was in standby. OpenWebif's Box Info indicated the boot would have occurred at 05:46 (and /tmp/was_timer_wakeup was timed the same).
I don't have last night's log from setting the PowerTimer because it gets overwritten as the date/time is 1-Jan-1970 08:00:{seconds}, so I can't check the "PowerTimerWakeupAuto" entry.
However, I did see these entries in today's log -

Code: Select all

[AutoTimer] Auto Poll Enabled
[PowerTimer] PowerTimerEntry(type=wakeuptostandby, begin=Mon Dec 21 06:00:00 2015)
[PowerTimer] PowerTimerEntry(type=deepstandby, begin=Sun Dec 20 23:30:00 2015)
POWERTIMER: wakeup to standby detected.
EVIOCGRAB: Device or resource busy
killall: hbbtv.app: no process killed

But I should, given the wake to standby did work!

My record timer example from the other day

Code: Select all

dvb time sync disabled... so set RTC now to current linux time! 2015/12/18 23:04
set wakeup time to 2015/12/19 01:50
recordTimerWakeupAuto True

I'm assuming the 'PowerTimerWakeupAuto' should have been similarly "True" - or have I misunderstood?

Cheers
Geoff

prl · Post by **prl** » Mon Dec 21, 2015 11:49

Grumpy_Geoff wrote:...
Shouldn't the PowerTimerWakeupAuto entry be "True" not "False"?
...

Not for the timers I had set up. PowerTimerWakeupAuto is something of a misnomer. It really means "the wakeup timer is a power timer that goes to standby", and it's passed to the Navigation object at startup to control whether the box goes into standby after initially waking up to be fully running.. The after-midnight timer I set up was a plain wakeup timer, not "wake to standby", and so PowerTimerWakeupAuto should be False.

I have the timers set the way that I did to try to get the simplest possible test case. I'm no longer trying to emulate srto2's setup.

About the Forum

Join us