How to record via IEEE 1394 (Firewire) to Windows XP - Page 185 - AVS Forum
Forum Jump: 
 
Thread Tools
Old 02-28-2011, 05:40 AM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by dr1394 View Post

Maybe it's time to change my username. Looking back at my e-mails with JVC, I haven't really worked on 1394 since August of 2005.

BTW, with my development platform, I can capture streams 100% error free for hours and hours from a DCH3200 here on Comcast in Silicon Valley.

Ron

I'm not familiar with the DCH3200. So you've not seen any change in firewire capture with the A28 guide update and firmware (circa July-ish)? Which channels do you capture? I mostly get the glitching with TBS, FX, IFC, AMC, and Comedy Central (but almost never now when I do my capture "Ritual"). I nearly never get glitching with the OTA networks, even if I skip the ritual.

Do you at least get the firewire stb reboot bug? If not, the firmware on your STB may be totally different.

I just looked up the DCH3200 and it appears not to be a DVR. And I would guess that it doesn't even have a hard drive in it...I would expect some fairly significant variance in the firmware, so it wouldn't really surprise me if it were immune to the problem.

What does that mean, your "development platform"? Do you get glitching on other setups?
TNO821 is offline  
Sponsored Links
Advertisement
 
Old 02-28-2011, 09:22 AM
AVS Special Member
 
dr1394's Avatar
 
Join Date: May 2002
Location: Mizar 5
Posts: 3,180
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 23 Post(s)
Liked: 21
Quote:
Originally Posted by TNO821 View Post

What does that mean, your "development platform"?

I was the development engineer at LSI Logic for the IEEE1394 portion of the SoC used in the JVC 40K, 5U and DT100U D-VHS decks.

I did all my firmware development on an in-house platform that supports every function of the SoC (which is why it's such a large board with many support components).



The gadget on the left is a Lexar 1394 CF card reader that's plugged into the same 1394 bus as the cable box. It acts as a 1394 disk drive. I use a 16GB card for my captures.

It's a super stable setup. It never ever reboots the cable box which is always plugged into the board (the gray 1394 cable in the upper left).

Ron

HD MPEG-2 Test Patterns http://www.w6rz.net
dr1394 is offline  
Old 02-28-2011, 11:26 AM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by dr1394 View Post

I was the development engineer at LSI Logic for the IEEE1394 portion of the SoC used in the JVC 40K, 5U and DT100U D-VHS decks.

I did all my firmware development on an in-house platform that supports every function of the SoC (which is why it's such a large board with many support components).

Very cool! So that board in the picture is connected to your computer via the white 1394 cable in the upper left?


Quote:
Originally Posted by dr1394 View Post

The gadget on the left is a Lexar 1394 CF card reader that's plugged into the same 1394 bus as the cable box. It acts as a 1394 disk drive. I use a 16GB card for my captures.

Forgive my ignorance, but how does the cable box know what to make of the Lexar CF card reader? Or is that handled on the PC end of the 1394 bus? (I'm assuming that a PC is connected at some point, but I guess it could all be controlled by your special board)

That is really cool, but my major concern/interest is figuring out if your Motorola cable box is immune to the firewire bugs that are hitting the DCH341x and DCT641x units. So far there are two big differences between your setup and others I've seen: 1. I have no experience with the DCH3200 and 2. your setup is many times more awesome than what I've seen (which is standard cable box-to-PC or cable box-to-DVHS VCR). Either one throws a lot of variables...does your unique setup side-step what would otherwise trigger the firewire glitching, or is the DCH3200 not impacted by the glitching (being a non-DVR cable box makes me wonder). Or maybe you just have God's-gift-to-Comcast-signal-strength or some such (After Comcast engineers boosted the signal of some channels in my area, I've seen a very noticeable drop in glitching...but it's still nowhere near zero on some of my channels unless I follow my "Ritual")

Quote:
Originally Posted by dr1394 View Post

It's a super stable setup. It never ever reboots the cable box which is always plugged into the board (the gray 1394 cable in the upper left).

Do you know if it would reboot under more ordinary circumstances? Have you tried having the DCH3200 directly connected to a DVHS VCR (I assume you have a JVC DVHS VCR) or PC? I would be interested in knowing if it reboots the cable box when you plug/unplug a DVHS VCR or when the PC reboots.

Thanks for sharing information on your setup!
TNO821 is offline  
Old 03-01-2011, 06:10 AM
AVS Special Member
 
dr1394's Avatar
 
Join Date: May 2002
Location: Mizar 5
Posts: 3,180
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 23 Post(s)
Liked: 21
Quote:
Originally Posted by TNO821 View Post

Very cool! So that board in the picture is connected to your computer via the white 1394 cable in the upper left?

No, the white 1394 cable is connected to the Belkin 1394 hub on the floor and then the CF card reader is connected to the hub with the clear cable. The PC is connected to the board with the gray serial cable and the orange Ethernet cable. The Ethernet connection is just to download the VxWorks operating system kernel to the board. I could burn everything to Flash ROM for a completely stand alone system (like it would be in a real product), but it's easier to just use the Ethernet download.

The serial port is the control interface. I just use a terminal emulator on the PC. Here's a dump of the terminal emulator during a recording session. I've made some comments denoted by "<-----".

Code:
JEDI  128 - MICRON_MT46V32M16_6T  VxWorks:1.2 BFI:020.4 
Copyright (c) 1984-1995 Wind River Systems, Inc.

DRAM test (reduced) ... Ok.


                            VxWorks System Boot


Copyright 1984-1998  Wind River Systems, Inc.


CPU: JEDI  (E52)
Version: 5.4
BSP version: VxWorks:1.2 BFI:020.4
Creation date: Jul 10 2007, prebuilt


Press any key to stop auto-boot...
 1
 0
auto-booting...


boot device          : ln
unit number          : 0 
processor number     : 0 
host name            : host
file name            : /Tornado/target/proj/galileo_8003/default/vxWorks
inet on ethernet (e) : 10.0.0.5
host inet (h)        : 10.0.0.1
user (u)             : anonymous
ftp password (pw)    : none
flags (f)            : 0x8 
target name (tn)     : dmn3

Attached TCP/IP interface to ln0.
Attaching network interface lo0... done.
Loading... 1203984 + 156944 + 21925816
Starting at 0x10005000...

JEDI  BAL Version VxWorks:1.2 BFI:020.6 
Booting VxWorks ...
Attached TCP/IP interface to ln unit 0
Attaching interface lo0...done

Adding 4858 symbols for standalone.


 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
      ]]]]]]]]]]]  ]]]]     ]]]]]]]]]]       ]]              ]]]]         (R)
 ]     ]]]]]]]]]  ]]]]]]     ]]]]]]]]       ]]               ]]]]            
 ]]     ]]]]]]]  ]]]]]]]]     ]]]]]] ]     ]]                ]]]]            
 ]]]     ]]]]] ]    ]]]  ]     ]]]] ]]]   ]]]]]]]]]  ]]]] ]] ]]]]  ]]   ]]]]]
 ]]]]     ]]]  ]]    ]  ]]]     ]] ]]]]] ]]]]]]   ]] ]]]]]]] ]]]] ]]   ]]]]  
 ]]]]]     ]  ]]]]     ]]]]]      ]]]]]]]] ]]]]   ]] ]]]]    ]]]]]]]    ]]]] 
 ]]]]]]      ]]]]]     ]]]]]]    ]  ]]]]]  ]]]]   ]] ]]]]    ]]]]]]]]    ]]]]
 ]]]]]]]    ]]]]]  ]    ]]]]]]  ]    ]]]   ]]]]   ]] ]]]]    ]]]] ]]]]    ]]]]
 ]]]]]]]]  ]]]]]  ]]]    ]]]]]]]      ]     ]]]]]]]  ]]]]    ]]]]  ]]]] ]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]       Development System
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]       VxWorks version 5.4
 ]]]]]]]]]]]]]]]]]]]]]]]]]]       KERNEL: WIND version 2.5
 ]]]]]]]]]]]]]]]]]]]]]]]]]       Copyright Wind River Systems, Inc., 1984-2000

                               CPU: JEDI  (E52).  Processor #0.
                              Memory Size: 0x7fec000.  BSP version VxWorks:1.2 BFI:020.6.
                             WDB: Ready.
