Originally Posted by TNO821
Okay, but I was getting the impression that you were disputing that any code change whatsoever had gone into the firewire portion of the A28 firmware. In other words your DCH doesn't reboot when firewire is connected/disconnected and you aren't seeing any glitching.
I honestly don't know if there was a code change in A28 relating to the firewire interface. Personally I would have expected those changes to be in firmware, not Guide software, but maybe the relevant code is in both places.
Anyway I am confirming that I have NEVER seen a DCH (or DCT before that) reboot relating to firewire recording to DVHS (first JVC 40K and now DT100U). My firewire cable is permanently connected, but the VCR is almost always powered off. And the VCR is tuned to L-1 when it's not being used for firewire recording. I used to use L-1 to pass-through DirectTV analog TV to my TV, but I've now discontinued DirectTV so my use of the VCR for this purpose is now zero. And I find myself recording from DVR to DVHS very very rare these days, since TWC has marked EVERY CHANNEL as "copy-once" making subsequent copies to PC impossible. I now find that the copy-once things I care to keep on DVHS for posterity are few and far between.
My experience has always been that problems of controlling the DVR and other anomalies pertaining to DVR behavior and performance are completely tied to the VCR being tuned to I-1 (and therefore "listening" to the DVR, and trying to "keep up" with channel changes, FF/REW, and 30-second skip forward or 15-second skip backward, etc.). Even if the VCR is powered off, if it's tuned to I-1 then it is actively part of the "firewire relay" topology (and could actually relay data from a source device to a target device through its two firewire connectors) and is essentially "powered on and active" from the perspective of the DVR. I've decided that it is in these situations where doing things "too fast" on the DVR (really, just perfectly normal control operations... but the VCR connected via firewire just can't keep up) is what causes havoc either on the DVR or on the VCR, sometimes requiring re-boot of either by pulling power cords.
Only tuning the VCR to something other than I-1 can the DVR be guaranteed to behave in true "standalone" performance mode. These DVR and VCR anomalies can be totally prevented by just "removing" the VCR from the firewire relay with the DVR, by tuning to L-1 (or really just anything other than I-1), even leaving the firewire cable still connected.
So you're just saying that your way of doing things prevents the firewire reboot bug from being an issue.
Correct. If and when I actually do want to offload something from DVR to VCR, I do it VERY SLOWLY AND CAREFULLY getting started, ensuring that the VCR is "synced up" (by monitoring the output of the VCR on my HDTV to ensure picture/sound, before restarting the DVR recording playback from the beginning and pushing REC on the VCR).
Note also that I never record anything "live" from the DVR onto the VCR. My habit is simply to record something on the DVR, decide later than I want to keep it, and then subsequently eventually offload it to DVHS. So I'm only creating DVR->DVHS copies from previous DVR recordings, and never "live TV".
I have 4 DVHS VCR's (2 JVC 30000's, a Mits 1100 and a Mits 2000) and I loaded the MEIDVHS drivers on a fresh WinXP SP3 (back in Dec) and got identical results with glitching on my DVHS tapes.
I've never owned a Mits DVHS machine, nor have I owned that 1st-generation 30K.
I went from a 0th-generation Panny combo (DST50/PV-HD1000) and Dish HDTV Modulator to a JVC 40K, and now DT100U's (three of them). Perhaps the firewire recording stability and glitch-freeness has improved with later generation JVC machines. But I've not had a signal strength issue with my TWC/LA situation, and I use a 3-way splitter. The Ceton card in my HTPC on one of those three split coax legs reads about -10db to -13db depending on channel, which appears to at least adequate for the Ceton card (and apparently also for the DCH3416 on another leg).
There was no difference vs. what I would typically see using the STB drivers and connecting directly to my PC. Now maybe the MEIDVHS.zip file I downloaded was different than what you use.
Could you post the drivers you're using so that I can test using them?
I'm sure we're using the same MEIDVHS driver. It's dated back in 2001, so I'm certain there's nothing "more current" about my version.
I only use that one because it had been suggested to me many years back, instead of the more "robust" STB driver that theoretically could support DVHS VCRs as well. I may have been having some problems getting things to work early on, learning about CapDVHS, etc., and thought going to a DVHS-only driver would be appropriate for my DVHS-only recording setup. Apparently it must have worked fine, and I'm just still using it after all these years. No reason to tamper with success.