[mythtv-users] Mythtranscode TRASHES file to 123KB when re-encoding with cut list

[Michael T. Dean]

On 05/24/2011 09:12 PM, Jeffrey J. Kosowsky wrote:
> If you don't find it "fun" to fix mythtranscode, then why not just
> drop the functionality or warn the user? How demanding can that be?

OFFICIAL WARNING:

All users should enable the mythtv-setup (General) setting:

Save original files after transcoding (globally)
If enabled and the transcoder is active, the original files will be
renamed to .old once the transcoding is complete.

because failing to do so could result in losing a recording.  :)

> Such supersensitive attitudes displayed by the official development
> community certainly does nothing to encourage new users to contribute
> their time and effort to improving the code. But hey it's your
> project... you don't have to listen to any constructive
> criticism... and I can instead choose to invest my time in projects
> where the developer community is more welcoming and open...

We have 413 open tickets, right now.  If we disabled all the 
functionality that doesn't work (and can result in loss of recordings, 
etc.--which would include the backend because of all the things that can 
cause it to crash or fail to record or ...), we wouldn't have a PVR left.

Unfortunately, those 413 tickets mean that we have a /lot/ of tickets 
for each developer to handle.  And, when one of the more-active 
developers spends his evening trying to triage /one/ ticket (where 
triage means just getting the ticket properly filed in our bug tracker), 
rather than getting to work on code for MythTV, it doesn't help us get 
any closer to fixing those 413 open tickets.

We do appreciate input.  We just have a /lot/ of things that need 
working on and only a few developers to work on them (especially since 
several of the developers aren't active due to other commitments in 
life).  So, having short tickets with to-the-point descriptions of the 
problems, so that a developer who makes time to work on the issue can 
read and understand quickly, allows us to spend more time fixing issues 
rather than reading about them.

As far as what seems to be your primary concern--that you lost a 
recording with the default settings--since there's a setting to allow 
users to safely transcode without losing anything, even in the event of 
a failure, this wouldn't fall under my definition of a critical issue 
(if I were the developer who chose to work on it--see 
http://code.mythtv.org/trac/wiki/TicketHowTo, "Please do not increase a 
ticket's priority, severity, or milestone from the defaults. These 
fields are for the person who is fixing the issue to decide. Don't 
change these after the ticket's been filed, either - they'll likely just 
get changed back.").  One could argue that the setting that saves 
transcodings should be enabled by default, but it's not (and never has 
been) because most users would never know to go back and clean up the 
*.old files if they didn't explicitly enable a setting that leaves them, 
and would, therefore, suffer from storage "leaks" (with unmanaged 
multi-gigabyte files taking up their recording space, and causing 
recordings to be expired early, thus causing a loss of recordings).  
IMHO, though, anyone who uses mythtranscode should enable the setting to 
save the original files when transcoding and clean up the *.old files 
manually after verifying success.  (I have it enabled for the once in a 
blue moon when I use mythtranscode.)

In the future, MythTV will be able to manage multiple files per 
recording, and at that point, mythtranscode will never delete 
recordings, and the original and the transcoded file will both exist as 
a file related to the recording, where the user will see them both and 
be able to verify a successful transcode and delete the original all 
from inside MythTV.  Unfortunately, that change will require major 
rework of a /lot/ of MythTV, so it won't happen quickly--especially 
because of all the other things that need doing/bugs that need fixing, 
too, and the limited time we have to work on MythTV in our "free" time.

So, that just leaves fixing mythtranscode to work on an nuv->nuv 
transcode, which is what the ticket description now says.

Mike