[mythtv-users] Problems with nuvexport and single episode shows

Dale Pontius DEPontius at edgehp.net
Sun Mar 21 22:31:47 UTC 2010


On 03/21/10 12:13, Gavin Hurlbut wrote:
> On Sat, Mar 20, 2010 at 2:37 PM, Dale Pontius <DEPontius at edgehp.net> wrote:
>> ID_AUDIO_BITRATE=384000
>> ID_AUDIO_RATE=48000
>> ID_AUDIO_NCH=2
>> ID_AUDIO_CODEC=mp3
> 
> OK, seems that the first file is consistant...
> 
>> ID_AUDIO_BITRATE=384000
>> ID_AUDIO_RATE=32000
>> ID_AUDIO_NCH=2
>> ID_AUDIO_CODEC=ffmp2
> 
> Interesting.  But this should work
> 
>> Too many video packets in the buffer: (1787 in 33561528 bytes).
> 
> My guess on these is that they are problems in the recording.  If the
> signal is marginal when being recorded, sometimes you get this kind of
> result.  Not having the same recording setup, I can't suggest any way
> of tweaking the settings to help there.  Is it at least watchable, but
> likely with little glitches?
> 
>> If this suggests changes I should make in my setup now, to make things
>> work better in the future, I'm game for that, too.
> 
> Well, one thing you could try is forcing it to 48kHz again, but it
> should be fine the way it is, theoretically.
> 
> The good news here:  If you use the nuvexport in SVN trunk (which will
> become 0.23 soon), this issue should be fixed.  A few weeks ago, I
> added in code to the MythTV perl bindings (that nuvexport uses) to try
> lavf if there was bogus audio information (and some bogus video
> information) detected by mplayer in its default settings.
> 
> If you can wait for 0.23, great.  If not, you should be able to
> manually change the one affected file (if you are careful), and it
> should start behaving correctly for you.  See:
> http://svn.mythtv.org/trac/changeset/23616 and
> http://svn.mythtv.org/trac/changeset/23771 to see the changes I made.
> 
Better, but not quite there yet.  In your "forcing the use of the ffmpeg
lavf demuxer" clause, you don't set "$info{'audio_bits_per_sample'}, so
the command line comes out with "-e 32000,,2", and there's a line of
hate-mail about the missing parameter.  I thought there might be a
chance the "-e 32000,,2" syntax might be accepted, so I tried it anyway
- no-go.  (I tried copying the audio_bits_per_sample clause into the
conditional, but that didn't work, either - same uninitialized string.)

I'm not sure what you mean about using nuvexport from the 0.23 trunk,
because your fix was over in MytTV itself.  Are you meaning that you
intend to try a different fix in nuvexport alone, or will whatever you
do for the longer run be dependent on what you've done in MythTV?

In any case, I see now that I am free to update my recording profiles,
because you're grabbing this information from the file itself, not from
the database.

In the long run, I'm assuming things are getting close, and will get
fixed.  Wherever the working nuvexport winds up, it would be good if you
could make another snapshot.  I'll then push that through to the folks
at Gentoo.  We've barely migrated to 0.22 here, so 0.23 is a ways off.
But nuvexport seems to be fairly version insensitive.  I suspect that my
current problems are because I never set up recording profiles after
migrating the partially-corrupt, fixed database to 0.22.

Thanks,
Dale


More information about the mythtv-users mailing list