<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Oct 15, 2018 at 11:59 AM Gary Buhrmaster <<a href="mailto:gary.buhrmaster@gmail.com">gary.buhrmaster@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Oct 15, 2018 at 2:42 PM Richard Shaw <<a href="mailto:hobbes1069@gmail.com" target="_blank">hobbes1069@gmail.com</a>> wrote:<br>
<br>
> 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.<br>
<br>
The first run has to create a large number of new(ish) entries<br>
and relationships for any run using the incremental approaches<br>
of mythfilldatabase and xmltv.  Subsequent runs will tend to<br>
create and/or update fewer entries(*) as long as the details<br>
remain the same on the schedule/program.  Depending on your<br>
DB configs, inserts and updates may take substantially longer<br>
than one might wish(**).  In addition the xmltv grabbers for<br>
Schedules Direct download certain data into caches such that<br>
the subsequent runs can (mostly) reuse that data.  That makes<br>
that first run, which you are typically watching in real time,<br>
seem to take forever and a day, and later runs at least a little<br>
faster.<br></blockquote><div><br></div><div>I didn't actually measure it but the first run seemed to take about 40-45 minutes. Per backend status in mythweb the next run only took about 4.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The memory usage issue is well understood (that was why<br>
--no-allatonce was introduced).  The better fix for the large<br>
memory usage would be a refactor of how mythfilldatabase<br>
reads in and parses the entire xmltv file before starting to<br>
process the data.  At this point, no one has decided to step<br>
up and do that refactor, and as DRAM is cheap, it is not<br>
clear anyone will any time soon (given there are mitigations).<br></blockquote><div><br></div><div>I'm planning to update my desktop which means the combined FE/BE I'm running will eventually have 16GB of memory and a quad core processor so I'll probably just leave it alone for now.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">btw, as far as docs, there is a different set of docs of creating<br>
a new videosource in the post regarding the HDHR Premium<br>
TV offering.  Not sure if they are better (probably not for a<br>
first user), just different.  I agree with Peter, it is *much* easier<br>
to configure the xmltv grabber outside of MythTV given the<br>
(current) need to do some work outside MythTV anyway<br>
due to the way the grabber(s) must configure the<br>
Schedules Direct lineups.  It does not help (regarding docs)<br>
that xmltv setup tends to be close to a one time only thing,<br>
so neither are people motivated to document what they did<br>
(often with many false starts), nor motivated to ever do it<br>
again and again for testing their documentation to share.<br></blockquote><div><br></div><div>Yeah, now that I know what to do it would be easier a second time but the first time using xmltv it was rather confusing. </div><div><br></div><div>I'm still not clear if I needed to do anything in mythtv-setup other than delete all my channels and let mythfilldatabase re-add them. </div><div><br></div><div>Thanks,</div><div>Richard</div></div></div>