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

[Jeffrey J. Kosowsky]

Michael T. Dean wrote at about 22:28:05 -0400 on Tuesday, May 24, 2011:
 > 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.
 > 

Thank you truly for your very helpful explanation!

And I wasn't suggesting fully disabling mythtranscode...
Just disabling for the specific broken case.
Say, a simple pseudo-code line like:
	 if(input_type eq "nuv" && honorcutlist==1) {
	 	print "Can't transcode from nuv with cutlists\n";
	 	exit 1;
	 }
Or maybe something within mythfrontend like:
   if(sizeof(output recording) < 1MB) don't erase existing recording...
   

I'm sure there are better ways... but I was just suggesting temporary,
simple fixes to prevent loss. In my opinion, even a bad kludge like the above
is better than risking unannounced data loss... Based on my recent
experience with mythtv (and to be fair some other programs), I have
become rather "paranoid" about data loss...

Finally, if anybody can point me to the relevant code sections and
changes in mythtranscode/cutlists between 0.23 and 0.24, I would be
happy to see if I can figure out what might have changed and caused
the problem...