[mythtv-users] Slim down weight from .old transcodes the MythTV way

[Michael T. Dean]

On 10/11/06 16:30, Yeechang Lee wrote:

>Michael T. Dean <mtdean at thirdcontact.com> says:
>  
>
>>***Warning:  /Do not/ enable this setting unless you're running MythTV 
>>0.20-fixes r11313 or above (basically, code from on or after Sep 28) or 
>>SVN trunk r11312.
>>    
>>
>Was this an issue that the bugfix you helped me with regarding this
>code took care of? Or was there another, more dire, issue with it?
>
It was a more dire issue that was fixed (in SVN trunk) before your 
remote filesystem issue was fixed.  That fix never got merged into 
-fixes, but once the remote filesystem fix went into trunk, it was 
merged into -fixes.  The remote filesystem fix simplified the approach 
and obsoleted the first fix (it got rid of the code that was broken and 
the code from the patch that only went into trunk).

So, [11313] is the fix to the remote filesystem issue, but also fixes 
the more dire issue.

>>Note, though, that even with this enabled, you can be affected by
>>slow deletes when the transcoder finishes if you don't enable the
>>mythtv-setup setting:
>>
>>Save original files after transcoding (globally) When set and the
>>transcoder is active, the original files will be renamed to .old
>>once the transcoding is complete.
>>
>>So, just enable that setting (which is actually a good thing since
>>you can verify your transcode worked before you lose the original)
>>and delete the .old files when Myth isn't recording.
>>
>Anyone feel like writing a shell script, callable through cron, that
>will a) take all .old files and b) truncate and delete each one down
>in a way similar to the method now incorporated into mythbackend?
>Volunteers wanted!
>  
>
I think it would be better to modify Myth to use the slow deletes (if 
enabled) for transcode deletes, too.  And, I plan to look into this in 
the relatively near future (once I finish up my current (non-Myth) 
project--maybe in a week or two).  I think the main reason your ticket 
was closed was a combination of commingling of requests (left over 
silly-renamed files and the moving transcode deletes to autoexpire) and 
the whole "feature request without a patch" issue.  :)

Mike