[mythtv-users] adding recordings to the database?

[Stephen Worthington]

On Wed, 31 Jan 2018 03:47:01 -0800, you wrote:

>James Abernathy <jfabernathy at gmail.com> says:
>> So I ran the find_orphans.py script just to see what it would find,
>> expecting nothing and I found a good bit of stuff.
>
>It's surprising what scripts can turn up. A while ago I had a problem
>with drives running out of room for recordings despite the "Extra disk
>space (GB)" setting not being changed; increasing this setting to
>enlarge the safety margin made no difference. One day I ran the
>flush_deleted_recgroup.pl script for a different reason and found many
>more entries being deleted than I expected.
>
>What happened was that a bunch of old, leftover recording entries and
>associated recording files were present in the Deleted recording
>group, although not visible when manually visiting it from Watch
>Recordings. Whatever caused them to be invisible also made them not
>get swept up by the "Time to retain deleted recordings (days)" setting
>(8 days in my case), and find_orphans.py did not find them either.
>
>(A symptom of this problem is the total number of recordings the
>frontend lists in the Change Filter popup for each individual
>recording group—"Default", "Deleted" (if existing), and any others you
>have created—differing from the number of entries in the 'recorded'
>database schema. (Don't use the number of recordings in "All
>Programs"; that excludes those in "Deleted".)
>
>flush_deleted_recgroup.pl almost entirely solved the problem, but
>there were a couple of garbage recording entries lacking associated
>recording files that the script ignored. I used 'touch' to create
>dummy recording files, then reran the script.

Yes, I also had quite a few of those old leftover recordings in the
deleted list.  It was being caused by a bug that has since been fixed.
I believe that once the fix for that bug got installed on your system,
mythbackend would have cleaned up the deleted list properly, but I had
manually already done that.