<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jan 23, 2017 at 12:03 PM Brian J. Murrell <<a href="mailto:brian@interlinx.bc.ca">brian@interlinx.bc.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2017-01-23 at 15:58 +0000, Joseph Fry wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Even then it doesn't get that weird... there is some pretty basic<br class="gmail_msg">
> logic<br class="gmail_msg">
> that controls the order in which recordings are deleted to recover<br class="gmail_msg">
> space.<br class="gmail_msg">
> Most likely if this recording has lasted this long, it was probably<br class="gmail_msg">
> recorded at a high priority or had the preserve flag set, which puts<br class="gmail_msg">
> it<br class="gmail_msg">
> very low on the list for clearing out.<br class="gmail_msg">
<br class="gmail_msg">
Both of the episodes I'm looking at have preserve == 0 and recpriority<br class="gmail_msg">
== 0.<br class="gmail_msg">
<br class="gmail_msg">
The one from 2010 has deletepending == 1.  The second one I was looking<br class="gmail_msg">
at has deletepending == 0 even though the recgroup == Deleted, like the<br class="gmail_msg">
first one.<br class="gmail_msg"></blockquote><div><br></div><div>I wonder if it's trying but failing to delete the file, and thus not updating it in the database since it never completes.  You might double check the file permissions and that the file actually exists at the exact path that the database is referencing.  You may also want to check the logs to see if you see any errors related to the deletion of that file when you attempt to force it's removal. </div></div></div>