mythtranscode TRASHES recordings when transcoding mpeg4->mpeg4 with cutlists

[mythtv@…]

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