-> fwmain                                     <------ start the 1394 stack
1394 SW package initialization
Cfg Rm Euid Hi = 0x805ee5, Euid Lo = 0x8 
TestBufInit() - MblkInit Successful PoolId 0x5
SubUnitBufInit() - MblkInit Successful PoolId 0x6
TestAppTask() - Busreset Start received
SBP-2 Initiator Test Driver V1.00
Sbp2irBufInit(): MblkInit Successful PoolId 7
Systop memory = 17fee000
Self node id = ffc2
SBP2 task created
value = 0 = 0x0
-> Sbp2:Bus Reset Complete..
TestAppTask() - Busreset Complete received
---------------------------
Number of nodes (including quiet nodes) = 0x4
Number of nodes (excluding quiet nodes) = 0x3
Node Id Eui_hi          Eui_lo
0x0     0x0030ffb4      0x0000abf3             <------ CF card
Node Id Eui_hi          Eui_lo
0x2     0x00805ee5      0x00000008             <------ the board itself
Node Id Eui_hi          Eui_lo
0x3     0x001bddff      0xfe9168ba             <------ DCH3200 cable box

-> sbp                                        <------ start the CF card "drive"
I have Euid As Hi = 0xd00101, Lo = 0xa70c 
Press 1 if you want change them or 0 otherwise :1
Enter Euid Hi:30ffb4
Enter Euid Lo :abf3
Set Euid As Hi = 0x30ffb4, Lo = 0xabf3 
StatFifoProc: Zero Length Command
StatFifoProc: Zero Length Command
AtaInit: Sync Sem received
Pread: Sync Sem received
No of Heads & Sectors per Track are SET as 10, 3f 
Block Size and Number of Blocks on the Device are : 200, 1e87eff
Login success
Offset : 3f
usrATaConfig success
value = 0 = 0x0
-> cd "TG2:"                                  <----------- cd to the CF card
value = 0 = 0x0
-> ll                                         <----------- "dir" equivilant
-rwxrwxrwx  1 0       0        2147462712 Feb 17  2011 test0.ts 
-rwxrwxrwx  1 0       0        345621456 Sep  2  2010 squid1.ts 
-rwxrwxrwx  1 0       0        168749552 Jan 26  2011 drinky1.ts 
-rwxrwxrwx  1 0       0        351684644 Feb  6  2011 clock.ts 
-rwxrwxrwx  1 0       0        464080444 Feb 17  2011 test1.ts 
-rwxrwxrwx  1 0       0        318634056 Jul  6  2010 squid.ts 
-rwxrwxAwx  1 0       0        953376012 Dec  3  2010 VS422.TS 
value = 0 = 0x0
-> chkdsk                            <-------- mostly just to set the system time
TG2:/  - disk check in progress ...

WARNING : dosChkLib : system clock is being set to MON FEB 21 00:00:00 2011
Value obtained from file system referenced by volume descriptor pointer: 0x17fea998
The old setting was THU JAN 01 00:00:04 1970
Accepted system dates are greater than FRI JAN 01 00:00:00 1999

TG2:/  - Volume is OK 

          total # of clusters:  500,098
           # of free clusters:  355,146
            # of bad clusters:  0
             total free space:  11,098 Mb
     max contiguous free space:  11,236,048,894 bytes
                   # of files:  7
                 # of folders:  0
         total bytes in files:  4,529 Mb
             # of lost chains:  0
   total bytes in lost chains:  0
