How to record via IEEE 1394 (Firewire) to Windows XP - Page 195

Originally Posted by tluxon

I'm not sure if I'm getting a defective download or something, but this installer package will not install on my Win 7 32-bit installation. I keep getting Error 1719 (Windows Installer not accessible), but it doesn't seem to have a problem installing and/or uninstalling everything else I throw at it.

Originally Posted by tluxon

So I guess that leaves me with the Tim M. Moore firestb driver package that I've used for WinXP. Is that suppose to work with Windows 7 32-bit as well? Or do I need something else?

Originally Posted by TNO821

Yes, attempts can be made to manually install the driver. But it would not be particularly easy breaking down my .msi package to do it (ripping open an .msi can be a bit esoteric...the main criticism of the technology is that it's rather involved and there exists nearly zero books that delve into it...on the other hand, all of the other installation technologies are overly simplistic and end up causing the majority of Windows non-malware problems).

But at the first signs of "this isn't working", I would abort before it becomes a time-vampire. FireWire capping can be plagued by Windows instability...many troubled systems that refused to FireWire cap suddenly work beautifully after an OS reinstall. Bad filter drivers seem to be particularly troublesome, and many legacy uninstallers do not properly fully remove drivers when you uninstall software (yet another case where Windows Installer is superior).

Originally Posted by qz3fwd

TNO-What does you MSI package do other than install the AVC driver, dump maybe CapDVHS onto the desktop, and maybe downgrade 7 firewire drivers?

Originally Posted by qz3fwd

Take care of which firewire port the cable is connected to on the DVR, at one time it was suggested you could only use one of the 2 ports on the back of the DVR.

Originally Posted by huesmann

TNO, does your installer allow WMC to see the STB as an "eligible" tuner, and thus use it to record?

Originally Posted by TNO821

It follows all Microsoft software installation best practices, something that even most Microsoft installations fail to do. This includes using only Windows Installer "standard actions", except for edge cases where the standard actions are unable to get the job done (cases where complex logic needs to be used, querying hardware, etc). These standard actions are built into the Windows Installer service and automatically back everything up before altering your system. In the event of a fatal error or user-cancellation, rollback restores your system to its original state (this is more thorough than System Restore).

The main idea behind the Windows Installer is to get people and software vendors away from using error-prone manual (scripting cowboy) free-for-all installs that follow no rhyme or reason. There aren't 23 different "best" ways to install a file, or modify the registry, or install a service, or install a driver. More importantly there isn't *any* "best" way for a non-.MSI to safely uninstall a registry value, service, or driver (any non-file resource can not safely be handled outside of an .MSI). There literally isn't. It. Can't. Safely. Be. Done. Anyone that claims otherwise doesn't fully understand Windows software installs (and, more importantly, uninstalls).

Why does this matter? Try a case study. A friend of mine got a new PC a few months back and proceeded to download dozens of freeware apps, most of which she didn't need and pretty much never used. Later she decided to uninstall a bunch of them (not a great idea, as hard drive space was not an issue). Her machine became painfully slow...not unstable per se (blue screens and .DLL hell have largely been mitigated by MS), but just getting Windows Explorer to fire up took waaaayy longer than it used to. It turns out that most of those freeware apps had awful legacy installers that ignored many best practices (the most important being to *always* and *only* use Windows Installer technology). Using the Sysinternals ProcessMonitor tool revealed that Windows was trying to fire up an Explorer shell extension that was no longer there (the app that installed it failed to properly unregister it upon uninstall). Long story short, we could have spent a lot of time hunting down and correcting all such nonsense, or we could spend half a day and back up files and cleanly reinstall the system (this time resisting the urge to go the all-you-can-eat route with freeware apps).

My .MSI package has very few "custom actions". One is needed in order to locate the Windows 7 "legacy FireWire" driver* (the folder which contains this driver changes with each service pack of Windows). Another pair of custom actions, known as DIFx (the Driver Install Framework), comes from Microsoft and is used to safely install/uninstall drivers (complete with Rollback in case of failure). As mentioned earlier, this works better than System Restore which has been known to throw young children out with the bath water.

Note: I have nothing against freeware apps, other than their generally laughably inept installation routines. I use quite a few freeware apps, rewriting their install routines to use .MSI. I merely pick on them because they tend to on average have worse installation routines than other apps.


*Windows 8 no longer has and no longer needs the "legacy" FireWire driver. If you install my v3 FireWire .MSI package on Windows 8, it will warn you at the end that it could not locate the legacy FireWire driver and that CapDVHS will likely fail unless it is installed...ignore that message. Windows 8 (32-bit only, of course) does not need the legacy FireWire driver and works perfectly fine for FireWire capping. I'll eventually update and release a v4 FireWire package that detects Windows 8 and prevents the warning message from displaying (it'll also add a lot of updates for newer cable box models).



This is not true. It makes no difference which FireWire port you use. Somebody posted that it did and people have repeated it ever since. I have conducted many many tests with numerous different Motorola DVR's and have never once had better or worse results depending on which port I chose (though I suppose that there could have been a small run of defective boxes released). I have tested the DCT-6412, DCT6416, DCH-6412, DCH-6416, DCT-3416, DCH-3412, and DCH-3416...none of them cared which FireWire port was used.

Originally Posted by dargo

just replaced my dct6412 box with dcx3425 box having issues with driver is there any driver update for this new box? thanks

