[mythtv-users] Mythfrontend crashes with no error after upgrade.

[Michael T. Dean]

On 12/28/2009 12:22 PM, Larry J on his Dell LT wrote:
> Jeremy Young wrote:
>> I upgraded to .22 just this weekend, and was hit with a strange 
>> situation. I've been fighting it for a couple days now. When I 
>> initially upgraded, both the BE and FE complained of being unable to 
>> connect to the database, despite all my efforts to provide them with 
>> the proper login information. I discovered this:
>>
>> http://www.mythtv.org/wiki/Troubleshooting:Mythbackend_will_not_start_after_upgrade 
>>
>>
>> and searched for multiple mysql.txt files, but found only one in my 
>> user/.mythtv directory. I think my issue was separate from that one. 
>> Despite this I upgraded mysql and recreated the mythtv user in mysql, 
>> this seems to have gotten at least the backend to run. It still seems 
>> quite touchy about connecting to the database though.
>>
>> However, now the FE crashes with no explanation. It will go to the 
>> base color screen for the theme that is selected, and then it drops 
>> me to X immediately. I get about 1 second of mythfrontend running, 
>> and then nothing. I can't find anything in the FE logs that explains 
>> why this would be. Is there some other release note/issue that might 
>> be causing this? The front-end worked fine on Wednesday, and nothing 
>> except myth and mysql were upgraded. I can provide logs if necessary 
>> (but honestly I couldn't find anything in it that indicated trouble). 
> Some how I managed to select Boise, ID as the time zone for the front 
> end and  Denver, CO for the backend. My front end refused to run and 
> exhibited the same behavior as you describe. (Flash of frontend, dump 
> to X). Even though these two cities are in the Mountain Time zone,  
> Myth apparently does not recognize this.

No.  America/Boise and America/Denver are in 2 /completely/ different 
time zones:

$ sha1sum /usr/share/zoneinfo/America/{Boise,Denver}
c4ff21fd5a6f39dd6339db18a9bb37884eaa95ec  /usr/share/zoneinfo/America/Boise
d908d688073b30d50b49fd0cebde0e153bd6fc93  /usr/share/zoneinfo/America/Denver

Myth understands time zones /very/ well, and knows that "Mountain Time" 
(both of them :) is a completely different time zone from either of the 
above (and really isn't used anywhere--and hasn't been since the 1800's):

$ sha1sum /usr/share/zoneinfo/MST*
f0aaf026d7e8988f1a21c02f9dbe6b18da66a14d  /usr/share/zoneinfo/MST
09c6d5bba53a1136dda4611046b06c80acea5c1b  /usr/share/zoneinfo/MST7MDT

People seem to assume that just because the current time is the same on 
some number of systems, Myth will work fine.  In truth, Myth needs to 
know the local time at /every/ point in the past, present, and 
future--and all Myth processes need to agree on that local time.  The 
/only/ possible way to do that is to ensure every single process runs in 
the same time zone.  We have decided to use the Olson time zone database 
for determining if any 2 processes are running in the same time zone, 
assuming that accuracy of local time determination since Jan 1, 1970 is 
sufficient for Myth's purposes (though even if not accurate prior to Jan 
1, 1970, processes in the same Olson time zone will agree on the local 
time prior to Jan 1, 1970).

In truth, Myth doesn't care if you set the proper time zone--only that 
all processes are running with the same time zone.

There's far more information on time zones than you likely care to know 
at http://www.twinsun.com/tz/tz-link.htm and 
http://en.wikipedia.org/wiki/Zoneinfo --including information on why 
Denver and Boise have different time zones:

"Each location in the database represents a national region where all 
clocks keeping local time have agreed since 1970."

This means that even though Indiana now uses Daylight Saving Time (like 
most of the rest of the areas that use Eastern time), they are /still/ 
in a different time zone--because for some periods of time since 1970, 
they did things differently from New York City:

$ sha1sum /usr/share/zoneinfo/America/{Indianapolis,New_York}
caa097c032d51d2d654305ea37e16523e47f3c82  
/usr/share/zoneinfo/America/Indianapolis
6e43d0b5a46ed5ba78da5c7e9dcf319b27d769e7  
/usr/share/zoneinfo/America/New_York

The same applies for Arizona.

Or, to see just how much things differ--even inside just the "Mountain 
Time" areas, check out 
http://en.wikipedia.org/wiki/List_of_zoneinfo_time_zones .

I'm not trying to pick at your comment, specifically--I just hear 
similar comments way too often, and don't want people to think that the 
proper implementation is a bug.  I'm just trying to help explain why the 
problem is not that, "Myth apparently does not recognize this."  There's 
actually a very valid reason for the rules Myth applies to time zones, 
and Myth happens to do understand those rules better than people do.

If anyone is truly bothered by this, feel free to waste a huge amount of 
time doing a series of many, many, many patches for 
http://svn.mythtv.org/trac/ticket/5853 .  I'm not saying that task isn't 
worth doing--just that we currently have a lot of bugs can affect people 
all year long.  The only issue we currently have with time (as reported 
in #5853) can only potentially have an effect on users for 2 hours per 
year (and only if the user is in an area that observes DST and only if 
the user has a recording scheduled that straddles the ambiguous time 
during the switch)--and, since it's easy enough to use a recording rule 
override with appropriate start early/end late to ensure you get the 
whole recording (and can even cut the extra garbage after recording), 
fixing that issue is /very/ low on my list of priorities.  I see this 
being something we complete for version 1.0--or perhaps 11.0.

> So Boise on both or Denver on both seems to have fixed the problem.

Exactly--and a very good point to make.  MythTV 0.22+ now requires that 
all processes (on all hosts) operate with the same time zone identifier 
(meaning that the rules for the flow of local time should be identical 
in all processes--assuming a properly updated zoneinfo DB).

Also, FWIW, (in response to the OP's comment), if it is an invalid time 
zone configuration, there's plenty of explanation at the bottom of the 
mythfrontend log or mythfrontend output.

So, Jeremy, please check your log output.

Mike

***This confusion about what exactly a time zone is and which area of 
the world is in which time zone is why, IMHO, time zones are an 
anachronism of the Rail age, and I'd rather just make a lunch date for 
5:00pm or a dinner date at 11:00pm.