[mythtv-users] Converting from DD to xmltv

[Gary Buhrmaster]

On Mon, Oct 15, 2018 at 2:42 PM Richard Shaw <hobbes1069 at gmail.com> wrote:

> Thanks, I'll take a look but subsequent runs seem to complete quickly. I think it was just the initial loading of all the data.

The first run has to create a large number of new(ish) entries
and relationships for any run using the incremental approaches
of mythfilldatabase and xmltv.  Subsequent runs will tend to
create and/or update fewer entries(*) as long as the details
remain the same on the schedule/program.  Depending on your
DB configs, inserts and updates may take substantially longer
than one might wish(**).  In addition the xmltv grabbers for
Schedules Direct download certain data into caches such that
the subsequent runs can (mostly) reuse that data.  That makes
that first run, which you are typically watching in real time,
seem to take forever and a day, and later runs at least a little
faster.

The memory usage issue is well understood (that was why
--no-allatonce was introduced).  The better fix for the large
memory usage would be a refactor of how mythfilldatabase
reads in and parses the entire xmltv file before starting to
process the data.  At this point, no one has decided to step
up and do that refactor, and as DRAM is cheap, it is not
clear anyone will any time soon (given there are mitigations).

btw, as far as docs, there is a different set of docs of creating
a new videosource in the post regarding the HDHR Premium
TV offering.  Not sure if they are better (probably not for a
first user), just different.  I agree with Peter, it is *much* easier
to configure the xmltv grabber outside of MythTV given the
(current) need to do some work outside MythTV anyway
due to the way the grabber(s) must configure the
Schedules Direct lineups.  It does not help (regarding docs)
that xmltv setup tends to be close to a one time only thing,
so neither are people motivated to document what they did
(often with many false starts), nor motivated to ever do it
again and again for testing their documentation to share.



(*) Due to the way mythfilldatabase does certain post-processing
it marks some episodes as new/old/repeats outside of the (I
think I remember) the 14 day period (14 days can be adjusted
in some tlv entry as I recall, but does not address all the changes
that mythfilldatabase performs) regardless of the source data, resulting
in the schedules further out being updated every run because they
have been adjusted by mythfilldatabase (and are now "different").

(**) Certain types of DB configs can trade off performance for
reliability.  Choose wisely.