[email protected] wrote: > And I still get what I refer to as stuttering. I'm watching something > through the Haupppage MediaMVP, and the video starts to stutter and > then almost locks up, jsut barely staggering forward. The buffers > drop down to empty. If I pause, they'll fill back up, but removing > pause almost immediately drops them back to 0, and stuttering. > > I still believe the problem is somewhere in the mvpmc code with > mythtv. Reasons: > -If I let it keep stuttering, it will keep it up as long as I'm > willing to tinker with it. Yet if I soft reboot the MediaMVP and go > right back to the video in mythtv, I'm good for a while. > -If I watch something from a cifs share, I don't appear to have the problem.
I've seen the same symptom, though in my observations it occurs rarely and randomly. I also observed that simply stopping the video and restarting it will reset the buffer problem. (Though as my show list grew, a warm restart would likely be necessary, but that holds true for almost any return to the show menu after playing a video.) My theory is that it is not memory related - at least not in the sense that mvpmc is running out of its general pool of memory. But that the problem is in the mvpmc MythTV client (or perhaps the network stack), though likely with an external trigger. It seems that once something causes a buffer underrun, mvpmc is unable to recover. That could be the result of a drop in disk I/O, a back-end slow-down (like a RAID rebuild), a burst in the bitrate of the encoded video, or network congestion. I recommend setting up an experiment where the video stream is slowed down in a controlled fashion. Then observe at what point the stuttering starts, and whether it recovers when the stream is sped back up to normal. > -I have two mediamvps. If something is being watched via mythtv on > both, when stuttering starts on one, it doesn't start no the other. Does it happen with any greater frequency when you are using two MVPs simultaneously? > Most commonly it starts at about 20 minutes, but not always. It may be interesting to try running the mvpmc bandwidth test for 30 minutes and see how that compares to a 10 minute run. Repeat with both MVPs running the test at the same time. > I've wondered if it has a correlation to the "Control TCP Receive > Buffer" and "Program TCP Receive Buffer" settings... There's an old (2007 era) thread I started about the mvpmc UI slowing down that ultimately was blamed on low memory, but along the way I observed that the error count on the Ethernet interface spikes when the MVP's CPU starts to get loaded. This implies to me that the network driver and/or hardware on the MVP are not the greatest (an interrupt handler shouldn't get delayed by a failed memory allocation request). So the MVP may be more sensitive to network conditions than an average client. Tweaking those buffers may help, but it's hard to imagine how they'd impact an event that takes 20 minutes to happen, as I expect the time to fill those buffers is orders of magnitude smaller. If, for example, you had a 64KB buffer, and it took 20 minutes for it to underrun, that would mean on average the MVP was consuming ~3KB more data than the back-end could supply. If that's actually what's happening, you could add another 32KB of buffer to stretch out the onset for another 10 minutes, but it's still going to eventually fail. A long-duration bandwidth test should show if something like this is happening. -Tom ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
