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