The debug log was named Enigma2-1970-01-01_08-00-59.log which straight away was an indication it couldn't grab a system clock time at UI startup (I believe my internet connection was playing down/up games at the time).
Even though file was_timer_wakeup contained 'True', I'm guessing that because a proper system time wasn't set the Navigation instance didn't then set whatever internal flagging mechanism is needed to allow the shutdown to deep standby at timer end.
Some debug log snippets -
Code: Select all
{562}< 61.735> [eDVBLocalTimeHandler] RTC not ready... wait for transponder time
{562}< 81.574> [Time By]: NTP
{562}< 81.575> [eDVBLocalTimeHandler] invalid system time, refuse to disable transponder time sync
{562}< 141.768> [Navigation] RECTIMER: wakeup to standby but system time not set.
{562}< 168.035> [Console] finished: /usr/bin/ntpdate-sync
{562}< 168.035> [NetworkTime] setting E2 time: 1542739652.2
{562}< 168.037> [eDVBLocalTimeHandler] disable sync local time with transponder time!
What I don't understand is the 'RTC not ready' and 'invalid system time' annotations when compared to a unit that isn't connected to the home network and thus can't grab the current time before the UI is started, as wouldn't it also initially be in 1970?
(from enigma2.sh) -
Code: Select all
if [ -x /usr/sbin/ntpdate ]; then
[ $(date +%Y) -lt 2017 ] && /usr/sbin/ntpdate -b -s -u au.pool.ntp.org
fi
Where would a non-networked T3/T4 get it's time from prior to the transponder tune - the Linux system time right? Which would come from the front panel, wouldn't it?
Why didn't that happen in our case?
Confused!
[and not looking to get into a trademark war ]
Cheers,
Geoff