[mythtv-users] Recordings stay in database and on disk for some time after delete?

Tom Dexter digitalaudiorock at gmail.com
Sat Feb 27 17:49:06 UTC 2010


On Fri, Feb 26, 2010 at 10:55 AM, Daniel Kristjansson
<danielk at cuymedia.net> wrote:
> On Fri, 2010-02-26 at 08:58 -0500, Tom Dexter wrote:
>> On Thu, Feb 25, 2010 at 9:18 PM, Chris Pinkham <cpinkham at bc2va.org> wrote:
>> > * On Thu Feb 25, 2010 at 09:15:53PM -0500, Chris Pinkham wrote:
>> >> * On Thu Feb 25, 2010 at 01:04:25PM -0500, Tom Dexter wrote:
>> >> > By the way...another thing that appears to have changed since 0.21:
>> >> > It used to be the case that, if a number of files where pending slow
>> >> > deletes when the backend is stopped, it deleted them as fast as the
>> >> > file system allowed before actually stopping.  It doesn't appear that
>> >> > occurs any more.  As a matter of fact, when I tried it, not only did
>> >> > it not delete the files...it appeared they weren't even getting
>> >> > truncated/deleted at all when I restarted the backend (even though
>> >> > they were set as deletepending in the recorded table) until I actually
>> >> > deleted them again.
>> >>
>> >> Thanks for mentioning this.  This was a regression introduced in [18792].
>> >> I just committed a fix to 0.22-fixes and trunk to restore the original
>> >> functionality.
>> >
>> > I should clarify. The issue fixed is the issue with the files not being
>> > deleted if the backend was restarted.  I should have trimmed the quoted
>> > text a little more above.
>
> They should be deleted immediately when the backend is stopped. The
> way it works is that the delete code opens the file and then tells
> the OS to delete the file.. but the OS doesn't do it right away since
> the file is open; now MythTV starts slowly truncating the file. if
> MythTV is killed before the file has been fully truncated the OS deletes
> the file right away because no one has the file open anymore... The
> regression was caused by some locking that was preventing the delete
> call to the OS from happening until after any in-progress truncates
> were finished, that has been fixed in trunk and the fix has been
> backported to 0.22-fixes.
>
> -- Daniel
>

Thanks Daniel! I'm applying that changeset (23604) to my system right
now.  Just curious...would this possibly explain some of the odd
behavior I described earlier in this thread, where recordings pending
delete were showing the in the list of recordings (both in the
frontend and mythweb)?

Thanks again.
Tom


More information about the mythtv-users mailing list