[mythtv-users] Recorded material stutters, live TV is perfect. Why?

[Gerald Schepens]

I have been having a stuttering issue since going to 0.21, though that
switch also came with different IVTV driver versions because I changed
kernels around the same time.  I also don't know whether live TV
playback is stutter-free because I pretty much always watch from
recordings, but the odd time I've fired up live TV I don't remember it
stuttering.

My system is a P4, 2.5 GHz, single processor, Asus P4PE mobo, 1 GB RAM,
running Fedora 8, kernel 2.6.24.5-85.fc8.  There are two capture cards
-- a PVR350 and a PVR500, and I run X on a framebuffer with the ivtvfb
kernel module to watch recordings and run the front end on my tv via the
PVR350 TV-out.  As for bit rate, a 70 minute show records a file of 3.3
GB in size, which works out to about 825 kbytes per sec.

I'd be curious to know whether the problem backend machine records
messages like this in the messages / dmesg log while recording the
stuttering shows:

May  2 10:07:32 www kernel: ivtv0: All encoder MPG stream buffers are
full. Dropping data.
May  2 10:07:32 www kernel: ivtv0: Cause: the application is not reading
fast enough.

And this despite adding buffers in the modprobe.conf options for ivtv...
obviously not the solution, or else the buffers I added were too few.

On Fri, 2008-05-02 at 10:42 -0700, Mark Knecht wrote:
> On Fri, May 2, 2008 at 10:38 AM, Michael T. Dean
> <mtdean at thirdcontact.com> wrote:
> > On 05/02/2008 01:16 PM, Brian Wood wrote:
> >  > On May 2, 2008, at 11:05 AM, Mark Boyum wrote:
> >  >
> >  >> You haven't indicated what type of material you are recording /
> >  >> playing.  Assuming it is SD, I would say that even at 20% your
> >  >> system should be able to perform decent playback.  I would suspect
> >  >> the problem is related to using a wireless network.  Just to test,
> >  >> try connecting that frontend via Cat5.
> >  >>
> >  >>
> >  >
> >  > Following this thread I'd missed that you were using a wireless
> >  > network. I agree that is almost certainly at least part of your problem.
> >
> >  And the 20% CPU is probably due to the rebuffering which is due to the
> >  stuttering which is due to the data transfer issues.  I.e. the jump from
> >  12% to 20% CPU is not causing the issue, but a symptom of it.  That's
> >  also why it doesn't stabilize after reducing the speed back to real-time
> >  (because it's still stuttering...).
> >
> >  Mike
> >
> 
> Ah, interesting thought. I was going a different direction with it. I
> noticed that the jump to 20% happens even when I slow down playback
> first. I was thinking that whatever the software component is that
> does the building of frames for different speeds might need updates in
> Gentoo. Maybe I'm using the wrong flags. Is that software part of Myth
> proper or is it a library that Myth calls like fftw or something?
> 
> Thanks,
> Mark
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users