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

[Mark Knecht]

On Fri, May 2, 2008 at 11:21 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 05/02/2008 01:42 PM, Mark Knecht wrote:
>
>
>  >  On Fri, May 2, 2008 at 10:38 AM, Michael T. Dean 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...).
>  >
>
> >  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?
>
>  The timestretch code in Myth is an integrated version of a standard
>  library (i.e. no need to update anything).

OK. Thanks.

>
>  Note, however, that 0.21 has some code which attempts to set the
>  read-buffer size appropriately "on the fly."  I.e. if it starts to
>  stutter, it attempts to increase the buffer size.  The code isn't
>  perfect and tends to have serious issues in less-than-ideal (read
>  wireless) network conditions.
>
>  You're typically better off letting the backend stream the recordings
>  rather than using NFS or CIFS or whatever when you're having these
>  issues.  If you want to work on fixing the code, I think Stuart A. had
>  some ideas.

Not a coder, unfortunately.

Streaming is default, correct? I've not setup NFS and assume I don't
use CIFS as I don't know what it is.

>
>  Fix the network, fix the playback.  (Think Heroes season 1.)
>

Big smile. Love the show.

OK, fix the network is a good idea, 0.20 worked flawlessly over this
same network so it's not like that's changed.

I will look at hooking it up with a cable in a day or two just to
ensure that at least it works as well as the other machines but that
still wouldn't get rid of the stuttering every time we skip
commercials. That's what the family is complaining about. This big
problem with wireless is my issue only back in my office where I work
during the day.

I'll keep plugging along. I'm sure an answer is out there. We just
need to find it.

Thanks,
Mark