<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Or maybe something with the HDD that the HDHR is streaming to? I'm<br>not sure if bringing up the F/E would cause the B/E to hit the HDD at
<br>all. You may have been over it already but some hdparm -tT output on<br>the B/E might be useful. Note that you could also try running hdparm -<br>tT _while_ the HDHR is streaming to the HDD to see if you can trip it<br>
up. Do this test on the B/E local console to avoid influencing the<br>network traffic.</blockquote><div><br>Good thought. I hadn't really been focusing on the HDD at all. My only question there would be if it is a hard drive issue wouldn't I see similar problems when I record from the PVR-150 or (especially) the HD-3000? Because I don't. I've never seen any programs recorded from the two tuner cards get corrupted, no matter what I did on the F/E. The one difference is that the HDHR is streaming over the network, which is why I was looking toward the network. I'll certainly do some hdparm tests though; it can't hurt that's for sure.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If you after you stop the F/E does the video return to normal? Have<br>you tried running mythtvbackend with "-v all", start a recording, and
<br>then fire up the F/E to see if any messages are logged? If nothing<br>else this might give you a good idea of what the F/E and B/E are<br>doing together that could lead resource starvation of the HDHR.</blockquote><div>
<br>I've tried having the F/E running before a recording from the HDHR starts, and in this case the recording gets corrupted right from the get go. I've also tried letting a recording go for a while and then firing up the F/E in the middle of the recording. In this case the beginning of the recording is fine, but when I get to the spot when I turned on the F/E it goes bad. I've only done one small test of what you suggest; turning off the F/E after a recording started and the recording did go back to normal after the F/E was off. I haven't tried turning up the debugging on the back end yet. The funny thing is when the recording is going bad I don't see anything special in the logs, but when the commercial flagging processing the recording I get literally thousands and thousands of messages in the log. Here's just a real small sample:
<br>[mpeg2video @ 0x4dc9c4]invalid cbp at 73 10<br>[mpeg2video @ 0x4dc9c4]Warning MVs not available<br>[mpeg2video @ 0x4dc9c4]ac-tex damaged at 38 56<br>[mpeg2video @ 0x4dc9c4]Warning MVs not available<br>[mpeg2video @ 0x4dc9c4]current_picture not initalized
<br>2007-02-12 18:33:36.669 AFD Error: Unknown decoding error<br>[mpeg2video @ 0x4dc9c4]current_picture not initalized<br>2007-02-12 18:33:37.520 AFD Error: Unknown decoding error<br>[mpeg2video @ 0x4dc9c4]mb incr damaged
<br>[mpeg2video @ 0x4dc9c4]Warning MVs not available<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Looking to the netowrk, with the HDHR the switch itself is usually
<br>the weak spot, as seen in the forums. Before helping diagnose network<br>troubles a network diagram of switches, systems, and zones would be<br>helpful.</blockquote><div><br>I must have just been typing my response to the first reply when you posted this message. See my last message for a description of my network.
<br></div></div><br>Thanks for your help.<br>John<br><br>