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

[Jeffrey J. Kosowsky]

Jeffrey J. Kosowsky wrote at about 20:56:50 -0400 on Tuesday, May 24, 2011:
 > Michael T. Dean wrote at about 20:17:22 -0400 on Tuesday, May 24, 2011:
 >  > FWIW, mythtranscode only "TRASHES file" because you're using the unsafe 
 >  > configuration that allows mythtranscode to delete the recording after it 
 >  > completes (in a way where it /thinks/ it was successful).
 >  > 
 >  > 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.
 >  > 
 >  > (and then clean up the .old after verifying a successful transcode).
 >  > 
 > 
 > Yes - I am aware of that setting :P  but the default is to delete!
 > 
 > But more importantly, the problem is not about me since I now
 > (painfully) know well enough not to re-transcode mpeg4->mpeg4 with
 > cutlists. So, I can just avoid the problem for that specific broken
 > use case rather than globally disabling.
 > 
 > The problem is for the next unwitting victim who uses the "unsafe"
 > default settings and then finds out months later that he has destroyed
 > his recordings...
 > 
 > -------------------------------
 > My more general comment (that was edited out from my bug report) is
 > that it seems like mythtranscode is not getting a lot of developer
 > attention which has resulted now in 2 severe regressions between 0.23
 > and 0.24 that without warning destroy original recordings (first the
 > 6-channel audio issue and now this). It also seems that the severity
 > and priority of both of these bugs was ignored at least in part
 > because the devs don't happen to use the feature.  If mythtranscode is
 > not being actively supported or lacks sufficient developer interest
 > and attention then IMHO we would all be better off disabling it
 > altogether or at least putting in major warnings and making the
 > default not to overwrite the original. Better to have fewer features
 > than to have features that destroy original data without warning. This
 > is not meant to be a criticism or a rant but rather a constructive
 > suggestion from a long-time user who actually cares about the quality
 > and adoption of the program... (it is disappointing to me that there
 > seems to be so much sensitivity to constructive suggestions)
 > _______________________________________________

Case in point is the response to the ticket...
	 Calm down. Most users don't use nuv to nuv transcoding, and I daresay
	 none of the developers do. If you'd like to have a rational discussion
	 we'd be happy to address your concerns on the users mailing
	 list. Until then, this ticket is locked and we will address it when it
	 is both convenient and fun, as befits a hobby. We are not slaves. You
	 have been told how to avoid having mythtranscode delete the old
	 recording on the mailing list. 

The only person not being calm and acting super-sensitive is the dev
who has edited and locked the ticket to avoid any comments that
they interpret as "unsolicited" or mildly constructively critical.

In my initial comment, I *specifically* and *repeatedly* prefaced my
comments with "with all due respect and appreciation to the devs" and
I gave *constructive* suggestions. I did so precisely because I know
how incredibly sensitive the devs are on this project relative to all
the other open source projects that I participate in. Nowhere were any
demands made or any suggestions offered about being 'slaves'. In fact,
I suggested that if there is not sufficient interest in supporting and
testing the mythtranscode functionality then it would be better to
drop it altogether or at least to deprecate it and/or warn users. None
of that requires any "slavery" or intrudes on anybodys fun.

If as you say nobody is using nuv->nuv transcoding and it is only
considered a minor priority then it would seem to make logical sense
to disable the functionality unless and until it is fixed. This seems
only reasonable and rational to avoid hurting other unsuspecting
users. The suggestion in fact does nothing for me -- it purely was
offered to help prevent other unwitting users from irretrievably
destroying and losing precious recordings.

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?

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