[mythtv-users] trandcoding messes up 6 channel audio slow audio playback
Jeffrey J. Kosowsky
mythtv at kosowsky.org
Mon Apr 11 14:23:41 UTC 2011
>On 10 April 2011 09:48, Scott Macdonell <genius9976 [at] yahoo> wrote:
>> FYI to those experiencing this problem. I tried using mythnuv2mkv
>> and a user job
>> instead of mythtranscode, thinking that might work. It caused the
>> same problems
>> with 6 channel audio. So... if anyone else had that idea... don't
>> waste your
>> time. It seems like it was also calling mythtranscode the userjob
>> just calls
>> Also, will these fixes end up in the rpmfusion packages or atrpms
>> before too long? I've never used trunk or anything like that, but if
>> it's going
>> to be a long time it might be worth it to me to figure it out
>For a fix to appear, it needs to be fixed first.
>For a fix to be found, the problem has to be able to be reproduced by
>a dev. This is done by people providing samples, arguments on how
>mythtranscode is called and logs.
>So far I'm yet to read anything that could be helpful in any ways.
>It's always : it doesn't work. It's messed up. I'm using mythtranscode
>default etc etc...
>While this is the case, no fix will be worked on.
I'm confused here. Are you talking about the original bug
identified on this thread (where mythtranscode fails with 6 channel
recording) or are you talking about some other transcoding issues that
have been infiltrated into this thread?
Because I thought the original issue with 0.24 where 6 channel
transcoding gets missed up was well documented and that you yourself
had volunteered back on December 30th to put this "trivial" fix on
your todo list for some time in February if I recall correctly. (I
believe the fix involved copying the AC3 stream directly to the
If this has been indeed fixed, will the fix be backported into the
official 0.24-fixes branch? I ask because I use atrpms and Axel is
hesitant to compile in any fixes that are not official. Meanwhile, I
continue to burn way too much disk space since I can't transcode...
If the bug has not been fixed, what further information is required to
identify and fix the bug or is it just a matter of nobody having the
time and/or interest and/or skills to fix it?
That being said, if indeed the bug is not yet fixed in trunk or not
backported to 0.24-fixes, it should be marked as a *HIGH PRIORITY
CRITICAL* bug given that it results in irreversible destruction of
precious recorded programs without any warning to the user. While some
of the advanced users may not be affected since they use their own
external 3rd party transcoding scripts, transcoding to mpeg4 remains
the *only* internally supported option for compressing massive mpeg2
HD quality recordings. So, this bug seems most likely to affect and
discourage the "mass" of none l33t users who may not even be aware
that their recordings are being silently destroyed (it took me a
couple of weeks to notice the problem at which point I had lost dozens
NOTE: I am not criticizing the devs since I am well-aware that this is
a volunteer project and have the utmost respect and thanks for all
contributors, I am just suggesting that from a QA severity-of-bug
perspective, fixing a bug that irreversibly destroys potentially
irreplaceable recordings seems to be a lot more important than random
feature enhancements or GUI fixes....
More information about the mythtv-users