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

Question about the 3400: Does it capture glitch-free from the live tuner? Or is it the same sketchy results that currently occur with the latest firmware on the 3416 and 6412?

In other news, I intend to upgrade the hard drive in my DCH3416 to 750 GB (I just happen to have an unused 750 GB SATA Seagate drive that I can use for it). Hopefully I can attempt this by the end of the week...I just have to wait until I receive the proper screwdriver "security bit" to unscrew those 3 wacky looking screws on the back. I'm not going to worry about the anti-tamper plastic thingy for now (and those can be ordered for $5 on the net).

I'd like to hear any input on this. I've got the DCX3450M and I can't capture recorded programs w/o the box going into a stuttering FF mode.

I'm having to keep a DCT3416 in another room solely for the purpose of firewire capture.

Good question. I'll try to test this soon. I only recorded 1 minute when I tried it.

I recently loaded firestb.msi software in XP MCE in an attempt to communciate with a Verizon Motorola QIP-6416 FIOS STB via a firewire connection. The channel change only works with the command "channel -v -f 2 C" where C is the channel number. However, mytray.exe does not work, presumably because it is using the "channel -v 2 C" command. Is it possible to modify the mytray.exe file so that I can communciate with the STB? Also, the MYTRAY app does not appear under "More Programs" in MCE 2005. Is there some way to add it to the "More Programs" so that I can record from within MCE? A copy of the response from the "channel -v -f 2 C" command is as follows:

Firewire STB channel changer V1.0.15, by timmmoore
Device 2 Channel 509 Timeout 100 Dec 0
1 "FireBus MPEG2TS Tuner Subunit Device"
'Motorola AV/C Tuner Device'
"@devicenp:\\\\?\\avc#motorola&qip-6416&typ_5&id_0#daae37feffdd1b00#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\\global" 0
2 "AVC Panel Device"
'Motorola AV/C Panel Device'

UniqueID 'daae37feffdd1b00'
VendorID '1bdd'
ModelID '7216'
VendorText 'MOTOROLA'
ModelText 'QIP-6416'
"@devicenp:\\\\?\\avc#motorola&qip-6416&typ_9&id_0#daae37feffdd1b00#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\\global" 0
3 'NVTV'
"@devicenp:\\\\?\\pci#ven_123f&dev_8120&subsys_01e210de&rev_b1#4&3b90381f&0&50f0#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\\capture" 0
4 'ATI DTV Wonder Analog AV Capture'
"@devicenp:\\\\?\\pci#ven_14f1&dev_8800&subsys_a1011002&rev_05#4&3b90381f&0&68f0#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\\global" 0
Device Id "Device Version "2.1.0"
Using alternative command 2
Response (0x09 (ACCEPTED)) received 5 bytes
09 48 7c 25 00
Response (0x09 (ACCEPTED)) received 5 bytes
09 48 7c a5 00
Response (0x09 (ACCEPTED)) received 5 bytes
09 48 7c 20 00
Response (0x09 (ACCEPTED)) received 5 bytes
09 48 7c a0 00
Response (0x09 (ACCEPTED)) received 5 bytes
09 48 7c 29 00
Response (0x09 (ACCEPTED)) received 5 bytes
09 48 7c a9 00
Calling tranport release
Called tranport release
Calling CoUninitialize
Called CoUninitialize


Here's the
Thanks for any help,
gtroan

Hey all, just an update on tests I've run.

I've been running a lot of firewire recording tests since the end of December and felt that I should share the results. Unfortunately, all of my complaints of a somewhat mild firewire bug in the latest 3416/3412/6416/6412 firmware have been proven, even when removing the PC from the equation and recording directly from the cable box to a DVHS digital high-def VCR.

