mythtv trunk timezone related boot error

[pleeke]

Hi,

I've built a mythtv-trunk version of minimyth (rev4507). When starting mythfrontend from a telnet session I see this error;

Code: Select all

2009-03-24 22:14:14.344 Time zone settings on the master backend differ from those on this system.
2009-03-24 22:14:14.344 Detected time zone settings:
    Master: Zone ID: 'Europe/London', UTC Offset: '0', Current Time: '2009-03-24T22:14:14'
     Local: Zone ID: 'Europe/Belfast', UTC Offset: '0', Current Time: '2009-03-24T22:14:13'

2009-03-24 22:14:14.344 The time and/or time zone settings on this system do not match those in use on the master backend. Please ensure all frontend and backend systems are configured to use the same time zone and have the current time properly set.
2009-03-24 22:14:14.344 Unable to run with invalid time settings. Exiting.

I have my dhcp server to allocate Europe/London and have also tried adding MM_DHCP_TCODE='Europe/London' to the minimyth.conf file.



MM seems to think its ok, /etc/udhcpd.conf shows;

MM_DHCP_DOMAIN_NAME=''
MM_DHCP_DOMAIN_NAME_SERVERS=''
MM_DHCP_HOST_NAME=''
MM_DHCP_LOG_SERVERS=''
MM_DHCP_NTP_SERVERS=''
MM_DHCP_TCODE='Europe/London'


but mythfrontend thinks there is a problem. Maybe an issue with mythfrontend more than MM?


Any ideas? I'll keep looking tomorrow to see if I can figure it out.

Thanks
Peter

[Pablo]

Different Linux distributions use different methods for configuring the timezone. It appears that the heuristics that MythTV uses to determine the time zone used the computer are not perfect. While the heuristics should work were the distributions on all MythTV boxes using the same distributions, they may not work when the distributions differ.

When no other heuristic works, MythTV compares the contents /etc/localtime with files in /usr/share/zoneinfo. Unfortunately, because the Europe/Belfast and Europe/London files are identical, this method can be problematic.

I have changed MiniMyth so that /etc/localtime is a link to the file in /usr/share/zoneinfo rather than a copy of the file. This should fix the problem. It has been committed to SVN and will be in the next test build.

[pleeke]

Pablo,

works fine now.

Thanks
Peter