View Full Version : [MB Premium Twin HD] Box failed to wake up from Deep Standby for a recording
Today my box failed to wake up from Deep Standby to do a recording. (In fact it missed 3 - 2 this morning and 1 this evening).
The timers were in place and when I started the box manually this evening (15 mins after a timer was meant to be running) it started the recording (in the middle of the programme).
Any ideas?
There does seem to be one possibility here....
I has occurred to me that I did shut the box down on Saturday by using "shutdown -h now" from the command line (as I was logged in at the time,. and the box is in a different room).
So I've just done some tests.
"shutdown -h now": shuts down the box and the blue LED (searchlight on this box!) comes on. But it doesn't wake-up to record.
"shutdown now": stops the box, but leaves the front LED displaying the name of last channel it was on (but this is no longer scrolling). It also doesn't wake-up to record. (It is also unresponsive to the remote control, so you needed to switch it off/on using the rear power button to get it back up.)
Selecting "Deep Standby" from the menu shuts it down so that it appears to be in the same state as after "shutdown -h now". But this does wake up to record.
Is this expected behaviour?
And, if so, is there anyway to put the system into Deep Standby from the command line?
is there anyway to put the system into Deep Standby from the command line?
Not that I know of.
Sent from my SM-G900F using Tapatalk
Not that I know of.Which sounds odd, given that it's the software on the box has to put it into Deep Standby.
Perhaps I need to look at the AutoTimer code...
Which sounds odd, given that it's the software on the box has to put it into Deep Standby.
Perhaps I need to look at the AutoTimer code...
There very well may be one but I dont know of one personally and I'm not a coder either.
Have you tried:
shutdown -P now
root@vusolo2:~# shutdown
Usage: shutdown [-akrhPHfFnc] [-t sec] time [warning message]
-a: use /etc/shutdown.allow
-k: don't really shutdown, only warn.
-r: reboot after shutdown.
-h: halt after shutdown.
-P: halt action is to turn off power.
-H: halt action is to just halt.
-f: do a 'fast' reboot (skip fsck).
-F: Force fsck on reboot.
-n: do not go through "init" but go down real fast.
-c: cancel a running shutdown.
-t secs: delay between warning and kill signal.
** the "time" argument is mandatory! (try "now") **
root@vusolo2:~#
Have you tried:
shutdown -P nowNot as part of my recent testing, no.
But worth a go, thanks.
EDIT: No, that doesn't work either....
I'm just confused by "-h" not working.
My "mental picture" of the box is that the front-panel has knowledge of the [I]next event (a wakeup or recording) and so will ensure that the box is powered on and running at (before) that time.
Given that "-h" does switch the system off and, at last as far the external visual appearance goes, put the box into the same state as the Deep Standby menu option does, I'd expect the front-panel controller to restart it.
So obviously my model is wrong.
If anyone knows what the actual model is then I'd be pleased to know.
But maybe the normal shutdown (from the menu or from a standby timer) has code to check the next wakeup time and set the ticker accordingly? Maybe when you run shutdown from telnet all it is doing is killing processes and the wakeup ticker is not set? I originally thought that these boxes would have a real time clock, but I have been informed otherwise and this is also borne out by the fact that when awoken from deep standby the clock time defaults to 1/1/1970 which in itself causes problems with log dates, but that's another issue ...
-h & -P are different options.
Just type shutdown into a shell & see the available options, should work the same way on all linux devices.
otherwise and this is also borne out by the fact that when awoken from deep standby the clock time defaults to 1/1/1970 which in itself causes problems with log dates, but that's another issue ...
That's a long standing issue. E2 restart uses correct time, reboot doesn't.
I assume that this is because it's a full linux restart and the clock data is lost once you go into deep standby?
I assume that this is because it's a full linux restart and the clock data is lost once you go into deep standby?
No idea, full reboot produces logs with old linux dates, E2 restart has the correct time.
@judge - why are being shown as offline, when you are posting? Invisibility shield :confused:
@judge - why are being shown as offline, when you are posting? Invisibility shield :confused:
No idea? Not using any invisibility shields? :confused:
-h & -P are different options.
Just type shutdown into a shell & see the available options, should work the same way on all linux devices.As it turns out -P is an option to -h, so -P on it's own won't do anything (except tell you that you need -h as well).
I'd expect -h to power down as well. It's difficult to imagine a situation where you'd want the power to still be on (or, indeed, for the hardware to be able to do it) unless you've shutdown to a specific run-level, which BusyBox doesn't cater for anyway.
But maybe the normal shutdown (from the menu or from a standby timer) has code to check the next wakeup time and set the ticker accordingly?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.
Think you need to learn linux & then E2?
shutdown will work the same on all linux boxes.
@judge - why are being shown as offline, when you are posting? Invisibility shield :confused:
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.
That's a long standing issue. E2 restart uses correct time, reboot doesn't.Presumably because the board in the box has no real-time clock, so only gets a time once the system is sufficiently up to get a time from the Internet or TV feed.
The Raspberry Pi has the same issue, and Raspbian "solves" (== works around) that by writing a file every few minutes (/etc/fake-hwclock.data) with the current time and uses this to set an "approximate" time as soon as possible during boot. May be ~1minute slow on a reboot, but is better that 1 Jan 1970.
Presumably because the board in the box has no real-time clock, so only gets a time once the system is sufficiently up to get a time from the Internet or TV feed.
when you setup your receiver you have the option of synchronizing the date and time from the Internet or directly from the satellite feed.
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 :)
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?
Don't think I ever had, never even knew about that option?
http://www.world-of-satellite.com/profile.php?do=editoptions
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.
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.
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?
Try here
https://github.com/oe-alliance
Try here
https://github.com/oe-allianceHmmm.
That starts with "E2openplugin-OpenWebif (https://github.com/oe-alliance/e2openplugin-OpenWebif)", which is forked from E2OpenPlugins/e2openplugin-OpenWebif (https://github.com/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!
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....
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.
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
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.
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.
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.
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).
I still think you're not getting me on this :confused: 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.
I still think you're not getting me on this :confused: 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.
I obviously have too much time on my hands :D 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
28-10-14, 22:38
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'.
Well - "ticker" maybe?
In all fairness to Rob, as a non native English speaker, he does a much better job in typing readable English than many of our native English speaker support requests.
http://www.world-of-satellite.com/showthread.php?41560-tm-nano-t3&p=321473&viewfull=1#post321473
Fair play to Abu for making sense of that one...
Rob van der Does
29-10-14, 06:26
Well - "ticker" maybe?
Hehe, yeah, that's the word :D
I rely too much on my spelling checker, which did allow me to write 'thicker' :o
It's just a fun poke :p We were all getting a bit "thick" about the wakeup timer in the thread. Rob knows that I have huge respect for his command of English and its idioms.
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).
Did you get any further with this? Any googling I did on front panel controllers indicated that there was an RTC running plus wake-up timer once there was a 3V supply to the chip. Presumably the interface to linux C (or Python) is dependent on the drivers supplied, but I really can't figure out why the clock doesn't seem to be available after boot from deep standby. Needs a view from linux or driver devs methinks:confused:
Did you get any further with this?No. Once I'd found out the cause I could just stop using shutdown so I concentrated on getting my Bouquets set up (http://www.world-of-satellite.com/showthread.php?41328-Where-can-I-find-information-about-EPG-related-details&p=321943#post321943) with standard Freeview HD channel numbers instead.
Rob van der Does
02-11-14, 07:11
None of the actual E2-running STB's has a RTC in the frontpanel, only a 'ticker' (xxx ticks untill wake up time).
That's the reason E2 needs to get the time (from the transponder or from internet) at start up.
Just start the box with no coax and no LAN connected: system start time will be 1-1-1970.
None of the actual E2-running STB's has a RTC in the frontpanel, only a 'ticker' (xxx ticks untill wake up time).
That's the reason E2 needs to get the time (from the transponder or from internet) at start up.
Just start the box with no coax and no LAN connected: system start time will be 1-1-1970.
Hey Rob - this was all discussed earlier in the thread - I know it's difficult to keep up with everything at our age :p . I even quoted you on the "ticker" in post #30 and #34. I just have an issue understanding why there is no RTC available. Most of the chip controller information (from the chip manufacturers) I could find on the web would indicate that there IS an RTC and alarm present on these chips. You can read the time by issuing cat proc/stb/fp/rtc on a running system. In the power down sequence the RTC is loaded in the fp and so is the wakeup time (StbHardware.py). The fp must have a clock running so that it triggers a boot from deep standby at the wakeup time. I just thought it maybe is an issue with the linux kernel on these systems that maybe can't access the fp clock at boot? The normal linux method to get the hwclock is through /dev/rtc but maybe there are no drivers provided to allow access to the clock on boot up? Do you have any links to where developers have discussed this issue?
You can read the time in /cat/stb/fp/rtc on a running system.That's actually /proc/stb/fp/rtc
The fp must have a clock running so that it triggers a boot from deep standby at the wakeup time.but that just needs a countdown timer, not a real-time clock (although I agree that these do sound very similar - they are both just counters that increment/decrement at the same rate).
That's actually /proc/stb/fp/rtc
but that just needs a countdown timer, not a real-time clock (although I agree that these do sound very similar - they are both just counters that increment/decrement at the same rate).
Sorry about the typo - cut and paste error!
As regards the countdown timer, I think I argued for that earlier in the thread also. It's just that lots of cheapo FP controllers seem to have a proper clock available. I even ended up on an arduino forum where I could see that the clock function on it would continue to run in the absence of power due to the fact that there was a supercapacitor on board which could supply power for up to three days. It looked like a normal electrolytic capacitor.
I think your initial posts in this thread triggered thoughts with me with regard to similar queries I had raised some time back as to why there was no time stamping of log entries and why the clock/date settings were lost on reboot. I suspect the answers are probably deep in the origins of enigma code. I may have to take my Quad Plus apart to check the actual FP controller chip model and see if I can find the spec. I just find it difficult to believe in this day and age that the functionality for continuously running clock is not there. Rant over...
I may have to take my Quad Plus apart to check the actual FP controller chip model and see if I can find the spec.If it's of any help, mine reports this at boot-time:
input: dreambox front panel as /devices/virtual/input/input0and there is an id directory there with these 4 files in:
root@mbtwin:/sys/devices/virtual/input/input0/id# for f in *; do printf "%7s: "
$f; cat $f; done
bustype: 0019
product: beee
vendor: deaa
version: 0001Perhaps you can work out the FP type from those 4 items?
Rob van der Does
02-11-14, 17:03
I suspect the answers are probably deep in the origins of enigma code.
I don't think so; keeping time (from an RTC) would be a Linux thing, not E2.
Reading a bootlog you can see things like:
RTC not ready... wait for transponder time
So E2 seems ready for RTC, but it simply isn't there.
Yes I suspect that the front panel drivers may not "expose" any method for linux to get the time from a HWCLOCK (normally /dev/rtc) and @birdman has already shown that the RTC clock access after boot to /proc/stb/fp/rtc seems to return a low value as if the clock has been set to zero initially. I don't know why this is the case but was interested in finding out.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.