value = 0 = 0x0
-> apilockopcr 3,0x3f,1          <----- tell node 3 (the cable box) to start sending on channel 0x3f at 200 Mbps
ulStat = 0x00000000
LockRequest result = 0x80008178
value = 402088620 = 0x17f762ac
-> ira 0x3f                      <----- listen on isochronous channel 0x3f
Rx Channel Allocated Context = 0x102c3660 
value = 0 = 0x0
-> ll
-rwxrwxrwx  1 0       0                0 Feb 21 00:02 test0.ts 
-rwxrwxrwx  1 0       0        345621456 Sep  2  2010 squid1.ts 
-rwxrwxrwx  1 0       0        168749552 Jan 26 00:00 drinky1.ts 
-rwxrwxrwx  1 0       0        351684644 Feb  6 00:01 clock.ts 
-rwxrwxrwx  1 0       0        464080444 Feb 17 00:25 test1.ts 
-rwxrwxrwx  1 0       0        318634056 Jul  6  2010 squid.ts 
-rwxrwxAwx  1 0       0        953376012 Dec  3  2010 VS422.TS 
value = 0 = 0x0
-> irs                           <------ start recording
IsoTestBufInit(): MblkInit Successful PoolId 8, pBuf = 11487ed0
pMblkStart = 0x11487eb0
0x17f76688 (tShell): Iso Rx Init = 0x00000004
value = 0 = 0x0
-> bytes = 11438484              <------ indicate progress
bytes = 21655908    
bytes = 34369220    
bytes = 49254684    
irr                              <------ stop recording
IrCmpCb1 :Channel Is released; !! 
pMblk Start = 0x11487eb0
pMblk End = 0x1147e8b0
IrCpFreeCb :Free status =0 
value = 0 = 0x0
-> ll
-rwxrwxrwx  1 0       0         52597324 Feb 21 00:02 test0.ts 
-rwxrwxrwx  1 0       0        345621456 Sep  2  2010 squid1.ts 
-rwxrwxrwx  1 0       0        168749552 Jan 26 00:00 drinky1.ts 
-rwxrwxrwx  1 0       0        351684644 Feb  6 00:01 clock.ts 
-rwxrwxrwx  1 0       0        464080444 Feb 17 00:25 test1.ts 
-rwxrwxrwx  1 0       0        318634056 Jul  6  2010 squid.ts 
-rwxrwxAwx  1 0       0        953376012 Dec  3  2010 VS422.TS 
value = 0 = 0x0
->
Basically, it's a little manually driven DVR.

Ron

HD MPEG-2 Test Patterns http://www.w6rz.net
dr1394 is offline  
Old 03-01-2011, 08:56 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by dr1394 View Post

No, the white 1394 cable is connected to the Belkin 1394 hub on the floor and then the CF card reader is connected to the hub with the clear cable. The PC is connected to the board with the gray serial cable and the orange Ethernet cable. The Ethernet connection is just to download the VxWorks operating system kernel to the board. I could burn everything to Flash ROM for a completely stand alone system (like it would be in a real product), but it's easier to just use the Ethernet download.

That is really cool...so the PC itself is nowhere in the 1394 chain. And I also assume that there are no DVHS VCR's anywhere in the 1394 chain. So my guess is that (if you have the A28 Guide update) your DCH3200 is likely using almost the same firmware as my DCH3416 and would reboot if you hooked up a PC or DVHS VCR without first powering the DCH3200 down. I would expect it to behave no better or worse than my cable box.

I have been doing some capture tests these last couple of days that are leading me to believe that the firewire glitching is triggered by a marginally low signal strength. On Sunday I came to find that, try as I might, I couldn't get any firewire glitching to occur (a pleasant surprise, but very unexpected). So I decided to stop performing my "ritual" or changing both tuners to SD channels and powering off before running a capture. I went on to perform a lot of captures, none of which had any firewire glitches (and, while this is impressive, most of the captures were of broadcast networks...those nearly never glitch even on my worst days. But there were several captures from cable channels also).

Yesterday I continued capturing without performing my ritual and everything was coming up glitch-free until I captured something from Cartoon Network (8 Input Sequence Errors, 6 Video Resync Frames Removed...not horribly glitchy, but still unacceptable). I then performed my ritual and it captured glitch free the second time.

The big difference is that Comcast engineers boosted the signal to my area recently. The signal had, for a while in mid Jan - mid Feb, gotten so bad that it was starting to cause noticeable video glitches while watching TV (never mind capturing anything). It didn't impact every channel, but there were a sizeable number of channels that had real obvious issues. And once Comcast boosted the signal, all of those problems went away...and apparently the lions share of my firewire glitches went with it.

So it would appear that the latest firmware is for some reason more sensitive to the signal strength than the older firmwares.

Now, before everybody having firewire glitching issues gets too excited and calls Comcast to boost their signal, I tried that last year shortly after the A28 update hit the Bay area. Guess what? They didn't boost jack. If the Comcast employee that comes to your home can't see an obvious picture problem (they know nothing of firewire), the best they'll do is cut off the ends of your CAT6 cables and re-crimp stuff and dick around with the cable bringing the signal into your home. That's it. If the signal is within their specs, they aren't going to contact engineering and have them tweak stuff. The only reason my signal recently got boosted is because it finally dropped to the point that errors were impacting the ability to watch quite a few channels (video glitches would be seen every 10-20 seconds in many cases...In that situation it's easy for the Comcast employee to see that a true problem exists and get engineering to work on it).
TNO821 is offline  
Old 03-02-2011, 06:44 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
I was doing some capture tests with my Mitsubishi DVHS VCR's and found that plugging and unplugging the firewire from them to the DCH3416 did not cause the cable box to reboot.

I thought some other(s) had said that their DVHS VCR's had been causing the same type of reboots that PC's cause...this appears not to be the case for me.

Has anybody seen a situation where connecting anything via firewire other than a Windows PC causes the cable box to reboot? (Mac, DVHS VCR, or otherwise)
TNO821 is offline  
Old 03-02-2011, 07:13 PM
Senior Member
 
teague's Avatar
 
Join Date: May 2001
Location: Irvine, CA USA
Posts: 351
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by TNO821 View Post


Has anybody seen a situation where connecting anything via firewire other than a Windows PC causes the cable box to reboot? (Mac, DVHS VCR, or otherwise)

I use a Mac Pro desktop and a MacBook Pro laptop for captures. Both are very reliable at captures. But after a firmware update some time ago, both cause the cable box to reboot when I power them up or down. Before that firmware,, they both worked fine. Even now, the capture is fine after the reboot.
teague is offline  
Old 03-02-2011, 08:24 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by teague View Post

