Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747

Index | Next | Previous | View Threaded

gnassas at mac

Jun 7, 2012, 3:26 PM

Post #1 of 17 (821 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747

On 2012-06-07, at 5:31 PM, noreply [at] mythtv (Git Repo Owner) wrote:

> IMPORTANT NOTE: For the two latter changes to work properly, time zone
> data must be loaded into the MySQL server. If that is not done, any
> recording rules using them will not match any programs.

How would one know if this is the case?

- George
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Jun 7, 2012, 3:43 PM

Post #2 of 17 (814 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/07/2012 06:26 PM, George Nassas wrote:
> On 2012-06-07, at 5:31 PM, noreply [at] mythtv (Git Repo Owner) wrote:
>
>> IMPORTANT NOTE: For the two latter changes to work properly, time zone
>> data must be loaded into the MySQL server. If that is not done, any
>> recording rules using them will not match any programs.
> How would one know if this is the case?

Easiest way is to just try to use a function that relies on it, such as:

SELECT CONVERT_TZ('2012-06-07 12:00:00', 'GMT', 'America/New_York');

If you get NULL, you don't have the zone info loaded, and need to follow
instructions at:
http://dev.mysql.com/doc/refman/5.0/en/time-zone-support.html
(specifically the part about mysql_tzinfo_to_sql , which references
http://dev.mysql.com/doc/refman/5.0/en/mysql-tzinfo-to-sql.html ).

I don't know if most distros load time zone data for users, but MySQL's
installation does not load it by default (only creates empty tables).
So, unless the distro did it for you, you don't have the data.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

keemllib at gmail

Jun 7, 2012, 7:56 PM

Post #3 of 17 (812 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/07/2012 05:43 PM, Michael T. Dean wrote:
> On 06/07/2012 06:26 PM, George Nassas wrote:
>> On 2012-06-07, at 5:31 PM, noreply [at] mythtv (Git Repo Owner) wrote:
>>
>>> IMPORTANT NOTE: For the two latter changes to work properly, time zone
>>> data must be loaded into the MySQL server. If that is not done, any
>>> recording rules using them will not match any programs.
>> How would one know if this is the case?
>
> Easiest way is to just try to use a function that relies on it, such as:
>
> SELECT CONVERT_TZ('2012-06-07 12:00:00', 'GMT', 'America/New_York');
...

Thanks for that info. So I'll reciprocate (retaliate) with:

http://www.mythtv.org/wiki/MySQL_Time_Zone_Tables

And, added a note to the 0.26 release notes, even though its
commented out.

--
Bill
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Jun 7, 2012, 8:57 PM

Post #4 of 17 (809 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 2012-06-07, at 10:56 PM, Bill Meek wrote:

>> Easiest way is to just try to use a function that relies on it, such as:
>>
>> SELECT CONVERT_TZ('2012-06-07 12:00:00', 'GMT', 'America/New_York');
>
> Thanks for that info. So I'll reciprocate (retaliate) with:

Wow, I step out for the day and come back to two great responses. Thanks guys!

- George

david at istwok

Jun 7, 2012, 9:05 PM

Post #5 of 17 (819 views)
Permalink

Re: mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On Thu, Jun 07, 2012 at 09:56:09PM -0500, Bill Meek wrote:
> On 06/07/2012 05:43 PM, Michael T. Dean wrote:
> >On 06/07/2012 06:26 PM, George Nassas wrote:
> >>On 2012-06-07, at 5:31 PM, noreply [at] mythtv (Git Repo Owner) wrote:
> >>
> >>>IMPORTANT NOTE: For the two latter changes to work properly, time zone
> >>>data must be loaded into the MySQL server. If that is not done, any
> >>>recording rules using them will not match any programs.
> >>How would one know if this is the case?
> >
> >Easiest way is to just try to use a function that relies on it, such as:
> >
> >SELECT CONVERT_TZ('2012-06-07 12:00:00', 'GMT', 'America/New_York');
> ...

Or if you want a way to check using only mythfrontend... Choose a
program in prime time that is going to be recorded, go into the rule
editor, turn on the "Prime time" filter and then "Preview" the changes.
If nothing changes, you have working time zone support.

> Thanks for that info. So I'll reciprocate (retaliate) with:
>
> http://www.mythtv.org/wiki/MySQL_Time_Zone_Tables
>
> And, added a note to the 0.26 release notes, even though its
> commented out.

Nice.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

nigel at ind

Jun 7, 2012, 11:30 PM

Post #6 of 17 (804 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 08/06/2012, at 8:43 AM, Michael T. Dean wrote:

> SELECT CONVERT_TZ('2012-06-07 12:00:00', 'GMT', 'America/New_York');

100% of my current machines (two KnoppMyth, two OS X)
return NULL. Which is my problem, but I'm thinking that,
for the sake of users, the schema upgrade code
needs to test+fail before doing its work?

--
Nigel Pearson, nigel [at] ind| "I am one in
Telstra Net. Eng., Sydney, Australia | a krillion!"
Office: 8576 5449 Fax: 9298 9033 | Will the Krill.
Mobile: 0408 664435 Home: 9792 6998 | Happy Feet 2.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Jun 8, 2012, 3:30 AM

Post #7 of 17 (801 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/08/2012 02:30 AM, Nigel Pearson wrote:
> On 08/06/2012, at 8:43 AM, Michael T. Dean wrote:
>
>> SELECT CONVERT_TZ('2012-06-07 12:00:00', 'GMT', 'America/New_York');
>
> 100% of my current machines (two KnoppMyth, two OS X)
> return NULL. Which is my problem, but I'm thinking that,
> for the sake of users, the schema upgrade code
> needs to test+fail before doing its work?

These aren't actually required for the schema upgrade, but for normal
MythTV program use--specifically use of certain types of custom
recording rules.

We could make this a master-backend startup test, perhaps, and exit if
the test fails?

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

nigel at ind

Jun 11, 2012, 9:49 PM

Post #8 of 17 (774 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/08/2012 02:30 AM, Nigel Pearson wrote:
> for the sake of users, the schema upgrade code
> needs to test+fail before doing its work?

On 08/06/2012, at 8:30 PM, Michael T. Dean wrote:
> These aren't actually required for the schema upgrade

True, but if a user runs the upgrade, and afterwards
part of their system doesn't work as before,
we will be getting bug reports,
pointing them to Bill's Wiki page, et c.

Logging a message from the master backend is tidy,
but mostly invisible for the average user who would
only look after some recordings fail?

That's why I reckon an upgrade failure is better.

--
Nigel Pearson, nigel [at] ind| 4 8 |
Telstra Net. Eng., Sydney, Australia | 15 16 |
Office: 8576 5449 Fax: 9298 9033 | 23 42 |
Mobile: 0408 664435 Home: 9792 6998 | Lost |

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Jun 12, 2012, 4:10 AM

Post #9 of 17 (768 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/12/2012 12:49 AM, Nigel Pearson wrote:
>
> On 06/08/2012 02:30 AM, Nigel Pearson wrote:
>> for the sake of users, the schema upgrade code
>> needs to test+fail before doing its work?
>
>
> On 08/06/2012, at 8:30 PM, Michael T. Dean wrote:
>> These aren't actually required for the schema upgrade
> True, but if a user runs the upgrade, and afterwards
> part of their system doesn't work as before,
> we will be getting bug reports,
> pointing them to Bill's Wiki page, et c.
>
>
> Logging a message from the master backend is tidy,
> but mostly invisible for the average user who would
> only look after some recordings fail?
>
> That's why I reckon an upgrade failure is better.

Yeah, good point. It's now looking like some of the final conversion
stuff for the recording rules that David E is working on will require a
DB update that requires time-zone data inside the database, so at that
point, we'll have to put in the check on DB upgrade.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

dbadia at gmail

Jun 12, 2012, 6:02 AM

Post #10 of 17 (772 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

Is it safe to make the mysql timezone change while running. 25 or should I
until I upgrade?

Thanks
Dave

mtdean at thirdcontact

Jun 12, 2012, 6:14 AM

Post #11 of 17 (769 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/12/2012 09:02 AM, Dave Badia wrote:
>
> Is it safe to make the mysql timezone change while running. 25 or
> should I until I upgrade?
>

Yes. Definitely safe. It won't hurt anything (and even if your package
manager re-runs it after upgrade, it won't hurt--it truncates, then
populates the time_zone* tables). The only effect will be the use of a
few more megabytes of HDD space for the MySQL database data files.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

