[mythtv-commits] Ticket #9801: mythtranscode TRASHES recordings when transcoding mpeg4->mpeg4 with cutlists

MythTV noreply at mythtv.org
Tue May 24 23:51:01 UTC 2011


#9801: mythtranscode TRASHES recordings when transcoding mpeg4->mpeg4 with
cutlists
-----------------------------------+--------------------------------------
 Reporter:  mythtv@…               |           Type:  Bug Report - General
   Status:  new                    |       Priority:  critical
Milestone:  unknown                |      Component:  MythTV - General
  Version:  0.24-fixes             |       Severity:  high
 Keywords:  mythtranscode cutlist  |  Ticket locked:  0
-----------------------------------+--------------------------------------
 I am having the following problem with the latest 0.24-fixes version of
 mythtranscode:
 1. Transcoding mpeg2 to mpeg4 with or without cutlist works fine
 2. (Re)Transcoding mpeg4 to mpeg4 WITHOUT cutlist works fine
 3. (Re)Transcoding mpeg4 to mpeg4 WITH cutlist terminates (without
 relevant error message) after a few seconds with an output file of about
 100-150KB independent of the actual cutlist. If mythfrontend is used then
 this useless, truncated recording replaces and TRASHES the original
 recording.

 This seems to occur regardless of the actual mpeg4->mpeg4 recording
 profile parameters and occurs even when doing a 'lossless' version (note
 in all cases I use mp3 for audio).

 Here is an example running mythtranscode from the CLI:

 #mythtranscode --chanid 1021 --starttime 20101120163000 --outfile
 1021_20101120 163000.nuv-OUT2 --honorcutlist --profile 3

 (where profile 3 = High Quality mpeg4/mp3)

 Gives the following output:

       2011-05-23 21:52:57.355 Using runtime prefix = /usr

       2011-05-23 21:52:57.355 Using configuration directory =
 /home/use/.mythtv

       2011-05-23 21:52:57.372 Empty LocalHostName.

       2011-05-23 21:52:57.426 New DB connection, total: 1

       2011-05-23 21:52:57.447 Closing DB connection named 'DBManager0'

       2011-05-23 21:52:57.495 Enabled verbose msgs: important

       2011-05-23 21:52:57.787 Found video height of 1088.  This is unusual
 and more than likely the video is actually 1080 so mythtranscode will
 treat it as such.

       2011-05-23 21:52:57.788 New DB connection, total: 2

       2011-05-23 21:52:57.816 New DB connection, total: 3

       2011-05-23 21:52:57.849 Using protocol version 63

       Error in my_thread_global_end(): 1 threads didn't exit


 Note that the last error line is a MySQL error that at least in other past
 reported mythtv contexts may be benign and I don't believe it has anything
 to do with this bug report.

 The full verbose output from adding '-v all' is too long to post so I have
 posted it to pastebin.com:
      http://pastebin.com/5F9qPR3i

 NOTE: I rate this as a CRITICAL PRIORITY/HIGH SEVERITY bug since it will
 totally TRASH your valuable recordings without any warnings or error
 messages when run from mythfrontend. Mythfrontend sees the transcoding as
 completing successfully so it overwrites and destroys the original.

 Again this used to work certainly back in 0.23 days.
 By the way this is the second CRITICAL DESTRUCTIVE bug in mythtranscode
 that was introduced in the transition from 0.23 to 0.24. Both this current
 bug and the recently fixed audio bug IRREVERSIBLY DESTROYED recordings.

 With all due respect to the volunteer nature of the developers, I would
 suggest that either mythtranscode be removed from the distribution or that
 more attention be paid to testing it before releasing a new mythtv
 version. The surest way to turn off new (or old) users of mythtv is to
 introduce major bugs into supposedly stable releases that break existing
 functionality and destroy valuable recordings. Again this is meant with
 all due respect and appreciation to the developer team

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/9801>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center


More information about the mythtv-commits mailing list