[MB Premium Twin HD] Box failed to wake up from Deep Standby for a recording

[Joe_90]

It would make far more sense to always have the current first event always loaded in the front-panel controller. That way if, for instance, their is a power cut it would still be able to wake up for the next recording once power is restored.

But there's no real time clock (RTC) in these boxes, so if there was a power cut and then power was subsequently restored it would have to boot up, check timers, set the controller to wake up in "n" ticks and then shutdown again. I don't really know how the timers control the wake up in the front panel controller. Need a programmer to advise

 

[judge]

off topic but In your user CP on the forum you can choose to show your self as invisible rather than online, Judge has had this active for as long as I can remember same as my self.

Don't think I ever had, never even knew about that option?

 

[Larry-G]

Don't think I ever had, never even knew about that option?

http://www.world-of-satellite.com/profile.php?do=editoptions

 

[birdman]

when you setup your receiver you have the option of synchronizing the date and time from the Internet or directly from the satellite feed.

Hence the latter part of my comment.
This has no effect until the network is up, or the tuners are running, which is some time after boot starts. So if there is no RTC on board then the system will start with a Epoch time of 0.
Hence the log-file names.

 

[Joe_90]

I think we understand the issue as regards the epoch timer influencing the log file naming (and their unfortunate deletion on reboot) and I have a bug report raised on that but other issues are taking priority at the moment.

However, as to when the front panel controller gets the wakeup time (or ticks) remains an unanswered question. Really one for a programmer to answer how the mechanism works. I think you've proven that wakeup does not work if you shut the box down through the command line.

 

[birdman]

I think you've proven that wakeup does not work if you shut the box down through the command line.

Hence my comment that I'll have a look at what the Power Timer code does (although I did say AutoTimer, which may have confused people...).

Does anyone know whether I will find most of the OpenVIX and Plugins code at these two links?

• https://github.com/OpenViX
• https://github.com/E2OpenPlugins

or are there other places to look as well?

 

[Larry-G]

Try here

https://github.com/oe-alliance

 

[birdman]

Try here

https://github.com/oe-alliance

Hmmm.
That starts with "E2openplugin-OpenWebif", which is forked from E2OpenPlugins/e2openplugin-OpenWebif (two different git repositories) leaving me with having to figure out which is actually on my box (if I were interested in that code - which actually I am for other reasons).

However, it occurred to me in a sudden flash of inspiration that opkg Packages files contain a Source: entry for each package, so if I append packages to all of the urls in the opkf conf files in /etc/opkg I can find out whence each actually comes!

 

[birdman]

But there's no real time clock (RTC) in these boxes,...

That's not strictly true, at least for my box, as the front-panel needs a clock (otherwise it couldn't wake the box up from Deep Standby) and this is accessible at run time.
So it should be possible to set the time from /proc/stb/fp/rtc after mountall.sh has run (you need /proc mounted, obviously) by reading the value in a program and making a settimeofday() call with it.
I could give this a little test....

 

[Joe_90]

My understanding from Rob is that the controller is just a ticker so no RTC during deep standby, so it's either counting down to zero from a set value or is counting up to a set value. If it actually was an RTC, then the date and time would be available to linux on boot and it obviously isn't on my box which is a Quad Plus. I don't know why an actual hardware clock isn't provided as it should be possible to possible to have one running and still stay under the 1W power limit for deep standby, even if there wasn't a battery backup like on a PC mainboard. My media player, based on an Asus AT5ION-T board manages to maintain a standby state with memory preserved and clock running (but no display) with instant wake-up (maybe 5 seconds) and still stay under 1W.

 

[birdman]

My understanding from Rob is that the controller is just a ticker, so it's either counting down to zero from a set value or is counting up to a set value. If it actually was an RTC, then the date and time would be available to linux on boot and it obviously isn't on my box which is a Quad Plus.

That RTC part doesn't follow. Their is no RTC device on my box, but the front panel does have an RTC and you can get the Epoch time from it.

root@mbtwin:~# cat /proc/stb/fp/rtc
1414501625

 

[Joe_90]

That RTC part doesn't follow. Their is no RTC device on my box, but the front panel does have an RTC and you can get the Epoch time from it.

root@mbtwin:~# cat /proc/stb/fp/rtc
1414501625

Yes - but only while the box is on or in normal standby. In deep standby there is nothing keeping the clock functioning (other than said ticker) otherwise the system could read back the date and time on boot, but it can't without either NTP or getting it from the satellite transponder or terrestrial multiplex.

 

[birdman]

In deep standby there is nothing keeping the clock functioning.

OK. I'll have to agree with you on that as I've just set things up, and it's reporting setting the Epoch time to 51 by reading the front panel at boot time.
Saving/restoring a value to file over a reboot is still on, though.

 

[Joe_90]

Yes - it's a right PITA that the clocks on most of these devices don't keep running in deep standby. I tested with my own receiver and left the network and sat / terrestrial cables unplugged and the clock starts at 01:00 on 1/1/1970. Once you have a network or service connection the clock is set.

 

[birdman]

Well, this may have helped to explain why command-line shutdown doesn't work, as well.

/proc/stb/fp/wakeup_time is the next wake-up time. and this seems to be left at 0 when the box is running.

There is a Python function - setFPWakeuptime (from Tools.StbHardware) - to write the (Epoch) time of the next wakeup to this. So presumably(?) something uses this to set the next time to wakeup as part of the shut-down process.

[Perhaps there's some reason not to have this always populated with the next event time - such as odd things happening if the front-panel tried to start the system when it's already running?]

So, if I really want a command line shutdown then I just need to grab the setting code which is in mytest.py in the OpenVIX enigma2 git repository and run that before shutdown (or even add it is a generic shutdown script if the current wakeup_time is 0).

 

[Joe_90]

I still think you're not getting me on this I don't think the epoch time of next wakeup is written to the front panel on shutdown. I think it's the difference between the current time and next wakeup time - i.e. the number of ticks or seconds or milliseconds or whatever units the front panel controller is using to either count down to zero or up to. So it can only be calculated at the time the box is being shut down. I could be talking complete bs, but logically it's the only way I can see it working if there is no actual clock available. In a PC you would load the wakeup date and time to the CMOS and let the BIOS start the machine up, but that's a fully battery backed clock.

 

[birdman]

I still think you're not getting me on this

I am...

I think it's the difference between the current time and next wakeup time - i.e. the number of ticks or seconds or milliseconds or whatever units the front panel controller is using to either count down to zero or up to. So it can only be calculated at the time the box is being shut down.

Yes. And the setFPWakeuptime call handles all that.
But, unless there is some reason not to, you could always set this every 5 mins (say) to the required countdown at that time.

 

[Joe_90]

I obviously have too much time on my hands Looked at the setFPWakuptime call in the StbHardware.py in the git and could see that where ever the wakeup time was being set, the RTC was also being set in the FP. So maybe what the FP does when it enters deep standby is tick off seconds from RTC until it hits wakeup? Does that make sense?

 

[Rob van der Does]

So maybe what the FP does when it enters deep standby is tick off seconds from RTC until it hits wakeup? Does that make sense?

That's correct; there is no RTC in the frontpanel, only a 'thicker'.

 

[Joe_90]

Well - "ticker" maybe?