jyavenard at gmail

Jun 12, 2012, 7:54 AM

Post #12 of 17 (765 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

Hi

On Tuesday, 12 June 2012, Michael T. Dean wrote:

>
>>
> Yeah, good point. It's now looking like some of the final conversion
> stuff for the recording rules that David E is working on will require a DB
> update that requires time-zone data inside the database, so at that point,
> we'll have to put in the check on DB upgrade.
>
>
IMHO, having to set a new local time zone setting in the database,
completely defeat the purpose of doing everything in UTC...
All you've done is shift the problem elsewhere...

If moving to UTC internally, means you have to fail if a time zone isn't
set, why bother with UTC in the first place?

david at istwok

Jun 12, 2012, 8:06 AM

Post #13 of 17 (761 views)
Permalink

Re: mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On Wed, Jun 13, 2012 at 12:54:35AM +1000, Jean-Yves Avenard wrote:
> On Tuesday, 12 June 2012, Michael T. Dean wrote:
> > Yeah, good point. It's now looking like some of the final conversion
> > stuff for the recording rules that David E is working on will require a DB
> > update that requires time-zone data inside the database, so at that point,
> > we'll have to put in the check on DB upgrade.
> >
> >
> IMHO, having to set a new local time zone setting in the database,
> completely defeat the purpose of doing everything in UTC...
> All you've done is shift the problem elsewhere...
>
> If moving to UTC internally, means you have to fail if a time zone isn't
> set, why bother with UTC in the first place?

You don't have to set the local time zone in the database. It will use
whatever is already configured for the system. What you have to do is
load the time zone data into the database so it can translate between
local time and UTC.

