[mythtv-users] Deleted recordings in mythweb

[Peter Bennett (cats22)]

On 01/22/2016 05:09 PM, Michael T. Dean wrote:
> On 01/22/2016 04:41 PM, Yianni wrote:
>>> I think some miscommunication, there is in Group Filter but there
>>> isn't in Group View. So you can set Filter to show Deleted, but then
>>> only Deleted!
>>
>> Yes, it's my fault, sorry, I've got the program in Greek and I'm
>> translating "on the fly" which apparently doesn't fly...
>> It's in the Change Group Filter  menu, the first entry when pressing
>> M, anyway. I've changed to English language
>> and now the group is called Deleted, with one entry. Mythweb, shows
>> 246 entries, one up from before.
>
> Can you delete the already-deleted recordings from MythWeb?  Do they
> actually disappear if you do?
>
> What's happening is there's a race condition that can occur when
> deleting (especially large numbers of) recordings and shutting down
> mythbackend (uncleanly), that can result in some recordings getting
> into a limbo state where they're not fully deleted, but they were
> supposed to be, so MythTV ignores them thinking they will be gone
> soon, even though the deletion process was interrupted and nothing is
> working to delete them, anymore.  All of the recordings in this state
> are ones that you've previously deleted, so you can re-delete them
> without problems.
>
> Technically, MythWeb's showing the recordings is a bug in MythWeb.
> However, since it does show them, if you can actually delete them from
> MythWeb, that's probably the best way to clean them up.
>
> Anyone with a large number of these probably got them when they
> upgraded to the version of MythTV that enabled the delete queue
> (Deleted recording group) for everyone.  There was a bug for a couple
> of days in the initial implementation of the patch that resulted in
> all the recordings in the Deleted recording group being immediately
> removed upon upgrade and--most likely--this resulted in people and/or
> process monitors thinking MythTV was locked up, which probably
> resulted in a lot of processes getting killed and leaving these broken
> recordings.
>
> And, FWIW, to the best of my knowledge, this race condition won't
> occur (or at least, the time period where it can occur is so much
> smaller that it will nearly never occur) for users who enable:
>
> Delete files slowly
> Some filesystems use a lot of resources when deleting large files. If
> enabled, this option makes MythTV delete files slowly on this backend
> to lessen the impact.
>
> So, to prevent more zombie recordings, anyone can enable that in
> mythtv-setup's General settings--whether you need it or not. There's
> not really a down side to enabling it, unless your backend happens to
> use NFS or CIFS to access its MythTV storage (in which case, you
> probably don't want it enabled).
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

Going back a few years, the upgrade from 0.24 to 0.25 was problematic
because the setting of "0" days for deletion changed from meaning "keep
as long as possible" to meaning "delete immediately". This combined with
a bug where the backend ran out of database connections when deleting a
lot of files at one time, and a permissions error where it could not
delete its files, left a bunch of deleted recordings in limbo.

The solution was -

To see if this is the case run this
select deletepending, recgroup, count(*) from recorded group by
deletepending, recgroup;

If you see recordings in Deleted group with deletepending non zero, run this
UPDATE recorded SET deletepending = 0 where recgroup = 'Deleted';

Peter