[mythtv-users] Deleted recordings in mythweb

Michael T. Dean mtdean at thirdcontact.com
Sat Jan 23 21:07:26 UTC 2016


On 01/23/2016 12:53 PM, Peter Bennett (cats22) wrote:
> 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).
>>
> 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".

That was not a problem.  We actually know that when we change the 
meaning of a setting, we need to do the right thing.  The problem was 
that the database update assumed that everyone would have a setting for 
each host stored in their database for this and other related setting.  
However--unlike almost every other setting in MythTV--only some users 
actually had those settings in their databases.  They were only written 
if the user had changed some other setting.  Therefore, the database 
update didn't always do the right thing--until it was updated after only 
a couple of days to take into account the fact that some users didn't 
have the specific settings in their databases.

>   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.

Not exactly--because it can happen whenever, as I've already 
explained--but deleting a huge number of recordings at once meant that 
the race condition was nearly guaranteed to be triggered.

> 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';

Actually, if you do that with any MythTV programs running, you will 
cause problems.

The safe way to take care of these recordings--as we've found in this 
thread--is to use the bug in MythWeb to get the list of Deleted 
recordings and then tell it to delete them.

Mike


More information about the mythtv-users mailing list