This isn't a slight on all the hard work done by Daniel, but yes what
we have mostly done is trade one problem for another.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Jun 12, 2012, 8:13 AM

Post #14 of 17 (760 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/12/2012 10:54 AM, Jean-Yves Avenard wrote:
> On Tuesday, 12 June 2012, Michael T. Dean wrote:
>> Yeah, good point. It's now looking like some of the final conversion
>> stuff for the recording rules that David E is working on will require a DB
>> update that requires time-zone data inside the database, so at that point,
>> we'll have to put in the check on DB upgrade.
> IMHO, having to set a new local time zone setting in the database,
> completely defeat the purpose of doing everything in UTC...
> All you've done is shift the problem elsewhere...
>
> If moving to UTC internally, means you have to fail if a time zone isn't
> set, why bother with UTC in the first place?

You don't have to actually set the time zone in MySQL--MySQL will pick
that up from the local system's time zone setting. You just have to
load the time zone rules from the Olsen database in /usr/share/zoneinfo
into tables in MySQL so that MySQL can do conversions across time
zones. Running

mysql_tzinfo_to_sql /usr/share/zoneinfo > /tmp/tzinfo.sql

will allow you to see exactly what it's doing.

This is something that doesn't require any specific configuration, and
probably should be done as part of a normal MySQL package install, but
it seems that either there aren't many other applications that require
the data in MySQL or each application's package handles the loading
itself. I have no idea why the MySQL developers decided not to load the
data automatically when you run mysql_install_db or something (at least
on *nix systems with zoneinfo DB on them).

Mike

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gary.buhrmaster at gmail

Jun 12, 2012, 12:59 PM

Post #15 of 17 (757 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On Tue, Jun 12, 2012 at 3:13 PM, Michael T. Dean
<mtdean [at] thirdcontact> wrote:
> ... �I have
> no idea why the MySQL developers decided not to load the data automatically
> when you run mysql_install_db or something (at least on *nix systems with
> zoneinfo DB on them).

Or use system functions (at least as a default; local overrides
may be useful/allowable) rather than creating yet another place to
update (when the timezone database changes). As a database
company, they should know that having more than one definitive
database of record means you actually have none. But I guess
I am being unrealistic.

Gary
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

newbury at mandamus

Jun 12, 2012, 2:16 PM

Post #16 of 17 (758 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/12/2012 11:13 AM, Michael T. Dean wrote:
> On 06/12/2012 10:54 AM, Jean-Yves Avenard wrote:
>> On Tuesday, 12 June 2012, Michael T. Dean wrote:
>>> Yeah, good point. It's now looking like some of the final conversion
>>> stuff for the recording rules that David E is working on will require
>>> a DB
>>> update that requires time-zone data inside the database, so at that
>>> point,
>>> we'll have to put in the check on DB upgrade.
>> IMHO, having to set a new local time zone setting in the database,
>> completely defeat the purpose of doing everything in UTC...
>> All you've done is shift the problem elsewhere...
>>
>> If moving to UTC internally, means you have to fail if a time zone isn't
>> set, why bother with UTC in the first place?
>
> You don't have to actually set the time zone in MySQL--MySQL will pick
> that up from the local system's time zone setting. You just have to load
> the time zone rules from the Olsen database in /usr/share/zoneinfo into
> tables in MySQL so that MySQL can do conversions across time zones. Running
>
> mysql_tzinfo_to_sql /usr/share/zoneinfo > /tmp/tzinfo.sql
>
> will allow you to see exactly what it's doing.
>
> This is something that doesn't require any specific configuration, and
> probably should be done as part of a normal MySQL package install, but
> it seems that either there aren't many other applications that require
> the data in MySQL or each application's package handles the loading
> itself. I have no idea why the MySQL developers decided not to load the
> data automatically when you run mysql_install_db or something (at least
> on *nix systems with zoneinfo DB on them).

Then loading the zoneinfo tables needs to be done in the mysql setup (
or in mc.sql for trunk installs), Problem is that the 'usual' route of
"mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -ppassword
mysql" requires entry of the mysql root password.

So it cannot be done in mysql_prepare_db as ExecStartPre in mysql.service.

This *is* messy. And there seems to be no way around it.

Geoff

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

keemllib at gmail

Jun 12, 2012, 2:49 PM

Post #17 of 17 (763 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747 [In reply to]

On 06/12/2012 04:16 PM, R. G. Newbury wrote:
...
>
> Then loading the zoneinfo tables needs to be done in the mysql setup ( or in mc.sql for trunk installs), Problem is that the 'usual' route of
> "mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -ppassword mysql" requires entry of the mysql root password.
>
> So it cannot be done in mysql_prepare_db as ExecStartPre in mysql.service.
>
> This *is* messy. And there seems to be no way around it.
...

Hi;

Speaking only for *buntu, the following could live in the upstart
file /etc/init/mysql.conf. That way if the zoneinfo changed, at
least if would be updated the next time mysql started.

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql --defaults-file=/etc/mysql/debian.cnf mysql

I don't know if other distributions have access to a similar maintenance password.

--
Bill
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads