[mythtv-commits] Ticket #9801: mythtranscode produces unusable output when transcoding mpeg4->mpeg4 with cutlists
MythTV
noreply at mythtv.org
Tue May 24 23:57:36 UTC 2011
#9801: mythtranscode produces unusable output when transcoding mpeg4->mpeg4 with
cutlists
------------------------------------+----------------------------
Reporter: mythtv@… | Owner:
Type: Bug Report - General | Status: new
Priority: minor | Milestone: unknown
Component: MythTV - Mythtranscode | Version: 0.24-fixes
Severity: medium | Resolution:
Keywords: mythtranscode cutlist | Ticket locked: 0
------------------------------------+----------------------------
Old description:
> 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
New description:
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
--
Comment (by robertm):
Removing opinion/unsolicited development advice.
--
Ticket URL: <http://code.mythtv.org/trac/ticket/9801#comment:3>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center
More information about the mythtv-commits
mailing list