[mythtv-users] HELP! Really odd stuff with old deleted recordings and find_orphans.py

[Tom Dexter]

On 10/29/18, Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:
> On Sun, 28 Oct 2018 23:11:32 -0400, you wrote:
>
>>On 10/28/18, Mark Perkins <perkins1724 at hotmail.com> wrote:
>>>
>>>
>>> On 29 October 2018 11:53:47 am Tom Dexter <digitalaudiorock at gmail.com>
>>> wrote:
>>>
>>> My understanding is that is expected behaviour. find_orphans.py just
>>> asks
>>> mythtv to do the delete. mythtv won't delete the metadata unless it can
>>> find the file.
>>>
>>> IIRC just go to FE recordings screen, change group filter to "Deleted",
>>> select All Programmes, menu, add this group to playlist, menu, playlist
>>> options, delete. Will get some sort of 'are you really REALLY sure' type
>>> message, I don't recall wording.
>>>
>>>
>>
>>Thanks! Looks like this might have gotten things straightened out. I'm
>>still a little confused as to your first paragraph, as the whole point
>>of that option #1 in find_orphans.py is to delete programs with
>>missing files. What you're saying seems to imply that that would never
>>work(?). I had originally deleted the programs in mythweb anyway.
>>
>>That aside, I tried what you explained about deleting items in the
>>Deleted group using a playlist. There were 84 entries in the Deleted
>>group. For some reason when I added that to the playlist it only
>>wanted to add 74 of them...not sure why. I deleted the other 10 one at
>>a time. Each one warned me that the file was missing too.
>>
>>Very confusing behavior...I'm still a little confused on all that.
>>I've had cases where there were missing files form tuner failures and
>>don't recall ever having things stuck out there like I had here. Maybe
>>that's because I've always just deleted those from the recordings
>>screen.
>>
>>Thanks again!
>>Tom
>
> This is how I understand MythTV currently does things.
>
> When you delete something from MythTV, it is not actually deleted, but
> instead is queued to be deleted later.  The "later" depends on your
> settings.  With the default settings, I believe it takes up to 20
> minutes before it will actually be deleted ("expired" in terms of what
> log message you will see).  Some available options will never actually
> do the delete until there is no spare space for a recording.  Until
> the "deleted" recordings get "expired", they can be undeleted.  To see
> the "deleted" recordings, you change the group filter to "Deleted".
> From the "Deleted" group, if you then delete something, it will be
> "expired" immediately - it will really be deleted.
>
> The other half of your problem is that things on the "Deleted" queue
> will not be deleted if there is a problem with them.  So if an error
> happens when a normal "expire" operation is done on them, they are not
> actually deleted and remain queued for deletion.  And at some later
> time there will be another attempt to "expire" them, and that will
> fail again.  In your case, the fact that there are no recording files
> for the recording causes the normal "expire" attempts to fail.
> However, when you manually select things from the "Deleted" group to
> be deleted again, that causes a real deletion to happen immediately,
> which does not fail if the recording file is not present.
>
> The way find_orphans.py works, if you tell it to delete all recordings
> where there is no recording file, it will tell MythTV to do exactly
> that.  However, where there are many recordings to be deleted, that
> results in a queue of recordings that MythTV will "expire" in order,
> and it takes its time doing it.  So if you run find_orphans.py again,
> you often find that things you have told it to delete are still there.
> But if you wait long enough, the "expire" queue will get processed
> completely and everything will be gone.  It works the same way when
> you delete lots of things from the Deleted group - if you exit from
> the Deleted group and go back into it, you may well see some of the
> things you have just deleted are still there.  But if you give it long
> enough, they will eventually disappear.  Unless mythbackend gets shut
> down, especially if a bad shut down like a power failure occurs - I
> think the expire queue is held in RAM only, so does not survive a shut
> down.

Thanks Stephen! Great explanation. If it comes up again I think I'll
be much less confused as to what's going on.

Tom