[mythtv-users] Questions on correcting database encoding under Gentoo while still on 0.21-fixes
digitalaudiorock at gmail.com
Tue Nov 3 00:12:02 UTC 2009
On Mon, Nov 2, 2009 at 6:55 PM, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> On 11/02/2009 05:16 PM, Tom Dexter wrote:
>> On Mon, Nov 2, 2009 at 4:04 PM, Michael T. Dean wrote:
>>> On 11/02/2009 03:15 PM, Tom Dexter wrote:
>>>> Thanks! Do you know offhand whether I may have run into problems if I
>>>> didn't change the my.cnf on the frontend? Like I explained above that
>>>> appears to create a situation where connections from the frontend to
>>>> the (newly corrected) backend would have this by default:
>>>> Server characterset: latin1
>>>> Db characterset: latin1
>>>> Client characterset: utf8
>>>> Conn. characterset: utf8
>>>> With the frontend's my.cnf changed the above are all latin1. Would
>>>> missing that have caused an issue, or would data just get properly
>>>> translated and stored? Then again, I guess that would only be an
>>>> issue for anything (if there is in fact any situation) where the
>>>> frontend writes directly to the database.
>>> If you run mythtv 0.21-fixes in that configuration, it will corrupt data.
>>> And, since the backend is not corrupting data, you will end up with the
>>> dreaded "partial corruption."
>>> If you fix mysql on the backend and the upgrade to 0.22-fixes using the
>>> backend host's mythtv-setup of mythbackend, then you'd be fine running
>>> frontend host in any charset configuration (as 0.22 and above properly
>>> Because I wasn't completely sure what you had said you were doing in your
>>> original post, I modified the wiki page to suggest fixing the DB right
>>> before upgrading. If you did change it and have run 0.21-fixes against
>>> fixed DB, you may want to go back to the original backup and either the
>>> original "misconfiguration" of mysqld or just upgrade to 0.22-fixes now.
>> Whoa...I'm really confused now. I did in fact change the my.cnf on
>> both the frontend and backend to ensure all latin1 defaults before
>> using the corrected database. I was curious as to whether missing
>> that frontend part would have caused problems, but I never ran that
>> That should properly ensure that everything is using and writing
>> latin1 shouldn't it? I certainly hope you're not saying I should
>> revert now for some reason, as it would already be a serious mess if I
>> have to (new recordings etc).
> If the connection character set is utf8, MySQL will do conversions of the
> data the frontend is sending to the server and corrupt it since we
> 0.21-fixes and below sends the data in the proper format for storage, not
> the proper format for "interpretation". This is, in fact, the root of the
> problem with a "misconfigured" (meaning, not properly configured for MythTV
> 0.21-fixes and below--not saying that distros are doing things wrong) MySQL
> However, since most (all?) of the "important" data is created by the
> backend(s), this configuration only on a dedicated remote frontend system
> may not have much of an effect (and could be easily be fixed with a partial
> restore--well, as easy as it is to reconfigure all of MythTV and all mythtv
> hosts from scratch).
> (I might be answering the wrong question here, so if so, I apologize. I
> think I'm explaining why I gave the last answer I gave, though, so it may be
> enough for you to figure out the answer to the question you're actually
Yes I think that answers it. All my connections since fixing the
database have been latin1, so I should be ok.
In any case, I decided to find out for myself by writing a php script
that performs all those temp file tests as well as the upgrade itself
that get performed in the 0.22 version of libs/libmythtv/dbcheck.cpp
when upgrading from schema 1214. I ran it on a copy of my mythconverg
(as it stands now after fixing it) on my development machine.
Everything tested an converted fine. No warnings, no failures on
those unique indexes etc etc.
Thanks again for the advice!
More information about the mythtv-users