Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#2492 closed defect (fixed)

mythtranscode leaving cifsxxxx files behind after transcode finishes

Reported by: ylee@… Owned by: Nigel
Priority: minor Milestone: unknown
Component: mythtv Version: 0.20
Severity: medium Keywords: mythtranscode delete silly rename cifs
Cc: Ticket locked: no

Description

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.

Change History (9)

comment:1 Changed 14 years ago by Isaac Richards

Resolution: invalid
Status: newclosed

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.

comment:2 Changed 14 years ago by ylee@…

Resolution: invalid
Status: closedreopened

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.

comment:3 Changed 14 years ago by Isaac Richards

Resolution: fixed
Status: reopenedclosed

This is still not a myth bug.

comment:4 Changed 14 years ago by ylee@…

Resolution: fixed
Status: closedreopened

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?

comment:5 Changed 14 years ago by Isaac Richards

Resolution: invalid
Status: reopenedclosed

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.

comment:6 Changed 14 years ago by Nigel

Resolution: invalid
Status: closedreopened

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.

comment:7 Changed 14 years ago by Nigel

Owner: changed from Isaac Richards to Nigel
Status: reopenednew

comment:8 Changed 13 years ago by cpinkham

Resolution: fixed
Status: newclosed

(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.

comment:9 Changed 13 years ago by 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.

Note: See TracTickets for help on using tickets.