[mythtv] Key mapping for BOOKMARK

Michael T. Dean mtdean at thirdcontact.com
Sat Mar 17 21:29:22 UTC 2018

On 03/17/2018 12:51 PM, Peter Bennett wrote:
> On 03/17/2018 12:59 AM, Michael T. Dean wrote:
>> Looks good, but why not do the part that tests to see if they're 
>> currently using the SELECT keys for bookmarks as a one-time DB update 
>> instead of having to do it every startup?  It would be something like 
>> the attached (totally untested) patch.  The main benefit of this 
>> approach is that it doesn't clutter up tv_play.cpp with code we'll 
>> always wonder how long we need to keep and it takes care of all the 
>> hosts in the system at one time and is done forever.  Then, you can 
>> just use the new-host default keylists in the REG_KEY lines in 
>> tv_play.cpp for SETBOOKMARK and TOGGLEBOOKMARK (which would be the 
>> empty string, "").
> Hi Mike
> I did consider using a database schema upgrade for this. These are my 
> thoughts.
> I think there are a number of users who run master. They will be 
> forced to upgrade all frontends and backends when the code gets 
> installed. This may be a penalty of running master, but I think it 
> should be avoided when possible.
> Doing it in a database upgrade is a lot more code because you have to 
> loop through all frontends, also cannot use the global routines that 
> get a setting value or the existing routines that get key assignments. 
> More testing would be needed. There are 82 lines or more of code 
> against 16 lines of code in the way I have it.
> I think the sample code you provided needs a different control loop - 
> there may be frontends that do not have a settings entry for 
> AltClearSavedPosition because the user never went into that setting page.

You don't need to go to that page. It's written automatically on 
frontend first startup (or, technically, first startup when there's a 
valid, proper-schema-version database to which mythfrontend first 
connected).  There are only a few settings that don't get written 
automatically--and they're ones buried inside "only applies if some 
other setting has some non-default value" code.

> If I do it as it is in my patch I can add a comment in the database 
> upgrade stuff saying that when consolidating database version 1348 
> into initialize you can remove a certain 16 lines of code and where to 
> find them.

That would work, too.

> Anyway, I will do it which ever way you recommend. Do you recommend 
> changing it to a schema upgrade?

So, yeah, you can do it the way you have and the DB update can be added 
later and the tv_play code simplified then.


More information about the mythtv-dev mailing list