Box schaltet sich ohne Timer ein

[Audioniek]

Ich bin da mal in Detail auf der Suche gegangen, und habe Folgendes heraus gefunden (Ich mache weiter in English da ich mich dann besser ausdruecken kann, bitte um Verstaendnis):

fp_control / time management analysis

Two clocks
There are two clocks in the system: the Linux system time and a separate clock maintained by the front panel processor. It is important to realise that the Linux kernel is not aware of the front panel clock, and therefore never interferes or interacts with it. This in turn means that it is the responsibility of the user software (in this case the HDMU image) to properly maintain the front panel clock.

Sequence of events in the HDMU image, power on from deep standby
As observed above, the earliest point in the startup where the system time and the front panel time are (supposed to be) dealt with is the rcS-routine. Regarding timehandling, it does the following:

1. The first thing that happens is the start of the nuvoton front panel driver. This driver is the speaking channel to the front panel clock and also controls the power state this way. The driver cannot synchronise the front panel clock, because at this point there is no network connection, and no satellite channel tuned in, so all possible sources of a correct and reliable time and date are absent
2. Just before Enigma2 is started the program /sbin/set_was_timer_wakeup is called. What that does exactly I cannot tell, as it a binary in the image.
3. Enigma2 is started.

Observation 1: Unless these tasks are done by the mysterious /sbin/set_was_timer_wakeup, either the system time, nor the front panel clock have been touched at this point. This in practice could mean that the system time is set to midnight January 1st 1970 (or 2000). This also means that the front panel clock is uninitialised when the receiver was off the mains before.
Observation 2: In usr/sbin there is a script time.sh that used to be called by the rcS, but is no longer. The script deleays itself for 52 seconds and then again for 30 seconds and executes a fp_contol -dt. The rationale behind this is that is very likely that by this time a satellite channel has been tuned in, and enigma2 has synchronised the system time with the transponder time. I have not been able to find any calling of this routine however.
fp_control -dt version 1.04 does absolutely nothing on a HS8200
fp_control -dt version 1.06 also does absolutely nothing on a HS8200

Net result seems to be that Enigma2 sets the system time, and the front panel clock is untouched at this point.

Sequence of events in the HDMU image, power down to deep standby
Enigma2 stops and returns to the rcS with a return value of 1. The rcS displays the message SHUTDOWN on the front panel display, sets the HDMI CEC and executes an init 0 (=system halt). At the end of this process /etc/init.d/halt is called. The very last ting is script does is an fp_control -e (without a further argument).

fp_control 1.06 now does the following. First it gets the current system time for the local timezone (the front processor works in local time, not UTC). Then it reads the earliest timer entry from enigma (in /etc/enigma2/timers.xml). It evaluates four cases:
A. No timer set at all;
B. Timer time is negative;
C. Timer time is valid, but in the past;
D. Timer time is valid and more than 300 days in the future.
In all four cases the lines: "There are no timers set or\nwake up time in the past;\nshutting down now." are written in the log and the receiver is powered down through nuvoton. Note that the front panel clock is still untouched and may still be uninitialsed!

If none of the above four cases are true, then there is a valid timer entry. fp_control now calculates the wakeup time in local time and writes this in the log.

Both versions now calculate the time difference between the system time and the timer time, and proceed to read the front panel clock time. Then the front panel time is compared to the system time.

fp_control 1.04 and 1.06 handle things differently from this point on.

Version 1.04 accepts a time difference between the two clocks of up to 12 hours either way, with version 1.06 this is 1 hour either way.

If there is a difference of more than 12 hours fp_control 1.04 sets the front panel clock equal to the system time, and then reports the front panel time in the log. It sets a wake up time of the front panel clock plus the calculated difference as wakeup time. If reading the front panel time fails, it does the same, but uses the system time plus the difference as the wake up time.

If there is a difference of more than 1 hour, fp_control 1.06 reports this in the log, but does NOT correct the front panel clock.
It then adds the calculated difference to the front panel time read previously and sets this as wakeup time.
If reading the front panel time fails, it sets the difference (plus zero) as the wake up time (this needs improvement as this will probably result in a failed timer. However if one cannot read the front panel time, is is very unlikely that one can set the wakeup time correctly).

The net result of both approaches should be the same, provided no overflows in the calcuations with a potentially uninitialised front panel clock occur. The approach in version 1.04 is the better of the two, and I have updated the git accordingly.

Both versions more or less assume Enigma2 sets the front panel clock, wheras it does not. The only point in time the front panel clock is corrected at the moment of writing, is when a power down to deep standby is done with fp_control version 1.04 and a valid timer set. Version 1.06 wrongly assumes the front panel clock would be set each time the system time is set, but is assumption is clearly wrong. The version currently in the git should correct this; the fp_control version number has been set to 1.07. I just pushed it.

Please not that this behaviour has been verified by users of Spark7162 with VFD display: they all conmplain about the front panel clock being incorrect until after the first deep standby and subsequent power on has occured. The real improvement would be that the rcS would set the front panel clock correctly before Enigma2 starts in about the the time.sh would do. fp_control 1.05 and higher have an option for this: option -sst copies the system time which must have be set correctly beforehand to the front panel clock. Neutrino handles all this correctly and initialises the front panel clock as part of its startup procedures.

Regards,

Audioniek.