Originally Posted by TNO821

You're not having issues with the driver, you're having issues with the DCX! Those things are awful. Upgrade to a DCH or DCT. The DCX is an abysmal mistake, rife with long standing unaddressed bugs. It can't even record stuff reliably.

Originally Posted by dargo

Thanks will take it back to comcast hope they still have the DCT box's

Originally Posted by DSperber

Given a choice, you should try to get a DCH3416 if you can. Newer, better, faster, smaller, cooler, quieter... and is the best alternative to a new DCX model.

Just remember that the hard drive in the old DCT/DCH boxes is either 120GB or 160GB, not the much larger 320GB or 500GB you'll find in DCX boxes.

Also, the DCT/DCH units do not have "native" output over HDMI if you wanted that feature, so you have to pick a fixed output resolution (720p or 1080i) from the DVR for everything sent to the HDTV. You then manually have to use the FORMAT button on the DCT/DCX in order to manually change back and forth between 720p or 1080i depending on the source program, if that's important to you and you have an HDTV that provides improved display of 720p delivered "native" rather than being up-converted to 1080i by the DVR.

But... the DCT/DCH units do both "speak firewire properly" to an outboard recording device like PC or DVHS VCR.

Originally Posted by dargo


They had none of the DCT box's had to special order one so I got a cablecard for my tivo HD this is the way to go, if it is reliable I drop the cable box altogether. I can transfer shows over Ethernet easier than firewire.

Originally Posted by TNO821

I think this sounds like a smart move. Another thing to consider: if you're on Comcast you can get a Comcast box loaded with TiVo software (at least in the SF Bay area, not sure about other areas). I assume the Ethernet show transferring would also work on those.

Originally Posted by dargo


well so far cablecard is working fantastic! I heard so many horror stories about getting them up and running but for me it was quick and easy, no harder than a cable box. plus i feel the picture over hdmi looks a bit better than my old cable box.

Originally Posted by dargo

...plus i feel the picture over hdmi looks a bit better than my old cable box.

Originally Posted by TNO821

Yeah, I'm glad it worked out for you. I think the only reason to care about the whole TiVo-on-Comcast-hardware is that you wouldn't lose On-Demand/PPV capability. I'm pretty sure that On-Demand doesn't work with cablecard (please correct me if I'm wrong).

Also: If you could try out the TiVo ethernet show transferring and let us know how that works out, you'd be my new hero! I am so close to getting a TiVo and my uncertainties about show transferring is all that's holding me back.

Originally Posted by dargo

On-Demand/PPV does not work, not a big deal for me as it's all covered in DRM anyway as is my showtime channels which i can't transfer off, transfer video over ethernet is perfect if a bit slow, files are .tivo which video redo handles fine. as for the picture hdmi is hdmi true but i do feel the video processor/chip set is giving me more detail and better color. but i'm willing to concede that it might be all in my head. i think by the time comcast calls me to pick up the old dct 6412 box i will cancel the box and stay with the cablecard which is a multistream card can record two shows at once.

Originally Posted by TNO821

Very nice! Even though ethernet transfer of shows might be slow, I'm doubting it's slower than the real-time recording + having to redo sections that suffer from Motorola FireWire glitching!

Sounds like I'll be grabbing a TiVo sometime in the near future,

Originally Posted by dargo


I always had some frame drops over firewire but with the tivo over ethernet perfect. one hour show takes about 1:30 transfer

Originally Posted by TNO821

Very nice! Even though ethernet transfer of shows might be slow, I'm doubting it's slower than the real-time recording + having to redo sections that suffer from Motorola FireWire glitching!

Sounds like I'll be grabbing a TiVo sometime in the near future,

Originally Posted by dargo

I always had some frame drops over firewire but with the tivo over ethernet perfect. one hour show takes about 1:30 transfer

Originally Posted by qz3fwd


He has a regular retail Tivo model, not a Motorola DVR loaded with Comcasts Tivo software correct?

Anyhow, I dont think the Comcast Tivo software includes Tivo Transfer functionality? That would be kinida cool. Maybe I should call Comcast and see if they offer the Tivo software on my Motorola box.

Originally Posted by qz3fwd

Something is wrong with your setup. My S3's all transfer at better than realtime, maybe 35-45 minutes / hour of content. Anyhow, just queue up TivoTransfer and let it run overnight if you have a lot of content to transfer, fire up VideoReDo, edit out the crap, and export as a DRM free transport stream.

You should get better than realtime transfer.
Let me guess-are you are using a wireless network?

Originally Posted by TNO821

That's the $64,000 question: Can the TiVo transfer software work with the Comcast/ TiVo boxes?

Originally Posted by JDLIVE

Not 100% sure, but I don't think it does. Do the Motorola DVRs even have ethernet? Probably can ask on the Tivo Community boards?

Originally Posted by qz3fwd

Yes, but the ethernet, usb, and sata ports are DISABLED on pretty much all cable systems in the USA!

Originally Posted by TNO821

Yeah, I've had it explained to me that the cable companies don't like the idea of single point of failure...they avoid making use of the (I think they call it MOCA) ethernet technology built into the cable boxes b/c if that box fails, you lose cable TV, internet, and your home phone (if you're a Comcast Xfinity Triple Play customer). I'm not sure if that's the real reason, but it does seem to make sense to me.