[mythtv-users] Lost Recordings and Database

[Ken Smith]

Bill Meek wrote:
> On 1/10/23 16:56, Mike Perkins wrote:
>> On 10/01/2023 20:53, Hika van den Hoven wrote:
>>> Hoi Simon,
>>>
>>> Tuesday, January 10, 2023, 9:20:27 PM, you wrote:
>>>
>>>> Nick Morrott <knowledgejunkie at gmail.com> wrote:
>>>
>>>>> The helpful replies so far (especially how this can be achieved using
>>>>> the API) are suggesting how to remove knowledge of the missing
>>>>> recordings from the database so that they may be recorded again in 
>>>>> the
>>>>> future.
>>>>>
>>>>> They do not go as far as creating a recording rule for each missing
>>>>> recording so that they are automatically recorded when next 
>>>>> broadcast.
>>>>> Is this what you are after?
>>>
>>>> I was thinking along the same lines as I have “a few” missing files
>>>> after a self inflicted loss of a recordings directory a few years
>>>> ago. But I’ve never had enough impetus to sit down and create new
>>>> recording rules for them (quite a few were “find and record one
>>>> showing” rules which self-delete after a successful recording).
>>>
>>>> Simon
>>>
>>> I guess you mean "Record this showing" If you select "Record One
>>> showing" the rule stays active and would in theory be able to
>>> rerecord.
>>>
>> Nope. If you schedule, as I do, using mythweb, one of the options is, 
>> indeed, "Find and record one showing of this title."
>>
>
> The attached is old, but it still works. The OP can try it with:
>
>   add_recording_rule.py --host localhost --title='CSI: Vegas'
>
> and it will say what would happen (but do nothing). Adding the
> We Really Mean It switch (--wrmi) will actually create the
> rule.
>
> It uses the Services API and it could be a template for what
> needs to be done here.
>
> These can be selected from the command line:
>
> TYPES = (
>     "Single Record",
>     "Record All",
>     "Record One",
>     "Record Daily",
>     "Record Weekly",
> )
>
> Start with: add_recording_rule.py --help
>
>

Thank you everyone for all these good suggestions. I'll definitely go 
with the API approach instead of direct sql.

Thanks  --- Ken


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.