<p>Hi all,</p>
<p>While browsing about myth I happened to be looking at <a href="http://mbe-address:6544/">http://mbe-address:6544/</a> in the information/backend status area I found &#39;space used by deleted recordings to have a large amount (100GB+). While no significant deletes or auto expires were underway.</p>

<p>With a little poking about in the database I found the deletepending column of the recordings table had a number of entries with a value of 1, most of these stretching back to when I had a mythtv bug causing the backend to delete/expire recordings prematurely and then die, last year.</p>

<p>I speculate that if a recording is deleted or expired and then the backend fails before the actual recording and metadata are removed, the file and recording row will become orphaned but still take up space on disk. </p>

<p>I guess its possible many people would have one of more files like this, if your backend has ever failed then its possible.  This bit of sql should show all pending deletes, those in the delete recording group and any &#39;extras&#39; you may have:<br>

select * from recorded where deletepending=1;</p>
<p>I ran into the database:<br>
update recorded set deletepending=0 where deletepending=1;<br>
[the where clause may well be unnecessary]</p>
<p>It did kill my mbe, so I recommend doing this with your backend(s) shutdown. After restarting I can now see all of the recordings which were supposedly removed previously while I had the bug last year, these will shortly expire (being old) and I&#39;ll get my space back.</p>

<p>Perhaps mythbackend should clear this flag on startup, to make the files re-appear or restart the slow delete process with data from the recorded table where the flag set. I dunno exactly what the correct behaviour should be.</p>

<p>I hope this helps someone else. have fun.<br>
dave<br></p>