[mythtv] Can mythtranscode use mythbackend's auto-expire to delete files?

[Yeechang Lee]

Chris Pinkham <cpinkham at bc2va.org> says:
> Mythtranscode doesn't delete the original recording using
> mythbackend, it just does a unlink() on the file, so if you have
> cifsxxxx files sticking around it is an issue unrelated to the
> truncating delete code.
> 
> The transcoder doesn't have the file open anymore by the time it does
> the unlink so I'm not sure why this would have happening.

Thanks for the clarification. Certainly I didn't see this behavior in
0.19-fixes (ATrpms); after transcoding was complete I'd see the
filesystem immediately lock up (as expected) while mythtranscode
deleted the original recording. I'll go ahead and file a ticket.

The reason I'd thought the truncation code was involved here as well
is a) the similar symptoms (leftover cifsxxxx files whose sizes never
decreased) and b) because this is a change I'd hoped would have
occurred in 0.20 in order to further eliminate instances of filesystem
lockups and consequent recording corruptions. How feasible would it be
for mythtranscode to pass the task of deleting original recordings
(and, perhaps, .tmp files if one already exists for a given
transcoding task when the task begins, as they can sometimes be
multigigabytes in size) to mythbackend autoexpire?

-- 
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US