I use a Mac Pro desktop and a MacBook Pro laptop for captures. Both are very reliable at captures. But after a firmware update some time ago, both cause the cable box to reboot when I power them up or down. Before that firmware,, they both worked fine. Even now, the capture is fine after the reboot.

Thank you very much for this info, teague! OK, so it's not just the Windows 32-bit driver that has that problem with the latest Motorola firmware.

A follow-up question, if I may: Are your Macs 64-bit or 32-bit? (or maybe 1 of each...hey, I can hope). I know very little about Macs, but I'm sure that the drivers for 32-bit and 64-bit would have to be different. I'm curious if both would cause the cable box to reboot.
TNO821 is offline  
Old 03-06-2011, 12:19 PM
Member
 
richardjb's Avatar
 
Join Date: Feb 2009
Location: SF Bay Area, USA
Posts: 43
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Like many others, I've been struggling with glitchy firewire captures since the last firmware update. I've appreciated TN0821's suggestions, but they haven't worked for me. On the theory that background video activity was still interfering with the firewire output, I tried TN0821's basic method, but instead set both tuners to audio-only (music) channels rather than SD channels. It still didn't work.

Then it occurred to me to try pulling out the coax cable input to the DVR, to completely prevent any background activity. Obviously, the music channels stop playing, but you can still access your DVR recordings, and for the first time in multiple attempts, I was able to get a glitch-free capture of a one-hour music show from HDNet (1920x1080). After the capture was finished, I just plugged the coax cable back in again, and everything works fine.

Admittedly, this is just a sample of one, but I'd be very interested to have others try this and see if it works for them. I suspect with this method, it probably doesn't matter what channels the tuners are set to, but I haven't tried that yet. Hope to hear back from some of you.

By the way, my cable box is a DCT6412 III (SF Bay area Comcast).

Richard
richardjb is offline  
Old 03-06-2011, 12:27 PM
Member
 
sailorickm's Avatar
 
Join Date: Dec 2010
Location: with Shaw Cable in Calgary, Canada
Posts: 39
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by richardjb View Post

Then it occurred to me to try pulling out the coax cable input to the DVR, to completely prevent any background activity. Obviously, the music channels stop playing, but you can still access your DVR recordings, and for the first time in multiple attempts, I was able to get a glitch-free capture of a one-hour music show from HDNet (1920x1080). After the capture was finished, I just plugged the coax cable back in again, and everything works fine.

Brilliant! I'll have to try this too. I have six 2-hour HDNet concerts recorded that take a big chunk of my 160GB drive and I just can't seem to find the time to watch them (and keep up with my weekly shows).

Am I right in assuming that disconnecting the coax feed does NOT cause the box to lose all the Guide data?
sailorickm is offline  
Old 03-06-2011, 12:43 PM
Member
 
richardjb's Avatar
 
Join Date: Feb 2009
Location: SF Bay Area, USA
Posts: 43
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by sailorickm View Post


Am I right in assuming that disconnecting the coax feed does NOT cause the box to lose all the Guide data?

I did not lose my guide data after a coax disconnect of about 75 minutes.

Richard
richardjb is offline  
Old 03-06-2011, 02:20 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by richardjb View Post

Then it occurred to me to try pulling out the coax cable input to the DVR, to completely prevent any background activity. Obviously, the music channels stop playing, but you can still access your DVR recordings, and for the first time in multiple attempts, I was able to get a glitch-free capture of a one-hour music show from HDNet (1920x1080). After the capture was finished, I just plugged the coax cable back in again, and everything works fine.

That is a great idea!! I can't believe that the thought never even came close to crossing my mind. I am surprised that the cable box lets us play back recordings without being connected...I would think that it would perform some sort of authorization check, but evidently not...and you know what they say about making assumptions

I'll be sure to play around with this very soon!

BTW, like richardjb, I am on Comcast in the SF Bay area. I wonder if something done here may agitate and cause more glitching than other areas...

Actually, I don't have a good feel for how many people are even experiencing these firewire glitches or where everybody is located. (Feel free to reply and let us know)
TNO821 is offline  
Old 03-06-2011, 03:22 PM
Member
 
richardjb's Avatar
 
Join Date: Feb 2009
Location: SF Bay Area, USA
Posts: 43
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by TNO821 View Post

I am surprised that the cable box lets us play back recordings without being connected...I would think that it would perform some sort of authorization check, but evidently not.

Yes, I was a bit surprised that it worked as well, since I seem to recall stories of people taking their Comcast box to some other location to play programs from the DVR, and having it not work.

But maybe as long as you don't unplug the box, it will tolerate an interruption on the coax input. I guess it could even be a "feature" so that in an actual cable outage, you can still play your recorded shows.

Anyway, thanks for responding, TN0821. I was hoping you would and that you can try this method yourself soon.
richardjb is offline  
Old 03-06-2011, 05:25 PM
Member
 
sailorickm's Avatar
 
Join Date: Dec 2010
Location: with Shaw Cable in Calgary, Canada
Posts: 39
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by TNO821 View Post

Actually, I don't have a good feel for how many people are even experiencing these firewire glitches or where everybody is located. (Feel free to reply and let us know)

I'm with Shaw Cable in Calgary, Canada. My DCT6412-P3 (with a 160GB drive that I installed) glitches with the firewire. The DCX4300M is worse (stutters real bad).

I just did a 1 minute test with the coax disconnected. Although it seemed to record OK the file won't play back with MPClassic or VLC. I started a 2-hour capture anyway to see what happens.

I haven't seen people mention it, but my original capture attempts (weeks ago) would play up to the glitches and sometimes (with MPC and/or VLC) hang an not play past the glitch. I think it would play through after running it through MPEG2repair (is that the name?) but then the audio was out of sync.

Is there some known trick that one should start the recorded file playing before hitting REC in the capture program, or vice versa? For my 1-minute test I started the capture program first. When I started the 2-hour copy just now, I started the playback first.
sailorickm is offline  
Old 03-06-2011, 05:43 PM
Member
 
richardjb's Avatar
 
Join Date: Feb 2009
Location: SF Bay Area, USA
Posts: 43
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by sailorickm View Post

