[mythtv] Missed recordings caused by EIT guide update

[David Engel]

On Thu, Aug 29, 2019 at 09:52:17PM +0200, Klaas de Waal wrote:
> As discussed, the problem of missed single recordings is caused by the starttime
> of programs being changed by the guide updates from the EIT.
> 
> I am now testing a fix that does the following.
> In addition to updating the starttime in database table program (and in the
> associated tables credits, programrating and programgenres) the starttime
> is now also updated in table record when the program is present there.
> 
> However, there may be a better solution possible.
> The underlying problem, as I understand it, is that the programs, i.e.
> the records in table program, can only be identified by the fields
> chanid plus starttime. This means there is no way to identify a
> program when the starttime of the program can have been changed.

I think you're heading down a rat hole where you're ultimately going
to be trading one problem for another.

It's reasonable to assume that the program with the same title that is
now 1 minute later than before is the same program.  But what if it's
5 minutes later?  Still probably the same.  But what if it's 15, 30 or
60 minutes later?  Maybe EIT provides information to reliably do that.
I don't know since I'm not familiar with it.

As I think your were implying in your followup message,
mythfilldatabase updates the program table differently.  I don't know
that it has the ability to reliably determine that a program slipped
by even 1 minute.

You're also assuming that because the program and related tables are
indexed by chanid and starttime that the scheduler works similarly.
It doesn't.  It actually uses starttime and callsign.  What you
propose would work if there's only one channel on one videsource to
involved.  If there are multiple, matching channels on one or more
videosources, it won't work.

> It is possible to give tables a separate field to be used as the
> primary key, independent of the content of the rest of the record.
> This is done in table record which has field recordid as primary key.
> Same for table capturecard with primary key cardid.
> 
> If the table program would also have a independent primary key then it
> would be possible to refer to programs (records in table program) using
> that key instead of using the starttime. This then makes it possible to
> have a reference to a program in which all fields including the starttime
> can be changed.
> 
> The advantage of the fix currently being tested is that it does not require
> a change in the database schema and that it comprises only a few lines of code.
> Nevertheless, when and if there is a database schema change forthcoming it might
> be a good moment to add a field programidx to table program and to all
> other tables that contain references to table program so that the code
> can be cleaned up.

I think you might be better off using find-one rules with the
this-episode filter enabled.  They are easy to create initially (at
least using mythfrontend) but might need some TLC to better fit the
problems you are trying to solve.

> Or maybe there is a very good reason why not to use a separate primary
> key but use startttime pluls chanid instead. Performance?
> 
> Comments are very much appreciated. In the meantime I keep on testing the fix!
> 
> Cheers,
> Klaas.
> 
> N.B. There is a field programid in table program but that is used
> for other purposes so that fieldname cannot be used for the primary index.
> 
> N.B. The code in programdata.cpp that does the updates is used by
> mythfilldatabase as well as far as I know so anything that works with the
> guide updates from EIT  should work for mythfilldatabase as well.
> 
> N.B. There is no field manualid in table record so I assume the manual records
> are dealt with in another place.

For manual recording rules, record.search is set to "manual" search
and record.recordid is used to match program.manualid.

David
-- 
David Engel
david at istwok.net