On Wed, Jan 18, 2006 at 09:43:37AM -0800, Yeechang Lee wrote: > 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.
That's fine, myth still will perform schedule recording updates from time to time for a number of reasons. Disk space auto expiring, commercial detection start/finish, etc. > > 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. It's what scans for program guide info on HD channels. > > 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. No, you just need to outsmart the IO problems on your system. It's not about what you throw at it, but how. > > 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?) Each HD tuner card can have a custom ring buffer size, this has nothing to do with the live-tv buffer. I'm not sure about firewire input though. > > 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 . . . May try some different NFS options or look into how your ethernet card buffers data. > > 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.) Odd, I'd expect this to not be a problem if you're using a remote file server. This may help myth devs though in fixing the problem. If you're getting IO Bounds on write, and you're using a remote filesystem then it's backing up on ethernet/NFS. I don't have a reponse, just a bunch of hmms for this. > > 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). cron jobs could cause problems, depending on which distro you run. Nightly updatedb's or other tasks too. > > 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. Hmm... > > 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. It's an IO issue. There's something in Myth that is not playing nice with system IO. It's brought out when scheduling takes place usually. Sometimes a large delete or a massive write can cause this. It only happens if the Myth can't get IO for writing for half a second. As it happens right now, this problem does occur. There's a bug in the bug tracking system that you can add addition info to, to help locate and solve this. I opened the bug when losing 5-15 minutes per hour of recording. After ditching reiserFS (I was using it to test as for the two years before I used XFS/JFS) and additional work from Daniel the loss of data went to about 5 seconds per 100 hours of HD recording. I currently can record 4 HD shows and watch one without any problems. Since it's been working fine the bug was closed. I'd recommend re-opening that bug and add in the info you've found, and/or try some of the profiling and debugging options mentioned in that bug to help locate what the exact problem is for you. --Brandon _______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