Is there some known trick that one should start the recorded file playing before hitting REC in the capture program, or vice versa? For my 1-minute test I started the capture program first. When I started the 2-hour copy just now, I started the playback first.

I usually start playback of the recording, pause it, launch and start the capture program recording, then un-pause the recording. But even then, MPClassic sometimes won't play it (or will play it only if you skip to the middle of the file). One solution is to use HDTVtoMPEG2 ( http://www.videohelp.com/tools/HDTVtoMPEG2 ) to clip a second or two off the beginning of the file.

Please let us know if your recording is glitch-free with the coax disconnected.

Richard
richardjb is offline  
Old 03-06-2011, 08:20 PM
AVS Club Gold
 
DSperber's Avatar
 
Join Date: Apr 2001
Location: Marina Del Rey, CA, USA
Posts: 5,455
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 80 Post(s)
Liked: 119
Just remember, in theory this is still governed by the 5C flags, and copy-freely vs. copy-once in the particular recorded content you're trying to offload. -> encrypted as well.

Even if you do manage to "record" an encrypted transport stream so-called glitch-free, you won't have any success trying to play it back. Black screen, likely.
DSperber is online now  
Old 03-06-2011, 09:27 PM
Member
 
sailorickm's Avatar
 
Join Date: Dec 2010
Location: with Shaw Cable in Calgary, Canada
Posts: 39
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by richardjb View Post

I usually start playback of the recording, pause it, launch and start the capture program recording, then un-pause the recording. But even then, MPClassic sometimes won't play it (or will play it only if you skip to the middle of the file). One solution is to use HDTVtoMPEG2 ( http://www.videohelp.com/tools/HDTVtoMPEG2 ) to clip a second or two off the beginning of the file.

Please let us know if your recording is glitch-free with the coax disconnected.

Richard

I ran MREG2Repair on the file and there are just two bad spots as shown in the log below. I played through them to check. The first is just a tiny little jerk/stutter. The second is much larger. It freezes for a second, then breaks up pixelated for another second, and then continues. For my purposes, this is good enough. I think this copy is the best I've gotten. This is not the same show as I tried a few weeks ago, if that matters.

I actually ran this ts file through HDTV2MPEG2 thinking I'd get a much smaller file, but it only went from 10.6GB to 9.6GB or so. I have HDTV2DVD, but that indicated it wanted to output over 8GB. I have ConvertXtDVD but I don't think that will help. I'm going to look for a (free) ts to avi converter. Any recommendations?

I'm sure that will horrify you all who are trying so hard to capture and keep the HD video!

Code:
MPEG2Repair: 

Sequence Frame 19781(10-B) / Time 0:10:59 :
Error: Packet 5946008 has no TS Sync Byte.
VideoWarning: Discontinuity of (7+) packet(s).  First packet ending at offset 1117998212
Additional error(s) detected.  Increase VerboseLogLevel in INI file for details.
VideoWarning: Discontinuity of (9+) packet(s).  First packet ending at offset 1118001408
FileInfo: Last video errors span 35330 bytes at file offset 1117937674

Sequence Frame 19782(13-B) / Time 0:11:00 :
AudioError: Corrupted AC3 frame of 2998 payload bytes at file offset 1117921788

Sequence Frame 19785(1-B) / Time 0:11:00 :
AudioWarning: Timestamp gap of 0.064000 sec. ending at file offset 1118165812

Sequence Frame 19798(13-B) / Time 0:11:00 :
VideoWarning: TemporalRef gap of 1.  Timestamp gap of 0.033367 sec. ending at file offset 1118036498
VideoWarning: TemporalRef gap of 1010.  Timestamp gap of 0.033367 sec. ending at file offset 1118212842

Sequence Frame 164303(0-B) / Time 1:31:22 :
Error: Packet 49239966 has no TS Sync Byte.
VideoWarning: Discontinuity of (11+) packet(s).  First packet ending at offset 9261567516
Additional error(s) detected.  Increase VerboseLogLevel in INI file for details.
FileInfo: Last video errors span 1052 bytes at file offset 9257262124
VideoWarning: Discontinuity of (10+) packet(s).  First packet ending at offset 9261574848

Sequence Frame 164304(3-B) / Time 1:31:24 :
AudioError: Corrupted AC3 frame of 2766 payload bytes at file offset 9257220412

Sequence Frame 164306(8-P) / Time 1:31:24 :
AudioWarning: Timestamp gap of 2.624000 sec. ending at file offset 9261675896

Sequence Frame 164330(13-B) / Time 1:31:25 :
VideoWarning: TemporalRef gap of 1.  Timestamp gap of 0.033367 sec. ending at file offset 9257115583
VideoWarning: Timestamp gap of 2.502500 sec. ending at file offset 9261581362
VideoWarning: TemporalRef gap of 1.  Timestamp gap of 0.033367 sec. ending at file offset 9261771054

Sequence Frame 196856(2-I) / Time 1:49:31 :
Error: Packet 57815631 has no TS Sync Byte.
Error: Packet 57834729 has no TS Sync Byte.
Error: Can't find next TS Sync Byte.  Terminating operation.
Additional error(s) detected.  Increase VerboseLogLevel in INI file for details.
FileInfo: Last video errors span 21 bytes at file offset 10873778791

Sequence Frame 196857(2-I) / Time 1:49:31 :
Info: End of MPEG2 sequence

Sequence Summary:

File Size Processed: 10.13 GB, Play Time: 01h:49m:28s
1920 x 1080, 29.97 fps, 24.00 Mbps (12.48 Mbps Average).
Average Video Quality: 50.82 KB/Frame, 0.20 Bits/Pixel.
AC3 Audio: 3/2 Channels (L, C, R, SL, SR) + LFE, 48.0 kHz, 384 kbps.
Dialog Normalization: -25.0 dB, Center Mix Level: -3.0 dB, Surround Mix Level: -3.0 dB
3 of 196857 video frames found with errors.
2 of 205271 audio frames found with errors.
48787 corrupted video bytes in file.
2.635967 seconds of video timestamp gaps.
2.688000 seconds of audio timestamp gaps.

End of Log
sailorickm is offline  
Old 03-07-2011, 10:17 AM
AVS Special Member
 
