[mythtv-users] SD programid too long?

[Michael T. Dean]

On 09/26/2007 08:30 PM, Cory Papenfuss wrote:
>  	So, for the record, what's the approved, correct way to create a 
> new myth machine with a newer version of mythtv and import ones previous 
> recordings?

1) Backup "old-version" DB on old machine
2) Import entire old-version DB on new machine
3) Run mythtv-setup or mythbackend to update the old-version DB to the
new-version DB  (Running mythfrontend would also work, but really, you
should consider running mythtv-setup after every upgrade, and generally,
you should have mythbackend running before starting mythfrontend, so I'm
ignoring using mythfrontend as an "approved" upgrade approach.)

Note that you should /not/ use mc.sql to create a new DB.  You should
/not/ run mythtv-setup, mythbackend, or mythfrontend on the new machine
before importing the old-version DB into the new machine's DB.

>   Am I paranoid about hidden settings/features that might not 
> be set to optimal values on a new version upgraded from a crusty old DB 
> that's been around for 4 years and 6-8 major revisions?  :)

There are 2 approaches for dealing with this.  Remember, that no matter
what, the "partial import" must be done from exact-same-version DB
schema to exact-same-version DB schema.

The general idea is to do the partial import, a.k.a. "spring cleaning" (
http://mythtv.org/docs/mythtv-HOWTO-23.html#ss23.7 ), using the
old-version DB and the old MythTV install, then doing a full backup to
import on the new machine as above.  See
http://www.gossamer-threads.com/lists/mythtv/users/223625#223625 for
more details.

The other approach is to upgrade the DB as above, then do a spring
cleaning of the upgraded DB.  (In short, backup upgraded DB, drop DB,
execute mc.sql, run mythtv-setup, exit mythtv-setup, do partial import,
run mythtv-setup and configure, run mythbackend, run mythfrontend and
configure.)

I'd use the first approach if I was concerned about the
quality/correctness of the old DB/data.  I'd use the second approach if
I'm relatively certain that the old DB/data is correct (i.e. everything
works on the old version) and just want to remove "deprecated" settings
values, etc, because of an O.C. desire for DB "cleanliness".

Note that you /can/ do both--start with the first approach to get a
new-version DB, then do a spring-cleaning of the new-version DB.  This
would be useful for those who don't trust their old-version DB/data
/and/ who are O.C.

I should probably write up both of these procedures in detail for Robert
as it seems that a /lot/ of people think that they can do 23.7 across DB
versions...

Mike