[redring] shows GMT!

hairy_mutley

Active Member
I have my redring set to show clock and elapsed time during playback.
Last night I noticed that the time being displayed was wrong (apparently GMT) although the on-screen time was being shown correctly.
About to post this morning, and thought that I should double-check... the problem has gone, the time is correct.

So why different last night? Well, I had been decorating yesterday, so the PVR had been completely off (no mains supply) for most of the day.
So, as an experiment, I turned the box off (at rear power switch, long enough for the redring to go out) and then turned it back on.
Sure enough, the problem is back; on screen time is correct, but redring time is GMT.
Interestingly, I turned if to standby, came and wrote a little more, went back and turned it on again, and the problem has now gone away again.
Last night it was wrong the whole time it was on (over an hour).
So I presume that it must be removing the power that causes the problem and on -> standby -> on that fixes it.

Well, at least that explains why, it hasn't been observed and reported before, and it is no big deal anyway since it corrects itself, but interesting nevertheless.
 
The main Unix / Linux clock used on the Humax does not use BST or any other daylight saving time system, the time remains the same through winter and summer. The BST correction has to be applied and it looks like it needs a standby cycle for this to happen
 
The on-screen time will be controlled by the standard Humax firmware, where-as the redring front display is controlled by the Custom Firmware which sometimes can only effect a change during a wake-up from standby
 
Having accessed the Humax command line, it does not seem to have a hwclock command, so I cannot see the hardware clock's time, but a date command shows that the o/s does run in BST. Since the date and time are o/s functions, any application, whether standard or custom, should get the same time. Admittedly, you can ask for time in a number of ways, which may affect whether you get local timezone or not. But that cannot be the problem here, as it would not explain why it is sometimes wrong and sometimes right. So it remains hard to understand the inconsistency.
 
Having accessed the Humax command line, it does not seem to have a hwclock command, so I cannot see the hardware clock's time, but a date command shows that the o/s does run in BST.
What makes you think that? If you are seeing BST on the end of the reported date I think that means that the GMT time is converted to BST for display purposes.
 
Time in Unix / Linux system ("Unix Time") is simply a count of the number of seconds that have passed since 00:00:00 on Thursday, 1 January 1970, this is why you quite often see time stamps like 1397909106 (which is the current time), the 'date' command line takes this 10 digit number and converts it into a readable time / date, however it is the 10 digit number that is used extensively by unix, so it is the 'date' command that is generating the BST time, without it you have 1397909106
 
The hardware clock is in the front panel which is a dedicated low power processor. Whenever the box goes into standby, the Humax software saves the current date and time to the front panel clock and then powers off the main board. The front panel's job is to run the clock, listen for the power on command from a remote control or the front panel button and wake up the main processor ready for a scheduled recording, reminder etc.

The main board doesn't have a real-time-clock (RTC) so when the Humax starts up, the Humax software reads the time back from the front panel and sets the system clock accordingly. If you have completely removed power at any point, the clock will not be current so the front panel will usually show 00:00 and the system date will be January 2000. The Humax software will set the date and time from the broadcast stream in this case (and in any case when the system date is more than a minute off from broadcast time).

Redring has initialisation code to detect the time zone at startup (actually, just whether the daylight saving time flag is set) and then it uses it whenever it has to display the clock. Following power being removed it will display in GMT because the flag was not set when it started up - defaulted to January 2000.

..but a date command shows that the o/s does run in BST.
As Martinliddle has already said, the OS runs in UTC/GMT. It's the date command that is converting the system date to the local timezone based on the value of the TZ environment variable.

Code:
humax# echo $TZ
GMT+0BST,M3.5.0/1,M10.5.0/2
humax# date
Sat Apr 19 18:26:18 BST 2014
humax# TZ=GMT date
Sat Apr 19 17:26:21 GMT 2014
humax# TZ='Asia/Kolkata' date
Sat Apr 19 22:56:23 IST 2014
 
I am used to writing in C++ for RedHat or Centos. If I need the time, I would use the standard o/s functions time(), localtime() and strftime(). In which case I would not need to worry about time zone and daylight saving as (provided that o/s time zone is correctly configured in TZ or /etc/localtime) the function calls will apply the appropriate offsets without any further intervention. This is the same way that standard date and ls commands would handle date-time.
(See http://linux.die.net/man/3/gmtime and http://linux.die.net/man/1/date)

(Maybe this explains the difference in opinion; to me a kernel running to GMT time + an o/s with a configured time zone = an o/s that is operating in local time.)

Sounds like the functions that redring is using are far less time zone aware.
 
I am used to writing in C++ for RedHat or Centos. If I need the time, I would use the standard o/s functions time(), localtime() and strftime().
Those are C library functions that do the necessary conversions based on the configured timezones and are available to redring too. The problem is that the standard Humax software runs in GMT all year round (you'd have to ask Humax why) and redring, unlike most of the custom firmware components, effectively runs within the Humax software and so gmtime() == localtime() all year long too. An additional problem is that the system time is not set when redring starts up - that's done later by the Humax software as I described in the previous post.

The redring startup wrapper uses a small binary (/mod/boot/tzget) which interrogates the front panel to determine the time it is holding and then uses the functions you mention to determine the time zone relating to that timestamp.

Code:
        ...
        /* mtt is the timestamp from the front panel */
 
        setenv("TZ", "GMT+0BST,M3.5.0/1,M10.5.0/2", 1);
        tzset();
        mt = localtime(&mtt);
        strftime(ftime, sizeof(ftime), "%Z", mt);
 
        printf("%s\n", ftime);

That's then used by Redring to determine whether to apply a DST offset when displaying the clock.
 
Back
Top