I was very hopeful, based on what some others had posted, that I could record my problematic shows directly to DVHS and then dump it from there to my PC (utilizing different, possibly more stable drivers than the ExDeus/TimMoore drivers: meidvhs). But those shows exhibited the exact same level of glitchiness on DVHS that would have been seen when recording to a PC.. The glitches are on the tape and can be seen by playing it back and would look the same if dumped from DVHS to PC. This is yet more evidence that the problem is with the cable box as it is outputting to firewire. It is also more evidence that the problem has absolutely nothing to do with the PC or DVHS deck.

I tested this with 4 different DVHS decks: 2 JVC HM-DH30000U's, a Mitsubishi HS-HD1100U, and a Mitsubishi HS-HD2000U. The results were the same on all and were identical to what would occur when recording to a PC.

Through the course of testing this and testing my cable stb driver MSI install, I wound up installing the 32-bit releases of Windows 2000 Pro, Windows XP Pro, Windows Server 2003 Standard (only the original, I didn't bother with R2), Windows Home Server, Windows Vista Home Premium, Windows Server 2008 Standard (only the original, as R2 is not available in 32-bit), and Windows 7 Home Premium.

One thing that surprised me is that I never had any additional problems on the newer operating systems...despite common belief that Vista/7 should be avoided because it eats up too much hard disk I/O, I never once had this issue, even when testing on a laptop hard drive! (believe me, the only reason I threw a laptop hard drive in the mix is b/c I was impressed that I wasn't having any disk I/O problems and wanted to press the issue...to no avail.) Now, I'm not claiming that you couldn't encounter a hard disk I/O issue if the stars were perfectly aligned, but I did a TON of tests and never had it. Not even once. So while I'm disappointed that I don't have a foolproof workaround for recording glitch free from a few of my channels, I've come away with more respect for Windows NT 6 and am perfectly comfortable ditching XP and using Windows 7 32-bit full-time.

If anybody else has any additional information about any firewire glitching (or lack thereof), I'd love to hear it. I really don't want to give up looking for a good workaround, and I fear I'll be dead of old age before Motorola fixes their firmware.

So far, the best workaround I have is what I posted here over a month ago: When I encounter glitching, I first switch both tuners to SD channels (I use channels 8 and 9) and I then turn the cable box off for about 30-seconds. When the glitching is really really bad (10 or more frames dropped, and possibly dozens of Input Sequence Errors), this never fails to get rid of almost all of it.

After doing this I often find that I'll get a really small glitch within the next 10 or 15 minutes of recording, and then everything else records perfectly for an hour or more (sometimes for 3 or 4 hours straight). I don't know what the significance of that is, but it's an unmistakable pattern that I am seeing a lot. I'm even considering having my recordings start 15 minutes early just so I can consistently take advantage of this pattern without having to do any firewire babysitting.

Anyways, if anybody has any additional input, I would love to hear it. Also: I've noticed a lot of downloads of my firewire driver MSI install, but no suggestions on how it could be improved...While I am confident that the installation is of high quality and follows installation best practices, I would be surprised if there were no bugs/oversights, etc.

I have heard that using a solid state HD also may help fix stuttering..

Agreed, but my tests prove that stuttering has nothing to do with the problem. The glitching is coming *from* the firewire output of the cable box. Solid State drive or not, garbage-in, garbage-out.

Plus, if it were a stuttering problem, the issue would not also occur when recording from the cable box to a DVHS VCR.

I turn the cable box off every time before transferring recordings to my HTPC, because I have to boot into XP to do it. If I don't, it reboots the DVR. It also reboots when I put the PC into sleep mode, but I digress.

I can't say I've done any extensive studies on recent results, though I have a very difficult time getting them encoded to H264 with any consistency. Sometimes the audio will stay in sync using my usual work flow, other times I'll have to cut some off of the start, or remux first, etc.

Have you validated your recordings are all glitch free on the DVR itself?

Yes. It is what I call a "glitch" if it occurs only during firewire capping and is not part of the original transmission (meaning if you watch the recording play back on the DVR itself, you never ever see any glitching).

*It is important to note that the firewire glitching happens both when capturing from the live tuner and when capturing from a recording stored on the DVR. I have found no differences at all. Therefore you would be a fool not to record to the DVR, as running multiple captures would be the only way to guarantee that you could eventually get a perfect glitch-free capture.

Also: all of these glitches are random. If I perform 3 firewire caps in a row of the same DVR recording, there will be different amounts of glitching (none, if I'm lucky) each time and in totally different spots. And none of those glitches would be visible or audible if you were watching the TV during the captures.

This is one reason why I say the glitching is specific to the cable box firewire output. You never get it via the HDMI or the digital audio outputs or any of the analog outputs. Just the firewire.

In fact, when I first started having the issue (July 2010, as soon as the A28 and firmware updates hit), my lousy workaround was to use my Hauppauge HD-PVR to record using the analog component video and digital toslink audio. This works okay, because the glitching only impacts the firewire, but the quality is a far cry from the original MPEG2 transport stream (due to the Hauppauge having to perform analog-to-digital conversion and then compress it to MPEG4). In light of my newer workarounds which retain 100% quality, I now refuse to use the Hauppauge workaround. As far as I'm concerned, the only purpose such a device serves is to capture somewhat high-quality recordings from the protected channels (HBO, Showtime, Pay-Per-View, On-Demand). It softens the picture somewhat and sometimes ends up looking little better than a really good upconverted DVD, not that that's terrible, but still...

That's a good point that I hadn't considered. Most people probably do what you do. By the way, we have that very same A28 and firmware update to thank for the firewire reboot bug. And the reason I didn't use to power off is that my HTPC runs 24/7 and all sleep mode and power saving features are disabled. So the reboot bug didn't happen to me until I started plugging and unplugging cables in an attempt to figure out why the firewire glitching was occurring.



I outright refuse to do any h.264 encoding due to the type of crap you're seeing. Hard drives are unbelievably cheap, and the space savings of h.264 does not justify the drop in quality due to re-encoding IMO. For me, quality is of #1 importance and I will go to absurd lengths to preserve it.

I figure I should divulge as much info as I can think of so that this stuff isn't so spread out all over this thread...

The "firewire glitching" bug, as I call it, began with the Motorola A28 guide update (and accompanying firmware) which was released in mid-2010. I live just south of San Francisco and received the update in July (if memory serves). This same update is also responsible for your cable box rebooting whenever your HTPC restarts or when you plug/unplug the firewire cable. The A28 guide update also includes some nice stuff in it, such as the ability to search for shows. You can also set future recordings that will automatically occur if those shows ever appear on the schedule...I was pleasantly surprised that the Xtacles were auto-recorded on Adult Swim recently. Organizing your DVR recordings into folders is another nice feature of the A28 update.

The firewire glitching issue can not be seen when watching your cable box (either Live Tuner or DVR recordings). Everything viewed from the cable box will look the same as when you recorded it. The glitching can only be seen after you have finished capturing a recording and are playing it back on your PC/Mac or DVHS VCR (or any device you transfer it to such as a TVIX or Western Digital TV Live, Blu-ray disc, etc).

The glitching looks like dropped frames and massive pixelation. Each glitch is typically very short (just a second or two), but I've seen a few longer ones...maybe 10 or 20 seconds of missing or messed up stuff. These glitches happen randomly; If you capture the same DVR recording 3 times in a row, you will have glitching in different spots (or hopefully you'll get a perfect capture).

In order to discover where glitches exist, you either have to watch the captured recording or run a program to check the integrity of the MPEG-2 transport stream (which is obviously the easier less time-consuming way of doing it).

Since I already use VideoReDo TVSuite v4 to remove ads, I rely on it to tell me about any glitches. I'm sure that there are other (free) ways of going about this, but I don't know what they are (maybe MPEG2Repair?). I would really appreciate it if others would share how they go about this.

I used to always run VideoRedo's "QuickStream Fix" option in order to locate glitches, but I have since discovered that to be overkill. Just the mere act of having VideoRedo save the file (in order to cut out ads, etc) is enough for it to scan the file and alert you to any glitches.

Here's what the VideoReDo output looks like when firewire glitches are present:
VideoReDo_Output_with_Firewire_glitches.jpg
This example is more extreme than average, but I've seen worse. Now, given this information, there's no way to know where precisely those glitches occur...only that they are all in there somewhere. Maybe there is only one problem spot and it happens to be pretty big. But it is much more likely that there are 2 or 3 or more problem areas scattered throughout the recording. VideoReDo's log file can tell us exactly where the glitches are.

VideoReDo's log file is located in the "Application Data" folder. For Windows XP this could be "C:\\Documents and Settings\\TNO821\\Application Data\\VideoReDo-TVSuite4\\VideoReDo.log"

At the bottom of the log file will be information about the last thing that VideoReDo edited. Here's a snippet:

Input file: E:\\110113164844.ts
Output file: E:\\110113164844 (02).ts
Mode: Frame Accurate
TS Video packets: 9021951
TS Audio packets: 367551
TS PSI packets: 26062
TS Null packets: 0
TS MUX Rate (Mbps): 16.92951
-TS Discontinuities: 1
Video output frames: 78337
Audio output frames: 40839
Processing time (secs): 257
Processed frames/sec: 304.22
Actual Video Bitrate: 10.11 Mbps
* Audio frame errors: 2
* Input Sequence Errors: 2
* Video resync frames removed: 9

2011-01-13 19:11:29 Displaying output complete dialog: 0

Notice the last few lines mention 2 Audio Frame Errors, 2 Input Sequence Errors, and 9 Video Resync Frames Removed. That's the same type of high-level (birds-eye view) information that the output dialog also reveals. It still doesn't tell us exactly where these errors occur or how many spots in the video are impacted by them.

For the detailed info, we need to look just a tiny bit higher up in the log file were some ultra-detailed info is recorded. Here's what that looks like:

2011-01-13 19:07:33 Adding new graph range, Start: 27094 (00:00:27.04), End: 161865.08 (00:02:41.50)
2011-01-13 19:07:34 XXCount: 0, Real: 1 0
2011-01-13 19:07:53 Resync: removed 8 video frames, at video 00:01:58.28, original (00:02:25.08), sync changed from -2753.33 to -33.98
2011-01-13 19:07:55 Starting new Frame Accurate Output Segment: start:307073.444 (00:05:07.06), end:669505.544 (00:11:09.30)
2011-01-13 19:07:55 Preparing to send status to: 0 Audio volume changed
2011-01-13 19:07:57 Sending status: 'Audio volume changed' to module: 'Output muxer - 0', Type: Video frame
2011-01-13 19:07:57 Preparing to send status to: 0 Audio volume changed
2011-01-13 19:07:57 Sending status: 'Audio volume changed' to module: 'Audio recoder - 0', Type: Audio frame
2011-01-13 19:07:57 Adding new graph range, Start: 307073 (00:05:07.06), End: 669505.54 (00:11:09.30)
2011-01-13 19:07:58 XXCount: 0, Real: 1 0
2011-01-13 19:08:09 AC3 (Unpacked2) Audio Frame Error 1 at: 00:06:02.25, Maxretries: 32000
2011-01-13 19:08:57 XXCount: 0, Real: 1 0
2011-01-13 19:08:57 Starting new Frame Accurate Output Segment: start:889605.400 (00:14:49.35), end:1191493.678 (00:19:51.30)
2011-01-13 19:08:57 Preparing to send status to: 0 Audio volume changed
2011-01-13 19:08:57 Sending status: 'Audio volume changed' to module: 'Output muxer - 0', Type: Video frame
2011-01-13 19:08:57 Preparing to send status to: 0 Audio volume changed
2011-01-13 19:08:57 Sending status: 'Audio volume changed' to module: 'Audio recoder - 0', Type: Audio frame
2011-01-13 19:08:58 Adding new graph range, Start: 889605 (00:14:49.35), End: 1191493.68 (00:19:51.30)
2011-01-13 19:08:59 XXCount: 0, Real: 1 0
2011-01-13 19:09:39 Temporal frame drop, at: 00:11:18.20, originalPTS: 1073238.84 (00:17:53.14), frame type: 3, temporal: 12 (2)
2011-01-13 19:09:39 AC3 (Unpacked2) Audio Frame Error 2 at: 00:17:52.28, Maxretries: 32000
2011-01-13 19:09:39 Temporal frame drop, at: 00:11:18.20, originalPTS: 1073255.53 (00:17:53.15), frame type: 3, temporal: 13 (2)
2011-01-13 19:09:39 Resync: removed 1 video frames, at video 00:11:18.20, original (00:17:53.04), sync changed from -156.32 to 43.89
2011-01-13 19:10:01 Starting new Frame Accurate Output Segment: start:1316727.278 (00:21:56.40), end:1827512.400 (00:30:27.29)
2011-01-13 19:10:02 Preparing to send status to: 0 Audio volume changed
2011-01-13 19:10:02 Sending status: 'Audio volume changed' to module: 'Output muxer - 0', Type: Video frame
2011-01-13 19:10:02 Preparing to send status to: 0 Audio volume changed
2011-01-13 19:10:02 Sending status: 'Audio volume changed' to module: 'Audio recoder - 0', Type: Audio frame
2011-01-13 19:10:03 Adding new graph range, Start: 1316727 (00:21:56.40), End: 1827512.40 (00:30:27.29)
2011-01-13 19:10:03 XXCount: 0, Real: 1 0
2011-01-13 19:11:28 XXCount: 0, Real: 1 0
2011-01-13 19:11:29 AudioRecoder thread complete. Stream: 0, Audio Frames, In:40842, Out: 40839
2011-01-13 19:11:29 Graph, monitoring thread received terminate signal.
2011-01-13 19:11:29 Graph monitoring thread finished.
2011-01-13 19:11:29 Output muxer processing thread complete. Video in: 78337, Out: 78337, Buffer: 0
2011-01-13 19:11:29 Output muxer processing thread complete. Audio stream 0 In: 40839, Out: 40839, Buffer: 0
2011-01-13 19:11:29 Muxer add / delete audio: stream: 0, add: 0 delete 0, sync: -16.01
2011-01-13 19:11:29 Output complete.

I've put the detailed error messages in italics. You can see that there are several areas in this video that are impacted by the firewire glitches:
1 min 58 sec
6 min 2 sec
11 min 18 sec

Now, being that this was only an 11 and a half minute Adult Swim show, having three different problem areas in such a short recording is really quite bad. And I would not even consider trying to splice around those three problem areas...that would be way too much effort. I would instead run my trick of changing both cable box tuners to SD channels (I use 8 and 9) and powering the cable box off for 30 seconds. I would then try capturing it again and hope for the best (In my case, this particular channel is not one of my glitchier channels, so it's nearly guaranteed to record glitch-free the second time).

If repeated attempts continue to have glitches (and if I really really want that recording), I will bite the bullet and perform splicing. But that truly is a pain in the ass, so I try to avoid it.

Hopefully this gives everyone a fairly good idea of how I determine how much and where the glitching is.

Thoughts? Suggestions?

Wow, I just recently started having trouble recording our local city programming in Calgary, and I wonder if they rolled out A28 here right when the trouble began (start of 2011).

I have copies of our City Council sessions on my PVR. My "live" firewire recordings (CapDVHS) are now too glitchy to be parsed by ProjectX or cleaned up by mpeg2repair... I mean it is a 14GB file I simply can't make use of.

So I'd like to try pull the data off the PVR again, except playback of a recording results in that FFWD lossy glitchy video. I can't even parse captions out of it (reliably).

Since the PVR starts FFWDing when I start recording with CapDVHS or VLC, I assume the app/driver is telling the PVR "hey I'm starting to record now!"

Is there anyway to simply monitor or record off the firewire port without telling the PVR you're about to start recording? Like read-only communications from the PC side? Isn't the cable box constantly shitting its current video output out the firewire port and all I want to do is monitor the port?

What model of Motorola cable box do you have?

Your description of symptoms do not sound like the much milder problems I'm discussing. Also, the A28 update comes with some fairly obvious new features. When you hit the My DVR button, do you see the "Search & Record" option? Do your recorded shows get organized into folders? For example, I have 4 episodes of Conan on my DVR but rather than show each one on a separate line, it shows one line that says something like "Conan - 4 Episodes". If I click on that line, it takes me into the folder and shows me the 4 episodes.

If you've had those features for a while, then the A28 update is not new.

Here's how you can check the software and firmware version:
On your remote, hit Menu and choose Menu > Setup > Cable Box Setup > "Configuration: Select to Display"
At the top of the "Review Configuration" screen, you'll see the "S/W Ver" field. If you have the A28 update, you will see A28 somewhere in this field.

It is possible that you now have a newer firmware and/or software version than I have, and that Motorola may have made more changes that further degrade the firewire functionality

Please let us know your S/W version and Firmware version.
Example:
My S/W ver is 78.53 - A28p0-4.1005.r-8
My Firmware is 18.77
I'm using a Motorola DCH-3416



Whoa! Do you literally mean that your cable box begins fast forwarding the show as soon as you hit record in CapDVHS? If you watch the cable box during the capture, do you see it doing this? (or see FF appear on the front of the cable box?) That is way worse than the firewire glitching that I'm talking about.

This sounds a little bit like the bug on the Motorola DCX3400, but I don't think that the DCX has ever had working firewire...it's been too royally screwed up for anyone to record from (unlike the DCT and DCH 6412/6416/3412/3416).

As for your question about not letting the cable box know you're recording, there's no way to do that.

MPEG2Repair is certainly useful for checking a file after capture. I also occasionally get a capture that VideoRedo won't even open, so I usually run that one through HDTV2MPEG, just remuxing is usually fixes things, sometime I end up clipping 5-10 frames off the front.

You're a lot more patient than I am about re-capturing to get a perfect copy. I've typically just been living with the glitches, a lot of what I capture is college sports, so they don't bother me too much. I don't watch a lot of TV shows or care to archive them, and movies are almost always either cropped, edited or have annoying pop-up ads and huge channel logos.

I'd like to hope Motorola can fix this, but my fear given their history with this firmware is the "fix" may end up causing even worse problems.

I understand your comment on re-encoding. While hard drives are cheap, they also fail. I had one die on me and lost a bunch of stuff I hadn't backed up. The H264 versions are smaller and can be typically backed up to a DVD-R.

After thinking about it, I'm convinced you must have the Motorola DCX3400, which has really really broken firewire. I don't think I've ever heard of someone with that box successfully performing a firewire capture (I've never used one, so I'm just going by what I read at this site).

I just had an idea that seems way too easy (this would have been tried and posted if it worked)...but what the hell: Have you tried hitting the play button on your remote as soon as the cable box begins fast forwarding?

My understanding of the DCX3400 is that it begins fast forwarding as soon as you tell CapDVHS to begin recording...so, if you immediately use your cable box remote and hit the play button to override the fast forward command, maybe it'll continue at a normal speed.

Again, seems way too obvious, but worth a shot.

I've had that problem with VideoReDo (where it refuses to even open the file), and just found a great workaround a week ago:
When VideoReDo refuses to open a file (usually with a No Data Found error message), go directly to the Tools menu and choose QuickStream Fix. Then, from the QuickStramFix menu, browse to the problematic file.

It's super counter-intuitive, being that I used to only choose QuickStream fix after opening the file, and never really considered that I could choose it before.

Before discovering this, I used to use Simple File Splitter to divide the problematic file into chunks (usually I'd get rid of the first and last chunk). I'd then use Simple File Joiner to recombine them. Using QuickStream Fix is SOOOO much faster

If by "patient" you mean "clinically obsessed", then I agree
And, now that I think about it, I nearly never watch or record movies from cable (I'm a big Blu-ray proponent and formerly a bigger HD DVD proponent)
I think that if I were in the habit of recording things longer than 1 hour, the glitching would be a much bigger nuisance.


Sadly, I fully expect that based on their track record.


Understood, and this is a big reason that I burn quite a few BD's.

Yeah, I'm aware of quickstream fix but it seems to me the times I've had problems it couldn't open the file either. And HDTV2MPEG seems faster. *shrug*

Reminds me of another issue I had, Comcast was dropping in 1080i/30 commercials on some 720p/60 stations like ESPN. VideoRedo was having an awful time dealing with that. That's one case where I had to do a chunk-by-chunk capture like you've done. Awful.

I think the latest version of VideoReDo v4 has made changes to QuickStream Fix. I don't think you'll ever get a "Could not open file" type of error. Now what it does is scan the entire file for any video content and if it sees multiple resolutions, it gives you a dialog where you can choose which resolution to keep.

I've only had this situation twice in the last couple of months, and I recall that it displayed a dialog with two "radio buttons" (one for 1080i and one for 480i) and asked which resolution I wanted to keep. Since it's a radio button, you can pick only one of the resolutions...everything else gets junked. Anyways, it worked really well. But the unintuitive trick is that you have to open VideoReDo and choose QuickStream Fix from the Tools menu *before* opening the problematic file (b/c any attempt to open the file results in an error message such as "No Video Data Found" since the file is too f'd up). It sure would be nice if that "No Video Data Found" error dialog would include a button to launch QuickStream Fix on the problematic file.

FYI: The reason I sometimes encounter these mixed-resolution files is that I'll sometimes forget to set a reasonable timer on CapDVHS and it'll capture for longer than my DVR recording...if I'm capturing a 1080i show and both of my tuners happen to be on 480i channels, that'd do it. (my tuners are now almost always on 480i channels when I'm capturing, as I try to minimize the firewire glitching).



Wow, that's bad! I haven't seen that particular issue. And I don't think I'll ever have to do that awful chunk-by-chunk editing again, now that I know QuickStream Fix can do it far more easily.

Yep, I've been running the latest beta versions of VideoRedo, even those couldn't handle some of the frame rate changes. I'm sure they'll get it figured out eventually.

Hello -

I have a Mot DCH3416 with Comcast. I am not new to capturing IEEE from a Motorola box using timmore drivers and CAPDVHS, etc. - I did it years ago with a different HD Mot box. I have all the proper drivers, etc. installed.

Here is my problem with this box:

I can't get Windows XP SP3 to even recognize the box. On two separate computers, one with an IEEE VIA chipset, and the other with a NEC chipset, neither will cause the computer to go through the PnP "found new hardware" process. (6 Pin IEEE cable).

I can take the same cable and from either computer, plug it in to a firewire hard drive and it works just fine - so, I don't think I have a bad cable or a bad PC interface.

I'm starting to think that the firewire controller in the Mot. box is hosed up somehow, or maybe the firmware is disabling IEEE output on the box.

Also, I get IEEE Enabled but not Active in the status display on the box.

Any suggestions?

TIA for any help!

PS My mother, living next door, has a different Mot HD box and I will drag my laptop over there and try it (after Super Bowl Sunday of course!)

Does this box only have 1 firewire connection? I've heard you must have 2 like the older boxes to avoid glitches. I found this out to be true when I tried to dub over to dvhs from a friend's box that only had 1. Recording was useless. I still have older model that works okay with Verizon.

Thanks for the reply! This box has 2 IEEE connectors.

Oops sorry, I thought you were replying to me.

Has anyone had success with the Cisco RNG200? I haven't been able to get it work once. Almost every time I recieve "Cannot start capture: 80070057"

One time I recieved a BSOD from the STB driver when trying to start a capture from CapDVHS.

Running on Windows 7 32-bit with legacy firewire driver.

Any help would be super.

anyone having success with fios' moto 7232-P2?

I probably shouldn't be saying anything, since I'm not on FIOS.

But last I heard this is essentially the same latest generation box as the Motorola DCX3400 family (used by TWC and Comcast and others).

As such, it's a "1-port firewire" version. All previous Motorola boxes for the past 9 years up until this latest generation have been "2-port firewire" construction. This really shouldn't have anything to do with the success or failure of the firewire interface, if the firmware was modified appropriately, but it appears that the entire generation of 1-port boxes HAS A BROKEN FIREWIRE INTERFACE.

So whether you're trying to record (a) from DVR to DVHS VCR (e.g. JVC DT100U or DH5U or 40K or 30K) or (b) from DVR to WinXP PC, to the best of my knowledge nobody anywhere has reported genuine 100% reliable results... either with the FIOS version or TWC/Comcast version of these latest Motorola models.

For this very reason, many users (including myself) have retained DCTxxxx or DCHxxxx or QIP62xx boxes (all 2-port models), which are 100% reliable for firewire recording.

Still no solution from Motorola, I'm afraid, more than a year after this hardware first became available in the field. Truly sad.

By this point, more than enough people have weighed in to prove that the DCH boxes no longer can be considered to have 100% reliable firewire recording.

With the A28 update and corresponding firmware, it's 90% reliable at best and dependent on several factors. Comcast engineers recently boosted my signal (which helped quite a bit for a few of my channels), but the firewire is nowhere near 100% reliable. The older firmware was not nearly so picky about the signal and gave 100% reliable firewire caps.

My 2-port DCT6412-Phase III is not reliable either.

Its been a while (7/25/2010) since I've done 1394 recording with my DCT3416 because I moved to Win7x64 and dont like to reboot just for recording. I wanted to extract some content and now it seems total broken. I see in another thread that some bugs like the STB rebooting when starting XP can be worked around.

My issue now is major stuttering when recording HD video. I've noticed when capturing at 38.8104 Mbps that it slows down every second and then speeds up. Is there something that can be done about this?

I've noticed that I now get sound when recording and it doesn't turn off video to the TV which is good. The curious thing is sometimes it works fine and that only occurs at standard def or when it shows recording at 20 Mbps. I do not know why I see 20 Mbps sometimes and 38.8104 a majority of other time.

If there is something to do the 20 Mbps all of the time that would be cool as well.

Edit: After more testing and editing it appears that MPEGVCR will mostly fix the stream stuttering when resaving the video which solves that problem.

Yes, it is widely known that the firmware which accompanied the A28 update has caused several problems with firewire on the DCT and DCH cable boxes. One problem is that the cable box reboots when you either plug or unplug the firewire cable (this happens when plugging or unplugging both DVHS VCR's and computers alike). Another problem is the firewire glitching bug, which is possibly what you are experiencing.

Do you mean it slows down and then speeds up when you play the recording back on your PC? Or are you just referring to the CapDVHS dialog that displays the stats while capturing?

You're referring to a very old DCT/DCH bug that would cut off the audio and video during firewire captures...that bug was fixed long ago.


The cable company controls which bitrate is used for each channel. There's nothing you can do to control it. I haven't really looked closely at the bitrates of channels where I get frequent glitching vs. those that don't...It is possible that higher bitrates causes more of the firewire glitching, but that's purely speculation on my part. I'll have to do some testing to see if there is any pattern there.

Sorry, there isn't.