[mythtv-users] Mythtranscode TRASHES file to 123KB when re-encoding with cut list
Jeffrey J. Kosowsky
mythtv at kosowsky.org
Wed May 25 03:35:07 UTC 2011
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...
More information about the mythtv-users
mailing list