JDLIVE's Avatar
 
Join Date: Apr 2003
Location: Marlborough, MA
Posts: 2,922
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 17 Post(s)
Liked: 27
Send a message via Yahoo to JDLIVE
Quote:
Originally Posted by richardjb View Post

Yes, I was a bit surprised that it worked as well, since I seem to recall stories of people taking their Comcast box to some other location to play programs from the DVR, and having it not work.

But maybe as long as you don't unplug the box, it will tolerate an interruption on the coax input. I guess it could even be a "feature" so that in an actual cable outage, you can still play your recorded shows.

Anyway, thanks for responding, TN0821. I was hoping you would and that you can try this method yourself soon.

Interesting suggestion, I'll have to try this out.

And I think you're right, the cable box has to be able to tolerate some kind of disruption to the connection, but most likely the threshold where it actually affects the function will probably be a fairly long time.
JDLIVE is offline  
Old 03-07-2011, 04:08 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by richardjb View Post

Yes, I was a bit surprised that it worked as well, since I seem to recall stories of people taking their Comcast box to some other location to play programs from the DVR, and having it not work.

But maybe as long as you don't unplug the box, it will tolerate an interruption on the coax input. I guess it could even be a "feature" so that in an actual cable outage, you can still play your recorded shows.

I think you're right...it is likely a feature of the cable box so that people can play back DVR'd shows during a cable outage.

Although this would be ridiculous, I guess you could take your cable box over to a friend's home and play DVR recordings...you'd just have to have a decent UPS hooked up to it

I haven't tried to capture anything yesterday or today, but I intend to play with this cool trick this evening.
TNO821 is offline  
Old 03-07-2011, 05:39 PM
Member
 
richardjb's Avatar
 
Join Date: Feb 2009
Location: SF Bay Area, USA
Posts: 43
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by TNO821 View Post

I haven't tried to capture anything yesterday or today, but I intend to play with this cool trick this evening.

OK, thanks. Based on sailorickm's less than perfect results, I'm a bit concerned that my one glitch-free capture was just a fluke. But the more people that give this method a try, the better feel we'll get for whether it makes any difference.

Richard
richardjb is offline  
Old 03-07-2011, 06:37 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by sailorickm View Post

I'm with Shaw Cable in Calgary, Canada. My DCT6412-P3 (with a 160GB drive that I installed) glitches with the firewire. The DCX4300M is worse (stutters real bad).

Thanks! That's good to know.

Quote:
Originally Posted by sailorickm View Post

The DCX4300M is worse (stutters real bad).

That's not because of the "firewire glitching" bug. It's because Motorola switched firewire chipsets in all of the DCX cable boxes...they have been, how shall we say, "less than successful" at getting any firewire functionality to work whatsoever. Nobody has successfully captured anything from a DCX cable box. Ever.

BTW, the DCX cable boxes fail with every firewire device, not just Windows PCs. You can't even capture using a DVHS VCR. You always end up with the garbled stuttering output like you saw.

Quote:
Originally Posted by sailorickm View Post

Is there some known trick that one should start the recorded file playing before hitting REC in the capture program, or vice versa? For my 1-minute test I started the capture program first. When I started the 2-hour copy just now, I started the playback first.

I *always* start the playback of the DVR'd show before hitting Rec in CapDVHS.
TNO821 is offline  
Old 03-07-2011, 06:49 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by richardjb View Post

OK, thanks. Based on sailorickm's less than perfect results, I'm a bit concerned that my one glitch-free capture was just a fluke. But the more people that give this method a try, the better feel we'll get for whether it makes any difference.

Well, I don't think that shooting for 100% perfect firewire captures 100% of the time is a realistic goal. Also, he did a 2 hour capture! I never go beyond 32 minutes.

There are just so many unknowns about the true nature of this firewire glitching bug. But I really like the concept behind your remove-the-coax trick...I would expect that, at worst, it would yield the same results as my trick. But then again, this is assuming that the problem has to do with the amount of background junk that the cable box is dealing with. And I guess it's also possible that the cable box runs some specialized logic when the cable signal is lost...we really have no way of knowing what it's trying to do while the cable coax is removed.

Anyways, I'll be playing with this in just a couple of hours.
TNO821 is offline  
Old 03-08-2011, 12:03 AM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Sorry guys (and gals), but I'm getting no love on the firewire glitching front.

I've been running captures, but all I've seen is one lousy Video Resync Frame Removed...everything else has been flawless without me using my "ritual" or removing the cable coax.

So there's no point in me testing this new trick until I see some actual substantial glitching (as I wouldn't be able to draw any conclusions)...I'll try again tomorrow.

In the mean time, I'll craft a post that gives a truly step-by-step for how I have been capturing stuff for the last couple of months.
TNO821 is offline  
Old 03-08-2011, 08:05 AM
AVS Club Gold
 
DSperber's Avatar
 
Join Date: Apr 2001
Location: Marina Del Rey, CA, USA
Posts: 5,455
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 80 Post(s)
Liked: 119
Quote:
Originally Posted by dr1394 View Post
It has absolutely nothing to do with the number of ports. The DCX series is an entirely different box than the DCT and DCH series. Motorola dumped the Broadcom SoC they had been using and went with an SoC from Conexant.
Fascinating. I was not aware of this new "variable" in the latest generation 1-port DCX/FIOS family of boxes. Of course the firewire recording failures (to DVHS VCR) have been reported not only with the DCX34xx model, but also with the equivalent FIOS 72xx model... which I would assume also uses the new Conexant chip.

Anyway, my contact in TWC/LA provided some interesting information on this whole subject a few months back, that I'd like to share. I realize this info might also have more relevance on the local TWC/LA thread, or on the DCX thread, or all of the above.

TWC/LA plans to roll out the multi-room version of the DCX products in 1st-quarter 2011. They've already made their appearance in Comcast areas and Charter areas around the country, and maybe already in Canada as well. But here in TWC/LA they're just now planning on making them available. I don't actually know if they can be had just yet, since I haven't seen any mailer.

Anyway, the new DCX3400-M/DCX3200-M boxes will have 24.07 firmware. This is apparently a prerequisite to support MPEG4 and the ESPN 3D channel, along with the multi-room client/server architecture.

