[mythtv-users] Can I tell mythfilldatabase not to reschedule?

[Klaas de Waal]

On Sun, 13 Feb 2022 at 11:44, Stephen Worthington <stephen_agent at jsw.gen.nz>
wrote:

> On Sun, 13 Feb 2022 10:55:48 +0100, you wrote:
>
> >Dear all,
> >
> >Since where I live (Belgium) is poorly served by reliable metadata
> >sources I have to use multiple grabbers and do some preprocessing before
> >importing the metadata using mythfilldatabase --xmlfile. That's three
> >mythfilldatabase runs one after the other.
> >
> >After these mythfilldatabase runs I do some postprocessing using sql
> >scripts, and then run mythutil --resched.
> >
> >Some of that postprocessing affects criteria that are used in recording
> >rules, such that certain shows that the raw metadata suggests should be
> >recorded end up not having to be. For example: my postprocessing marks
> >shows I have on DVD or blueray as not to be rerecorded.
> >
> >The trouble is that each mythfilldatabase run also asks the backend to
> >reschedule, and occasionally a recording immediately begins of a show
> >that my postprocessing decides should not be recorded.
> >
> >I would like to avoid that by getting mythfilldatabase not to also
> >reschedule, leaving me to do that at the end of the nightly script. Can
> >this be done?
> >
> >Many thanks, Jan
>
> I do SQL postprocessing too, and I have never found a way to prevent
> mythfilldatabase from rescheduling.  Fortunately, the problem of
> recordings starting immediately is not one I normally get, but it
> would be nice to not have to worry about it.  But I think that would
> require a patch to mythfilldatabase - probably not a difficult one
> though.
>
> Just another command line option would be the way to go probably.
I think that I understand the problem but I suggest creating a Github issue
for this so that it will not be forgotten and that any developer can pick
it up.

Thanks,
Klaas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20220213/0b2d2742/attachment.htm>