mythtranscode leaving cifsxxxx files behind after transcode finishes

[ylee@…]

I use a cifs mount for my MythTV recordings. With 0.20 (ATrpms) mythtranscode will, after completing a transcode, leave behind the original recording renamed to cifsxxxx (a consequence of using silly rename, I know) instead of deleting it as it's supposed to (and as it did in 0.19-fixes).

I don't know how feasible this is from an architectural standpoint, but could this issue be fixed by having mythtranscode pass along the task of deleting the original recording to mythbackend's autoexpire? That way the recording could be deleted using, if set, 0.20's new truncated-delete feature and, thus, eliminate the last major cause of filesystem lockups and consequent damaged recordings for those of us stuck with EXT3 for one reason or another.

[Isaac Richards]

This is not a myth bug. Renaming the file (and it's final removal) doesn't really have much to do with Myth's deletion code.

[ylee@…]

With all respect, Isaac, this is a bug that appeared in 0.20, or at the very least a change between 0.19-fixes and 0.20 in how mythtranscode treats old recordings. Even if no work is done on my suggestion to to fix the bug by passing old recordings off to autoexpire, I'd like to keep this ticket around to at least restore 0.19-fixes' mythtranscode's behavior in terms of properly and completely deleting them.

[Isaac Richards]

This is still not a myth bug.

[ylee@…]

Isaac, I am very likely being obtuse here, but how is this not a MythTV bug? If mythtranscode in 0.20 can't properly delete a file when mythbackend (regardless of my chatter about truncated deletes and autoexpire and so forth) can (regardless of the setting of the slow-deletes option), isn't that a problem with mythtranscode?

[Isaac Richards]

If the file is being renamed to cifsxxxx, then myth is properly deleting it. Unless you can prove otherwise, I don't see how Myth could possibly be doing anything wrong here.

[Nigel]

Mark Buechler remarks the cifsXXXX file is being created because Myth is deleting the file while it is still open. I think I have observed similar behaviour with NFS, so I will try to recreate this.

[cpinkham]

(In [13894]) We need to delete the Transcode object which deletes the RingBuffer? object which closes the open input file before we can call CompleteJob?() which deletes the input file. Previously we were deleting the open file which was causing cifsxxxx files to hang around after mythtranscode was finished.

Closes #2492.

[cpinkham]

(In [13895]) Carries over [13894] from trunk.

We need to delete the Transcode object which deletes the RingBuffer? object which closes the open input file before we can call CompleteJob?() which deletes the input file. Previously we were deleting the open file which was causing cifsxxxx files to hang around after mythtranscode was finished.

References #2492.