or Connect
AVS › AVS Forum › HDTV › HDTV Recorders › How to record via IEEE 1394 (Firewire) to Windows XP
New Posts  All Forums:Forum Nav:

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

post #5821 of 6013
Quote:
Originally Posted by tluxon View Post

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.

I honestly would reinstall Windows if I were you. That is not a commonly seen error and indicates serious problems (I'm a software consultant that specializes in installation design and particularly Windows Installer). You would be getting a different message if it were a simple matter of insufficient permissions...your error indicates that the Windows Installer OS service has incurred substantial damage.

Now, you say that nothing else you throw at it causes the error, but I have no way of knowing what percentage of that stuff is in the Windows Installer .MSI format. Having consulted on the technology for 12 years, I am shocked at how much software still doesn't use it (granted, it is a bit complex...but legacy installer technologies simply can not get the job done safely, period). So I propose a test: Run another .MSI and see if the same message is generated. I recommend FreeUndelete, which is one of the few file undelete utilities that uses a Windows Installer .msi: http://www.officerecovery.com/freeundelete/

I expect that you'll get the same 1719 error result. My FireWire .MSI package is using almost no "custom actions" and is very strictly following Windows Installer best practices. Frankly, the amount of table-editing required to do that almost begs the question why didn't I use ORCA to create it from the ground up...Answer: I used to work for Wise and just sort of wanted it to be a Wise .msi. The next version most certainly won't be (it will be InstallShield, for basically the same reason).

So, why is the .msi installation better than grabbing the driver files and using the command line or Device Manager to manually install it? One word: Rollback.
Windows Installer is transactional and will roll off any changes if an error is encountered. So with a properly authored .MSI installation there are only two possible installation states: fully properly installed, or not at all installed.
If a manual installation (or legacy installation, such as Inno Setup, WiseScript, InstallShield ISScript, Nullsoft Installer, etc.) bombs out mid-way through, they just take their ball and go home; your machine is therefore left in a quasi-installed state where there typically is not enough logging/info available to do better than guessing at what has been altered and needs to be changed back. This is why no legacy installer is *ever* allowed on my systems...if it isn't .MSI it will become .MSI by my hands.

If you'd like for me to review your MSI log file, I will. To generate the log file, open an Administrator Command Prompt and type the following:
MSIEXEC.EXE /I "" /L*v "C:\\wherever\\Logfile.log"

This will produce a (perhaps largish) .log file that will have a lot of information in it (depending on how far into the install it gets before crapping out). /L is the logging command and the * means to log everything and the v means to be verbose, giving a *lot* of detail. This is something that is beyond legacy installations (and obviously manual installations) and gives the information needed to trace back the problem to its root, though sometimes it's like looking for a needle in a haystack.

I think reinstalling Windows is the smartest thing long-term (my assumption being that this indicates other underlying problems and that a fresh reinstall is ultimately a time saver vs. endless disparate troubleshooting). But if there are no other indications of trouble, perhaps this issue is a one-off impacting only the Windows Installer service (doubtful, but possible). I would recommend performing the steps outlined here (this article is for Vista, but the same steps can be used on Windows 7).

Quote:
Originally Posted by tluxon View Post

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?

Yes, these will work with Windows 7 32-bit.
post #5822 of 6013
Well reinstalling windows no for this driver is kind of extreme and may in fact cause more serious problems for the user, depending on their knowledge of windows and techinical capability. If they just have 1 big partition with the OS and all of their personal files (tax forms, movies, kiddie photos/videos, software, etc...) and they reformat the drive while re-installing windows, they may not be very hapy to find that OMG now the driver works, but all my important **** is gone........

Cant they just unpack the installer package or use the ExDues zip to manually install the driver, then downgrade the Win7 firewire stack, and grab CapDVHS from videohelp.com?

That would be a hell of a lot quicker for them to test firewire capping, and they can surely go ahead and re-install windows over christmas holiday AFTER they get it working, or not.
post #5823 of 6013
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).
post #5824 of 6013
Quote:
Originally Posted by TNO821 View Post

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).

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?

Anyhow, if the MSI isnt working for some reason and you dont want to re-install Windows but want to try capping, I would suggest downloading the ExDues package located at http://home.comcast.net/~exdeus/stbfirewire/ and try following the instructions to have a go at it. 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.

This is a simple zip file with CapDVHS and the drivers. Nothing fancy and no installer-which you really do not need for this application.
This is what I have always used on Windows side.

Let us know how it works out or not for you.
post #5825 of 6013
Quote:
Originally Posted by qz3fwd View Post

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?

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).


Quote:
Originally Posted by qz3fwd View Post

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.

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.
post #5826 of 6013
TNO, does your installer allow WMC to see the STB as an "eligible" tuner, and thus use it to record?
post #5827 of 6013
Quote:
Originally Posted by huesmann View Post

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

I know that it allows Arcsoft Showbiz to see it as an eligible capture device, but I'm not sure if WMC can use it. I kind of doubt it b/c WMC would not be able to change the channel (I think) and could only capture from whatever channel the cable box was tuned to.

I'll try and test this in the next few days.
post #5828 of 6013
Quote:
Originally Posted by TNO821 View Post

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.

