[mythtv-users] mythfilldatabase not logging

[Michael T. Dean]

On 02/11/2016 07:01 PM, Jerome Yuzyk wrote:
>
> On Thursday, February 11, 2016 03:40:49 PM Michael T. Dean wrote:
>
> > > Ah OK, thanks. There seem to be a lot of these left-overs. Why 
> weren't
>
> > > they removed during a DB conversion?
>
> > >
>
> >
>
> > Because there's no need. They take up virtually no space in the
>
> > database (a whole host's settings take an incremental 4-8kB or less on
>
> > disk compared to just table structure and indices--and most of that is
>
> > because of disk block size--even on my system where my host's settings
>
> > have persisted since I started with MythTV in 0.14) and since we have a
>
> > nice* UI which shows only those settings in use (as well as
>
> > user-friendly names for them and descriptions of what they're for and
>
> > how they work), old settings don't get in the way. So, we've never
>
> > really removed any no-longer-in-use settings values, other than a few
>
> > odd ones.
>
> Not so much a question of space savings for me, but cruft 
> accumulation. All the database upgrades/updates I've ever done for 
> work have included removal of obsolete columns.
>

Yes, we always remove obsolete columns.  Obsolete settings rows, 
however, aren't worth the trouble. ;)

> > Or, from another perspective, removing a setting name from the database
>
> > generally doesn't warrant all the delay (backup, prompt, upgrade 
> times X
>
> > number of users) and danger (all hosts need to be upgraded for the new
>
> > DB schema version, etc) of a DB update.
>
> I thought a BE schema update required FEs to update anyway. But, I've 
> never run a separate FE.
>

Right, that's the the thing--everything has to be updated when there's a 
DB update.  This can be really annoying for developers or any users who 
follow master when some "unimportant" change is made as a DB update and 
prevents them from doing a quick test before commit or a "quick upgrade 
of this part before my recordings start and finish the upgrade tomorrow" 
type thing.

> > * By some definitions of nice, at least. If nothing else, it's much
>
> > better than the MythWeb/mysql "properties" view of the settings and
>
> > values. Note, too, that some of the settings do exactly opposite what
>
> > their names say or work very differently from how their names imply, so
>
> > it's always best to use mythfrontend settings or mythtv-setup for
>
> > setting values for your settings.
>
> Old habits die hard... I've never used the other bits of the FE UI so 
> much in the 9 years before 0.27 as I have in the 6 months since. And I 
> seem to always get an idea to change something that requires 
> mythtv-setup while I have a pack of recordings in progress or soon to 
> start. :( Now I make notes to myself.
>

Yeah, well, that's a whole other thing.  It used to be that any settings 
that required a backend/MythTV-system restart were in mythtv-setup and 
any settings that didn't require a restart were in the frontend settings 
editor (even if they were settings that affected the backend).  However, 
some users complained that, "All backend settings should be in 
mythtv-setup, where it makes sense. Duh!," so now you get to run 
mythtv-setup and restart your backend to change all sorts of settings 
values--like mythfilldatabase path/args--that you used to be able to 
change from the frontend settings editor while the backend and frontends 
were running/recording/whatever.

0.22:
https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythfrontend/globalsettings.cpp?h=fixes%2F0.21#n3976

0.23:
https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythtv-setup/backendsettings.cpp?h=fixes%2F0.23#n884

(and it remains the same in 0.27/master).  But, hey, I'm not 
complaining.  After all, the customer^H^H^H^H^H^H^H^Huser is always 
right, amiright?  Or, maybe I should say, "You* asked for it.  You got 
it.  Backend restarts!"  I'm only mentioning this because I'm a student 
of (MythTV) history.

Mike

*Where, "You," means the generic, "You," not you.