Brandon Beattie <[EMAIL PROTECTED]> says: > Every time a recording, transcode, commercial detection, and so on start > or finish the recordings table is updated.
The IOBOUND errors I mentioned that are occurring at five-minute multiples (and one-minute multiples before I changed the "check every x seconds" setting in the backend from the default) occur independent of any recording starts or stops. As previously mentioned I have set commflag jobs to only occur in the early morning, and I never do transcode. > If you use EIT monitoring with a HD tuner than every time this > finishes it can cause the recording scheduler to be re-run. Sorry, don't know what EIT monitoring is; I use FireWire with my HD cable boxes. > Adding RAM will not help at all. This is purely a system and disk IO > issue. This both gladdens my wallet while dimming my hopes for always-pristine (subject to the vagaries of cable provider compression) HD recordings regardless of circumstance. > Also, the PCI bus can be occupied and cause data from the card to be > lost if the system IO can't be freed up quick enough to handle the > data. HD tuner cards have a rather small cache on them. If > anything occupies the system IO longer than 500ms then you risk > losing data from the HD tuner, and Myth and the scheduler does this > at times. Hmm. If it's not a swapping issue, perhaps I should turn the ringbuffer size on the frontend back up to the maximum? I thought that only applied to Live TV. Is there a separate ringbuffer setting I am not aware of in 0.18.1? (Live TV is set to record locally, but I wonder if maybe it's better to trade network bandwidth for disk IO bandwidth and set it to go to the same place the recordings go to?) > The best way to fix this? Keep the drive for the database on a > different disk than one used for recordings. Done. I keep the database on a local SATA drive, but the recordings go to an Infrant 600 2TB over gigabit Ethernet . . . > Use XFS or JFS. . . . and which uses ext3, not JFS (as I use pretty much everywhere else), as its filesystem. (Although the Infrant folks use straightforward md-compatible RAID on the 600 [and even their proprietary X-RAID on the X6 is md-readable], I think they've tweaked with the ext3 filesystem code a bit. When I delete a recording, the system gives me back control as quickly as when I recorded to my JFS-based RAID array, but only for a split second; then there is a distinct 'hang' for a few moments as the deletions occur. And yes, this does cause a few bursts of IOBOUNDs when I am doing HDTV recording at the time.) > Make sure nothing else IO intensive is running when the schedular > runs. That's easy; the MythTV box doesn't do anything else but MythTV, and the Infrant is going to be dedicated solely to Myth (at least once I've moved my remaining non-Myth video collection off it). > Intel based systems have less of a problem than AMD from what I've > seen (Intel systems with hyper threading that is). Check that; the MythTV box is a 3.0GHz Pentium 4. > Reiser is a good choice though for the filesystem holding the > database, since it does a better job with sub GB size files. = Like I said, I am using JFS pretty much everywhere else, and that includes the MythTV box's local disk. I wonder if this is a latency issue? Unfortuantely I can't tweak up the latency on my PCI Express gigabit Ethernet card with setpci; I've tried. -- Yeechang Lee <[EMAIL PROTECTED]> | +1 650 776 7763 | San Francisco CA US _______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
