> > The Iomega BUZ seem kinda cool, but they don't seem to > > sell it anymore: > > The MAC version is the PC version, with MAC software (both have PCI > bus).... > > People are working on versions with the Matrox Video card that has the > Zoran MJPEG chip on it also... The Miro DC10+ now also has drivers... however if you can afford itwait for the Matrox drivers to appear. It is a *pain* not having a tuner on-card. I lost count of the number of times some minor househould glitch lost or disturbed a capture. All it takes is a cat sitting on a remote (or a dumb cat-owner pressing the wrong remote) and... bye bye "Lexx" and hello "Sports quiz gameshow" ;-( My experience in setting a Digital VCR rig up has been that it is very easy to underestimate the "minor logistical issues" and level of reliability required to make the whole thing work adequately. Capturing a 90+ minute movie or even a 50 minute series episode to disk exposes all kinds of minor warts you'd never notice otherwise. Unhappy experiences (solved) - Forget VIA VPx motherboards. The PCI implementation is too flaky / too mismatched to the Zoran. Here a frame gone there a frame gone. The ATA UDMA drivers for VIA are also not really up to the grade either... - Get a good mature sound-card with mature drivers. Much gnashing of teeth until I spent a few $ on an OEM AWE64. On-motherboard sound is often (audibly) rotten... - Dedicate a machine. Drivers and/or hardware are not up to handling a general-purpose load *and* a video stream capture. Even with liberal use of process priority... Any kind of X windows activity seems particularly poisonous. Whether thats because multiple process can suddenly become runnable, a paging load, or the screen driver spending significant time with interrupts locked I don't know. Again, perhaps Alan or other folk with kernel know-how might be able to shed light on this phenomenon. Unhappy experiences (not fully solved) - Put bluntly: ext2 is not good for video capture (I'll bet the TIVO guys are writing direct to disk not via an FS). Ext2 has an evil habit of wandering off to do surges of head-rattling house-keeping for longish periods of time when a big file is closed. Presumably it is updating its block trees. Net result: a 0.5M/sec video stream cannot always be streamed without loss on a 20M/sec hard-disk because usually you have to split over multiple files. Once > 2G I/O stuff hits the maintstream and/or the new FS come on line this should become a non-issue but in the meantime it is a pain.... Again, those with kernel knowledge might be able to shed light and/or advice. My experience is that it is *just about* adequate if you keep the partion no more than 1/2 full, and regularly empty it. A regularly emptied (and hence defragged) VFAT works tolerably as well. I also tried ReiserFS and that seemed better but there the problems with NFS bit me. As a work-around this weekend's programming chore is to modify the MJPEG capture tools to pre-allocate and then over-write the capture files. That should hopefully work around ext2's limitations. Happy experience The MJPEG mini playlist editor/previewer "xlav" is the ultimate "Ad remover". It just does the basic job easy and simple and reliable, every time. Andrew
