<p>Well thanks for such a long reply!</p>
<p>Mine is a combined BE/FE so io should not be the issue. I have tried leaving an SSH terminal logged in during playback and leaving top running, the pauses don't tie up with corresponding peaks in CPU usage. Its using the gt430 for video decode and CPU is around 7% when playing back HD recordings.</p>
<p>The pauses can be anything from a second or two up to over a minute and the box is completely unresponsive during this time. I'm going to try to set it to record the SD equivalent channels for a few days and see if it helps.</p>
<p>Can you help me set the -v playback option so it starts when the FE starts on mythbuntu. Currently I have to stop the FE and restart from the cli with the options which I normally forget to do!</p>
<p>Also sometimes when it pauses like this the FE crashes with a video buffering failed too many times message's but not always</p>
<p>Any other suggestions also welcome!</p>
<p>Cheers</p>
<p>Chris<br>
</p>
<div class="gmail_quote">On Feb 1, 2012 8:11 PM, "Matt Garman" <<a href="mailto:matthew.garman@gmail.com">matthew.garman@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Feb 1, 2012 at 8:12 AM, Chris Lewis <<a href="mailto:chrislewis915@gmail.com">chrislewis915@gmail.com</a>> wrote:<br>
> I'm seeing similar on HD recordings from dvb-s2. When it happens the FE is<br>
> completely unresponsive to ir remote or keyboard commands.<br>
><br>
> I did get some FE/BE logs the other night but they didn't contain much.<br>
> I'll try again with -v playback to see if it sheds any light.<br>
><br>
> Fwiw I'm on a dual core p4 @ 3.2ghz with 4gigs ram and a gt430 using vdpau<br>
<br>
Is this a pure FE box, i.e. are the FE and BE separate machines? If<br>
so, you have to consider network issues and disk I/O on the BE. If<br>
your network connection is wireless, try (if possible, at least<br>
temporarily) a wired connection.<br>
<br>
Also, run something like this on the backend while watching something<br>
that has the freeze phenomenon:<br>
<br>
iostat -ktx 1 > iostat.txt<br>
<br>
When you see a freeze, make a note of the time. Then go look at the<br>
iostat.txt file, and look for the timestamp(s) where the freeze<br>
occurred. If you see your mythtv storage device at (or near) 100%<br>
utilization during this time, then you have the culprit (disk IO<br>
bottleneck). This is possible if, for example, you are trying to<br>
playback from the same disk that is also recording multiple streams<br>
and doing some kind of job (commercial flagging, transcoding, etc).<br>
Also, there's a chance the disk is going bad and timing out on reads.<br>
Do a "smartctl -t long <device>", wait however long it says, then<br>
"smartctl -a <device>" and see if anything looks suspicious.<br>
<br>
Note that the above iostat command dumps output every one second, so<br>
the file will grow relatively quickly---don't let it run indefinitely!<br>
<br>
If this turns out to be the case, the solution is more and/or faster<br>
disks, and/or increasing buffering on the client and/or server side<br>
(or a new disk if smartctl shows errors).<br>
<br>
Another thought: try doing an NFS mount of the BE's storage directory,<br>
and use an external player like mplayer or vlc to play your recording<br>
file. Does it exhibit the same behavior? This will help isolate the<br>
problem (is it MythTV specifically or something lower level?). I know<br>
at least with mplayer, you can set the buffer size. So if you see the<br>
freezing in mplayer, increase the buffer, and see if it still happens.<br>
<br>
Another tool I've found semi-useful for tracking down performance<br>
issues is "sar". On CentOS (and presumably Fedora), it's part of the<br>
"sysstat" package (not sure where it's found on other distros). But I<br>
set this up to be much more aggressive than the defaults, taking<br>
samples every five seconds. I'd suggest running this on both the<br>
frontend and the backend.<br>
<br>
If it's not disk IO, and sar doesn't show any obvious problems (e.g.<br>
CPU load), then you might also want to try running some network<br>
bandwidth tests. There are lots of tools for this... but it's not<br>
uncommon to have a bad wire or a switch overheating or a buggy NIC<br>
driver... at least check the obvious things first: duplex and speed<br>
settings via ethtool (e.g. one is configured 100/Full and the other<br>
1GbE/half will give you all kinds of grief). Also do a simple<br>
"ifconfig" and look for interface errors. ethtool -S will give you<br>
lots of low-level info, depending on the hardware and driver.<br>
<br>
I have never experienced the particular freezing issue myself, but the<br>
above are general tips that can hopefully track down and isolate the<br>
problem.<br>
<br>
> Any advice appreciated<br>
><br>
> On 1 Feb 2012 13:44, "Tim Draper" <<a href="mailto:veehexx@gmail.com">veehexx@gmail.com</a>> wrote:<br>
> FE is a 330 atom with ion & VDPAU enabled.<br>
> 2gb ram (2x 1gb iirc).<br>
><br>
> when i watch shows, that are over a certain size (1hour 5gb HD<br>
> recordings definitely do it, 40min 1.4gb files seem not to), i will<br>
> get random mini freezes of the video after a certain period.<br>
> the other night i was watching a 5.6gb recording, and it froze twice;<br>
> once around 25mins, and again around 50min area. rewinding and<br>
> replaying again does not re-produce that mini-freeze.<br>
><br>
> what i suspect is happening is the video is being buffered to RAM, and<br>
> it then gets wiped after a period (once ram is full?), which is whats<br>
> causing the freezing.<br>
><br>
> i have been SSH'd into the FE while a freeze occured. while i didnt<br>
> catch resource usage at that exact time, CPU and RAM utilization were<br>
> acceptable within 10-20 seconds either side of the freezing.<br>
> (mythfrontend process)<br>
><br>
> can anyone confirm/deny if my suspicions are correct, and what would<br>
> be an appropriate solution? more ram would be an idea, but due to the<br>
> atoms 3gb RAM limit, then i'd likely still see the freeze if it is<br>
> indeed down to a flushing RAM issue.<br>
> i know atoms arent highly recommended here, but i dont believe the<br>
> underpowered state is the issue here, else i'd be experiencing issues<br>
> alot closer together. HD playback seems fine for the shorter shows<br>
> (around 30mins), but freezes do occur for longer running shows (1h).<br>
> _______________________________________________<br>
> mythtv-users mailing list<br>
> <a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
> <a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/listinfo/mythtv-users</a><br>
><br>
><br>
> _______________________________________________<br>
> mythtv-users mailing list<br>
> <a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
> <a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/listinfo/mythtv-users</a><br>
><br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/listinfo/mythtv-users</a><br>
</blockquote></div>