<div><span class="gmail_quote">On 1/17/06, <b class="gmail_sendername">Brandon Beattie</b> <<a href="mailto:brandon+myth@linuxis.us">brandon+myth@linuxis.us</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Tue, Jan 17, 2006 at 05:11:08PM -0500, Michael Haan wrote:<br>> I understand what you're saying. The first thing I would note is that this
<br>> is QAM not satellite so trees etc aren't the issue. The machine is an AMD64<br>> 3800+ writing to a raid 5 array. Granted, the array is software raid, but<br>> watching live HD, my cpu hangs around 10-20%, so I think it's fine. So, I'm
<br>> trying to figure out what to look at next. One final point: watching HD<br>> through the HD3000 I get occasional pixelation but if I then switch over and<br>> watch the same channel through firewire, there is no pixelation. Just seems
<br>> like that points the the card.<br><br>QAM can have even more problems than OTA, it just depends. Do you use<br>any splitter, powered splitter, or amplifier? Do you have a cable<br>modem? Any one of those can cause attenuation or interference. The
<br>fact that the cable box doesn't have problems could be that it has a<br>better QAM tuner, or that it just works better for your specific cable<br>provider. I'd recommend calling the cable company and have them do a<br>
quality check (They can do this from remote and free of charge). Also try<br>disconnecting any splitters or cable modem and see if this helps. The<br>pcHDTV HD-3000 has had the best success in tuning the various types of
<br>QAM, so I'm not sure what else to recommend if you want a PCI HD tuner,<br>but if firewire works perfectly, go for that. :)<br><br>Also just so it's known, you can have the best system, raid 10, and<br>still get corrupted video. There are a few things that can cause
<br>this. The update scheduled recordings task is nasty in Myth... and Mysql<br>can be nasty too. I see (Weekly) a single recording lose data when<br>it spawns this task. There has been a lot of time spent on tring to<br>
make this less severe. I actually spent about 40+ hours with Daniel and<br>others down to the point of profiling the kernel to help improve this<br>problem. To keep this from being as bad:<br><br>Don't ever think about using ReiserFS. Some disk accessing is slow
<br>first of all, such as deletes. If you delete a large file it can keep<br>the disk from writing for several seconds, by then Myth drops data.<br>Also, reiserFS does not handle large files very well. Combine a many GB
<br>file and a directory holding 1+TB of data in it and you're really going<br>to have problems. You don't see this as bad with few large files in a<br>directory.<br><br>Don't put your recordings directory on the same disk as where MySQL
<br>stores the DB for mythTV. You can lose data when mysql is using the<br>disk and doesn't let the mythfilewriter thread save data to the disk<br>before it's taken too long and discarded the data.<br><br>A few signs (But not always there when problems do happen and data is
<br>lost) are IO Errors/IO Bound. Notices that it's taking too long to read<br>data from the HD card, or you can enable debug and get a half dozen<br>other errors that will show up when you have a thread struggling for<br>
resources.<br><br>You also can see these problems with a CPU at 95% idle. You can watch<br>for the actualy system load, or the system io usage to help you see if<br>this is too high and causing problems, but problems do happen even when
<br>this is low because the time between updates for top and other apps<br>doesn't check fast enough to always see the io problems that could cause<br>data to be lost.<br><br>--Brandon<br>_______________________________________________
<br>mythtv-users mailing list<br><a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
</a><br></blockquote></div>
<div> </div>
<div>Yes, there are two splitters between the source and the card - there is also a cable modem and an amplifier. You may be right that this is an attenuation issue but the 3000 in the same rig with the same setup worked almost flawlessly under a previous gentoo incarnation so that makes me suspicious. I am using reiser (just as I was before) - I could try switching that but I'd need a recommendation for what to use.
<br> </div>