TWC/LA is simultaneously rolling out two new Samsung boxes (model numbers unknown to me). I don't know if these are Motorola-compatible replacements, or if they're for the Scientific Atlanta side of the house, but I assume they are also multi-room enabled.

What's interesting, however, is that I was also told: "I'm optimistic that firewire VCRs will work with the new boxes, when were close to test, I'll let you know." This suggests that Motorola/Conexant may have finally gotten to the bottom of the problem with the 24.07 firmware upgrade, and that maybe/hopefully the firewire issue with the DCX/Conexant family has now finally been solved.


I have repeatedly asked TWC Dallas AVS members (over on the official DCX thread) for any feedback at all on this question, because 24.07 was rolled out to TWC Dallas some time ago.

So if there were any TWC Dallas DCX/DVHS users (who've for sure been having firewire recording problems since day 1, like all of us have), you'd think that at least one of them would have seen the new 24.07 appear and experiment to see if it really had made any difference in the firewire recording area. Forget for the moment about DCX/PC WinXP firewire recording users... I'm talking about basic DCX/DVHS firewire recording users.

Well, still no reply. Maybe someone on this thread who lives in Dallas and is on TWC and has a DCX (single-room or multi-room) with 24.07 and also a DVHS VCR will re-try the firewire recording experiment, and report back as to whether or not 24.07 has finally done it.


With this new information about the Conexant chip, I wonder if my TWC/LA contact's "optimism" is due to an upgraded Conexant chip in the multi-room DCX3400-M model which has finally solved the firewire problem by correcting Conexant bugs... with a hardware upgrade.

Or, hopefully, the problem wasn't really in the Conexant chip or SoC engineering at all, but rather solely in the new Motorola firmware use of that new Conexant 1394 functionality which was at fault. And that they've finally fixed that flawed early Motorola/Conexant firmware to now use the [always 100% working] Conexant 1394 functionality correctly.


Still looking for any and all input on this subject, from anyone anywhere.

Thanks very much for this new-to-the-lore fact about Conexant vs. Broadcom/LSI technology in the new DCX/FIOS family of boxes.
DSperber is online now  
Old 03-08-2011, 09:22 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Those posts, regarding how each of us goes about starting a capture, are interesting...So, in mega-detail, here's how I do it:

I always set my recordings to start 2 minutes early and end 2 minutes late. One minute would probably be fine, but I like to err on the side of caution. If I'm trying to record several shows in a row (On Thurs I like NBC's Community, The Office, Parks and Rec and 30 Rock) I'll set the recording for the first show and have it add a bunch of time to the end. So in this example I'd set the recording for Community, and have it start 2 minutes early and end 2 1/2 hours late. This ends up recording two shows I don't watch (Perfect Couples which airs at 8:30 PM between Community and The Office, and Outsourced which airs at 10:30 PM after 30 Rock)...I just ignore those shows. To me it isn't worth micro-managing the recordings of these shows and tying up both of my tuners in the process, since I need to be able to also record Archer on FX at 10:00 PM (I'd sooner give up the entire NBC Thurs night lineup than miss Archer).

BTW, the reason I set it to record 2 1/2 hours extra instead of 2 hours extra is that I don't want the very end of 30 Rock to get cut off. Many of the networks now have comedy bits during the credit sequence and then start the next show immediately following the credits (no ad break, they want to keep you watching the next show). So I ignore most of that last half hour (which is Outsourced, a show that hasn't really hooked me).

When I'm ready to capture a show, here are my exact steps:

1. I go to channel 5
2. I hit the PiP/Tuner "Swap" button
3. I go to channel 6
(Both tuners are now on Standard-Definition channels)
4. I hit the power button to put the cable box into Standby
5. I wait for 30 seconds to a minute
6. I hit the power button to power up the cable box
7. I go to channel 8
8. I hit the PiP/Tuner "Swap" button
9. I go to channel 9

(Both tuners are now on different Standard-Definition channels)
Note: these are the exact channel numbers that I use. This is the exact "ritual" that I follow that gives me glitch-free captures in well over 90% of cases. I do not deviate from this even a little. The channel numbers themselves were chosen arbitrarily, but based on the success that it has provided me with, I adhere to this religiously. It was just by chance that I found that I got better results by changing the channels both before and after powering off.

10. I hit the "My DVR" button, go the "My Recordings" menu and start playing back the show that I'm trying to capture.

11. I use the 30-second skip button a few times until I see the beginning of the show.

*You have to program the remote to add the 30-second skip button. Here's how.

12. I use the 15 second back button until I'm roughly 20 or 30 seconds before the show begins.

13. On the PC, I press "Rec" in CapDVHS.
*I would already have made sure that the recording time in CapDVHS is set appropriately...for a 30 minute show, I have CapDVHS set to record for 32 minutes. That means I'll have about 20 or 30 seconds to remove from the beginning of the capture and about another minute-and-a-half to remove from the end. I never babysit the capture...I'm usually not even in the same room.

14. I let the entire recording play (unless it's one of those huge 2 1/2 hour recordings with multiple shows...I'll stop those once CapDVHS has finished recording).

15. On the PC, I open VideoReDo TVSuite v4 and open the recording.

16. I trim the 20-30 seconds of extra crap from the beginning of the recording and the approximately minute-and-a-half of extra crap from the end (I do NOT bother with removing ads at this point).

17. I have VideoReDo save the trimmed .ts file (I have CapDVHS save files with the .ts extension rather than the .mpg extension...but the contents of the file are no different, regardless what extension you choose).

*If there are firewire glitches in the capture, VideoReDo will mention it in the output dialog. Here's what it looks like when glitches are present.

If no glitches are present, I then remove ads.

