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

[Jeffrey J. Kosowsky]

Jeffrey J. Kosowsky wrote at about 16:59:09 -0400 on Tuesday, May 24, 2011:
 > Jeffrey J. Kosowsky wrote at about 16:13:00 -0400 on Monday, May 23, 2011:
 >  > I automatically run mythtranscode on all my new recordings (all are
 >  > originally OTA mpeg2 in HD or SD) to convert them to mpeg4.
 >  > 
 >  > Then after watching them, I manually create a cut list to eliminate
 >  > commercials and other unwanted stuff. Then I re-run mythtranscode
 >  > manually from within mythfrontend.
 >  > 
 >  > This always worked until just now when I notice that a 725MB file was
 >  > reduced to about 123KB (when I was just cutting about 5%). I tried
 >  > again just to make sure I hadn't mistakenly cut the whole file and the
 >  > same thing happened again.
 >  > 
 >  > I am running myth-0.24 fixes.
 >  > The only "new" thing is that I recently updated to include the
 >  > backported fix for the mythtranscode 6-channel audio problem though I
 >  > wouldn't think this would effect my problem (and the channel I am
 >  > dealing with is not 6-channels since it transcoded fine the first time
 >  > before the fix).
 >  > 
 >  > The only potentially unusual lines in the log are:
 >  > 1] "Found video height of 1088.  This is unusual and more than likely
 >  >    the video is actually 1080 so mythtranscode will treat it as such."
 >  > 
 >  > 2] "SampleRate: Attempted to add a rate 32000 Hz, which is not in the
 >  >    list of allowed rates." 
 >  > However, both of these messages have occurred before and never were an
 >  > issue (actually #2 always occurs)
 > 
 > OK... I did some more troubleshooting.
 > 
 > 1. If there is no cutlist, then the transcoding works just fine (as it
 >    always did)
 > 
 > 2. If there is a cutlist (whether generated manually or
 >    automatically), then mythtranscode terminates after a few seconds
 >    and gives a severely truncated (~123KB) file.
 > 
 > 3. The same behavior occurs whether I run mythtranscode via the
 >    mythfrontend interface or directly from the CLI.
 > 
 > Specifically, running:
 > 
 > #mythtranscode --chanid 1021 --starttime 20101120163000 --outfile 1021_20101120163000.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/user1/.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... so I'm not sure that is
 > the root cause of the problem here.
 > 

Some more experimenting...
The problem seems to only occur when transcoding cutlists on mpeg4
files that have already been transcoded from mpeg2.
Specifically:
1. transcoding with and without cutlists work fine on the original
   recording
2. transcoding with cutlists truncates & destroys the recording when
   done on an mpeg4 recording (that has already been transcoded from
   mpeg2).
   However, transcoding without cutlists works fine in mpeg4
   recordings.

So, somehow the problem seems to be restricted to (re)transcoding
mpeg4 recordings with cutlists!

Note that I never used to have such problems so something has
definitely broken in the past 6 months or so...