<div dir="ltr"><div>Thanks Mike. Yes, my situation was unusual, I had an odd bug last year to do with a sbe and expiring recordings which was happily deleting everything in sight. <br><br>It's been a while since I ran find_orphans.py, I struggled to find a copy of it when I looked the other day but perhaps I didn't look too hard as I usually just compare whats on disk to whats in the mysql tables.<br>
<br></div>ttfn.d<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 June 2013 02:19, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com" target="_blank">mtdean@thirdcontact.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06/17/2013 07:17 PM, David Scammell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
While browsing about myth I happened to be looking at<br>
<a href="http://mbe-address:6544/" target="_blank">http://mbe-address:6544/</a> in the information/backend status area I found<br>
'space used by deleted recordings to have a large amount (100GB+). While no<br>
significant deletes or auto expires were underway.<br>
<br>
With a little poking about in the database I found the deletepending column<br>
of the recordings table had a number of entries with a value of 1, most of<br>
these stretching back to when I had a mythtv bug causing the backend to<br>
delete/expire recordings prematurely and then die, last year.<br>
<br>
I speculate that if a recording is deleted or expired and then the backend<br>
fails before the actual recording and metadata are removed, the file and<br>
recording row will become orphaned but still take up space on disk.<br>
<br>
I guess its possible many people would have one of more files like this, if<br>
your backend has ever failed then its possible. This bit of sql should<br>
show all pending deletes, those in the delete recording group and any<br>
'extras' you may have:<br>
select * from recorded where deletepending=1;<br>
<br>
I ran into the database:<br>
update recorded set deletepending=0 where deletepending=1;<br>
[the where clause may well be unnecessary]<br>
<br>
It did kill my mbe, so I recommend doing this with your backend(s)<br>
shutdown. After restarting I can now see all of the recordings which were<br>
supposedly removed previously while I had the bug last year, these will<br>
shortly expire (being old) and I'll get my space back.<br>
<br>
Perhaps mythbackend should clear this flag on startup, to make the files<br>
re-appear or restart the slow delete process with data from the recorded<br>
table where the flag set. I dunno exactly what the correct behaviour should<br>
be.<br>
<br>
I hope this helps someone else. have fun.<br>
</blockquote>
<br></div></div>
This is a known issue that only happens in unusual circumstances (such as upgrading to 0.26 with the release version instead of the -fixes version that has a fix for a bug that can cause this in some systems with a specific pre-upgrade configuration, or doing very bad things like hard-killing the backend right after deleting a ton of files).<br>
<br>
And, yes, the SQL you issued is a /very/ bad thing to send when (any part of) MythTV is running.<br>
<br>
There will be a workaround for the issue, eventually, but it's not as easy as just resetting the flag on startup. It's on my TODO list, but since this should only happen if people are doing bad things, and since it's likely not that much space wasted on any given affected system, I recommend not worrying about it too much.<br>
<br>
For now, find_orphans.py should be used to clean up any messes, but I'm not sure where the updated version that handles it is.<br>
<br>
Mike<br>
______________________________<u></u>_________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/<u></u>listinfo/mythtv-users</a><br>
</blockquote></div><br></div>