[mythtv] Bootstrapping DB settings
Wed, 4 Dec 2002 11:10:17 -0500
On Wed, Dec 04, 2002 at 07:05:32AM -0800, Bruce Markey wrote:
> 1) There is a mismatch for codecparams in the 0-7-to-0-8.sql
> file. "type" is included in the primary key but is not
> defined. At first I tried adding it as a not null varchar
> but then I never saw it being set so maybe it doesn't belong
> in the key...
Cut and paste error. Fixed in CVS now.
> 2) Entering the recording settings with empty codecparams
> and recordingprofiles tables causes some weird behavior the
> first couple times through. It seems as if the first time
> a profile is committed, the 13 name/value pairs in
> codecparams have "0" in the profile column while there
> are two rows created in recordingprofiles with id values
> of 1 and 2 with missing data in each row.
> Editing and committing "Custom" a second time adds 13
> new rows in codecparams with a profile value of 1 and
> the "Custom" row then has all fields filled in correctly.
Try dropping the recordingprofiles table and recreating it using the new
0-7-to-0-8.sql script. I think this was happening because the row is
filled in one column at a time, but some of the columns were set to be NOT
NULL. Let me know if this fixes the problem; I can't test it right now.
> 3) Even though the "Finish" button goes back to the list
> of profiles (suggesting you could begin adding another)
> the edited profile doesn't appear to get committed until
> exiting back to the setup menu. Is this the intended
No, this is just the roughness of the implementation. I mean to fix it so
that it commits the changes immediately. It just wasn't obvious to me what
the best way was to do it in Qt fashion. I wanted to get this stuff into
CVS before it diverged any further, to avoid interfering with other work
that is being done right now.
> 4) It looks as if the codecparams table is used as a group
> of name/value pairs but the data seems like it should be
> in rows. Did you consider using the names as columns then
> putting the values in rows for each profile number?
Different codecs have different parameters. Doing it in rows would require
modifying the database every time a new setting or codec was added, and
either having a different table for each codec, or having each row be a
superset of all possible settings for every codec. I think the current
design is preferable.
> Of these, fixing the sql upgrade file is the only thing
> that needs attention before starting to use builds from
Should be done.