Instead of using VideoReDo, you could also use Mpeg2Repair to find out if any glitching took place (keep in mind that problems at the very beginning or end of the file don't count as firewire "glitches"...they are simply a very common occurrence of starting and ending the capture, and happen with all firmware versions). You could also try using the free TSSniper to remove the beginning and end (plus ads).

*************Update*************
It is very important to note that I re-do this ritual between every capture that I perform.
When I capture several shows on Thursday, I will change channels back to 5 and 6, power off the stb, power it back on, and change channels to 8 and 9 before every one of them. And it almost always results in a perfect capture.
TNO821 is offline  
Old 03-09-2011, 08:26 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
I've been doing some capture tests with the cable coax removed and I've seen fairly good results, but I did get some mild glitching it two cases (out of six).

So at the moment I can conclude that it isn't a guarantee of a perfect capture, but I'm going to continue playing with it...I really like the concept. The way I figure it, it should do better than my method simply because there's no tuner buffers being populated whatsoever.

But, again, we have very very little information to go on regarding the true nature of the firewire glitching bug...it may not have anything to do with the amount of background processing that the stb is attending to.

*It is also important to note that I very intentionally did nothing else to help these captures...no powering off the stb, no changing channels to SD material...nothing. I even had both tuners on HD channels that have been known to glitch. I was going for worst-case-scenario. And the worst glitching that I got was 6 video resync frames removed and a few Input Sequence Errors, which pales in comparison to some of the crap I saw two months ago (87+ Input Sequence Errors, 40+ Video Resync Frames Removed, etc).

It hasn't been helpful to my testing that most of my firewire glitching seems to have vanished when Comcast boosted the signal strength to my neighborhood.
TNO821 is offline  
Old 03-10-2011, 09:15 AM
Member
 
sailorickm's Avatar
 
Join Date: Dec 2010
Location: with Shaw Cable in Calgary, Canada
Posts: 39
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by TNO821 View Post

It hasn't been helpful to my testing that most of my firewire glitching seems to have vanished when Comcast boosted the signal strength to my neighborhood.

Given that repeated capture attempts of the same recorded program will glitch in different places, I couldn't make any sense out of your glitching improving by a signal boost in the neighborhood. Just a wild guess, but could it be that with the coax connected, the STB was working overly hard to deal with incoming glitches for the channels tuned on the 2 turners, and with the coax disconnected, it doesn't?
sailorickm is offline  
Old 03-10-2011, 11:34 AM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by sailorickm View Post

Given that repeated capture attempts of the same recorded program will glitch in different places, I couldn't make any sense out of your glitching improving by a signal boost in the neighborhood.

Perhaps something to do with error correction? All I know is that all the glitching started as of the A28 update, was moderate until Dec, got real bad in Jan and Feb and got much better as soon as Comcast engineers fiddled with the signal to my neighborhood. I don't know specifically what was changed that helped...for all I know the signal strength wasn't actually changed, but I know that as soon as they made their changes (whatever those changes were...they wouldn't specify) the firewire glitches have been far less frequent.

And when I call it a "signal boost", I don't actually know what the engineers changed. I use the term in a very generic fashion. All I know is that they made some sort of substantial change which resulted not only in getting rid of the obvious graphical glitching problems that customers in my neighborhood were calling in about, but also greatly reducing the amount of firewire glitches.


Quote:
Originally Posted by sailorickm View Post

Just a wild guess, but could it be that with the coax connected, the STB was working overly hard to deal with incoming glitches for the channels tuned on the 2 turners, and with the coax disconnected, it doesn't?

That's what I initially was hoping...but my testing hasn't backed this up. But again, we've been having to make a lot of assumptions. For all we know, the STB goes into some sort of panic-mode when the signal cuts out...we have no way of knowing what logic it's running or how "taxing" it is on the STB's ability to properly output via firewire.
TNO821 is offline  
Old 03-10-2011, 04:21 PM
AVS Special Member
 
splinke's Avatar
 
Join Date: Dec 2001
Location: Carlsbad, CA
Posts: 1,082
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by TNO821 View Post
Unfortunately, yes. You need to reload the fresh OS (no upgrade) and reload all of your applications. I know it sucks, but your copy of Windows is ill, and nothing short of a full reformat and reinstall is likely to fix it...there's just too many possible different things that could be wrong with it and it would be hugely expensive and time-consuming to investigate all possibilities...
Just an update. I first tried a "repair install," which replaces all of the Windows OS files, but nothing else. That did not work. However, after wiping everything and completely reinstalling Windows XP, I can now capture over Firewire without a blue screen of death. There was probably some Dell driver crap that was screwing things up. Of course, it took an entire day to get everything on my computer back to the way it was.

I captured 30 minutes of HD video at 1920x1080 at 29.97 fps with a 15.64 Mbps average (38.81 Mbps max.) with Dolby Digital 5.1 audio, and MPEG2Repair did not report any video errors, except the last frame. And it was done from a recorded program while two other programs were being recorded. Hopefully, my luck will continue.

Anyway, thanks so much to TNO821 for taking the time to provide detailed answers to my questions earlier.

Sony LCD Rear Projection TV Problems: informational web site
SPL Moxi FAQ: comprehensive guide to Moxi DVRs.
splinke is offline  
Old 03-10-2011, 05:55 PM
AVS Special Member
 
TNO821's Avatar
 
Join Date: Jun 2007
Location: Silicon Valley
Posts: 1,105
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 17
Quote:
Originally Posted by splinke View Post

Just an update. I first tried a "repair install," which replaces all of the Windows OS files, but nothing else. That did not work. However, after wiping everything and completely reinstalling Windows XP, I can now capture over Firewire without a blue screen of death.

Awesome! You're probably right about a crummy driver being responsible for the problem. This is why a fresh reinstall is recommended...anything short of that can't typically undo the layers of crummy filter drivers that applications sometimes install.

Quote:
Originally Posted by splinke View Post

I captured 30 minutes of HD video at 1920x1080 at 29.97 fps with a 15.64 Mbps average (38.81 Mbps max.) with Dolby Digital 5.1 audio, and MPEG2Repair did not report any video errors, except the last frame. And it was done from a recorded program while two other programs were being recorded. Hopefully, my luck will continue.

That's good. It sounds like you aren't encountering the "firewire glitching" that some of us have been wrestling with.

Quote:
Originally Posted by splinke View Post

Anyway, thanks so much to TNO821 for taking the time to provide detailed answers to my questions earlier.

You're very welcome. I've learned so many cool things here over the years and am now trying to give a little back.
TNO821 is offline  
 
Thread Tools


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off