[mythtv-users] Ticket #9801: mythtranscode produces unusable output when transcoding mpeg4->mpeg4 with cutlists

[Jeffrey J. Kosowsky]

Unfortunately, ticket is LOCKED which makes it rather difficult to
supply the "infoneeded_new" :P

I will post my response below and perhaps the powers-that-be can
repost on the ticketing system...

""MythTV"" wrote at about 17:39:35 +0000 on Tuesday, June 14, 2011:
 > #9801: mythtranscode produces unusable output when transcoding mpeg4->mpeg4 with
 > cutlists
 > ------------------------------------+--------------------------------
 >  Reporter:  mythtv@…                |          Owner:
 >      Type:  Bug Report - General    |         Status:  infoneeded_new
 >  Priority:  minor                   |      Milestone:  unknown
 > Component:  MythTV - Mythtranscode  |        Version:  0.24-fixes
 >  Severity:  medium                  |     Resolution:
 >  Keywords:  mythtranscode cutlist   |  Ticket locked:  1
 > ------------------------------------+--------------------------------
 > Changes (by mdean):
 > 
 >  * status:  new => infoneeded_new
 > 
 > 
 > Comment:
 > 
 >  What distro is this?  There's an issue that's been observed on some
 >  distros (specifically some versions of *buntu) where the exit status is
 >  not properly reported to applications, so MythTV doesn't realize that an
 >  application died--which would explain why it continued without realizing
 >  there was a failure.
 > 
 > -- 
 > Ticket URL: <http://code.mythtv.org/trac/ticket/9801#comment:7>
 > MythTV <http://code.mythtv.org/trac>
 > MythTV Media Center

My response:

I am running using the atrpms version (0.24-272) of MythTV under
Fedora.

The attached log shows all the verbose information and should capture
any of the messaged errors (though there don't seem to be any related
to this bug).

Note that the behavior can be replicated by running mythtranscode
directly from the CLI (see the original post). I did not however check
the shell exit code at the time. If that would be helpful, I could run
it again and check it (Hopefully, the bug report will be unlocked by
then :P)

Regarding your mention of MythTV checking exit codes before
overwriting the original, one suggestion for future versions of the
code may be to also sanity check the file size to avoid obvious
destructive overwriting of original recordings. For example, if the
ouput size is less than a few megabytes then either don't overwrite
(and signal an error) or overwrite but rename original rather than
deleting it.

Note such an added sanity check would have caught this bug where the
output files are 100-150KB. It also would have caught rare unexplained
cases I have noted in the past (unrelated to this bug) where the
output file is zero length.