just replaced my dct6412 box with dcx3425 box having issues with driver is there any driver update for this new box? thanks
post #5829 of 6013
Quote:
Originally Posted by dargo View Post

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

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.
post #5830 of 6013
Quote:
Originally Posted by TNO821 View Post

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.

Thanks will take it back to comcast hope they still have the DCT box's
post #5831 of 6013
Quote:
Originally Posted by dargo View Post

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

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.
post #5832 of 6013
If you guys didn't already know, premium channels seem to be unlocked during a free preview weekend, at least with FiOS which is what I have. Right now is a free preview weekend for Showtime.
post #5833 of 6013
Quote:
Originally Posted by DSperber View Post

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.

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.
post #5834 of 6013
Quote:
Originally Posted by dargo View Post


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.

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.
post #5835 of 6013
Quote:
Originally Posted by TNO821 View Post

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.

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.
post #5836 of 6013
Quote:
Originally Posted by dargo View Post


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.

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.
post #5837 of 6013
Quote:
Originally Posted by dargo View Post

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

Placebo effect.

Call me a doubting Thomas, but in my mind HDMI is HDMI. It's a digital delivery system (with MPEG-2 data exploded into uncompressed bits, so the same MPEG-2 data will explode into the same bitstream no matter what box does it).

The exploded bitstream then gets delivered to the HDTV via HDMI cable. The HDTV will see exactly the same exploded bitstream no matter whether it was a Motorola DVR or Tivo that did the MPEG-2 decoding, since the MPEG-2 data itself is identical being delivered from the same cable system over the same infrastructure.

That's what makes it "digital". It's there, or it's not. You don't need to spend $1,000 on a "high-end HDMI cable". You can use a $10 one, and get the same results. The HDTV sees the identical bitstream arriving no matter who exploded the MPEG-2 stream and delivered it digitally to the HDTV via the HDMI cable.

At least that's how I see things. Should be exactly the same image on your HDTV display, assuming you didn't adjust anything else of a video nature.

Now... go with component video (i.e. analog) HD? Entirely different story. But HDMI? Zero difference.
post #5838 of 6013
Quote:
Originally Posted by TNO821 View Post

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.

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.
post #5839 of 6013
Quote:
Originally Posted by dargo View Post

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.

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,
post #5840 of 6013
Quote:
Originally Posted by TNO821 View Post

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,

I always had some frame drops over firewire but with the tivo over ethernet perfect. one hour show takes about 1:30 transfer
post #5841 of 6013
Quote:
Originally Posted by dargo View Post


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

1:30...an hour and thirty minutes? Ouch, but if it contains no glitching, it's worth it!
post #5842 of 6013
Quote:
Originally Posted by TNO821 View Post

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,

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.
post #5843 of 6013
Quote:
Originally Posted by dargo View Post

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

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?
post #5844 of 6013
Quote:
Originally Posted by qz3fwd View Post


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.

That's the $64,000 question: Can the TiVo transfer software work with the Comcast/ TiVo boxes?
post #5845 of 6013
Quote:
Originally Posted by qz3fwd View Post

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?

nope gigabyte ethernet, but i'm not complaining about the speed
transferring files from pc to pc is very fast but i doubt tivo has a gigabyte
speed card in them.
post #5846 of 6013
Quote:
Originally Posted by TNO821 View Post

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

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?
post #5847 of 6013
Quote:
Originally Posted by JDLIVE View Post

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?

Yes, but the ethernet, usb, and sata ports are DISABLED on pretty much all cable systems in the USA!
post #5848 of 6013
Quote:
Originally Posted by qz3fwd View Post

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

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.
post #5849 of 6013
Quote:
Originally Posted by TNO821 View Post

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.

Follow the money. More like why would they want you to be able to create and playback a vast archive of content on your own devices (think NAS, external HDD) when they can sell you those same "services" such as VOD, PPV, premium channels.

If you can rip a DVD/BD and simply sttream it through LAN to the STB then playback on your TV that would "compete" with their paid services and you and I know they are deathly afraid of competition and becoming simple bit shufflers in the marketplace and thats why they stiffle innovation and drag their feet on deploying new technology which the consumer has been wanting and is readily avaliable for many years.

Call me cynical.
post #5850 of 6013
Forgive me if I'm asking a redundant question, but I have not been able to find the answer yet.

Here's what I'm working with:
Windows XP Home SP3
Cisco CHS435HD dvr from Verizon

Here's my story:

I just switched to Verizon FiOS from Comcast this past weekend. I previously had a Motorola DCT6412 and, for the past few years, was able to use CAPDVHS to capture from it with relative ease. So, after the new FiOS install on Saturday, started searching for ways to record from the new Cisco DVR. I found this thread and successfully updated my firestb.inf file. My new Cisco dvr is recognized in Device Manager. BUT, I keep getting the dreaded "80070057: cannot begin capture" error from CAPDVHS. Am I missing something? I'd really like to get this up and running and I feel like I'm so very close. Any ideas? Thanks for the help.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: HDTV Recorders
AVS › AVS Forum › HDTV › HDTV Recorders › How to record via IEEE 1394 (Firewire) to Windows XP