[jg167]

What sw are you running? I never had this issue with 3.1, nor for the first 6 months after having upgraded to 6.2 via instacake. But now is getting bad. When ever pixilation occurs, it also occurs on all the channels that are on the same sat & transponder as the one where I noticed the issue. Its often so bad the frame freezes completely. Often it seems to be SPEED, but not always by any means. It also sometimes fixes itself. I'm just now watching the recording of this weekends F1 qualifing in Belgium and the first 30 mins had lots of breakup, but then it was fine for an hour and then blew out again for a bit. (boy this is frustrating)

I find if you restart the recorder (power cycle or use the restart menu item) that seems to fix the immediate problem, but does not prevent it from coming back a few hours later (though might be on a different sat/transponder channel group).

I think this has to be sw issue (or the power cycle wouldn't fix it even temporarily), thought that isn't certain, just likely.

 

[jg167]

The picture breakup is still driving me mad. In the log files
I seem some things that look clearly related, but what is the root cause? What to do about it?

in tverr, lots of:
Sep 16 18:19:08 (none) myworld[247]: hpk brcm: start code 0x0 not found, assuming buffer overrun
Sep 16 18:19:08 (none) myworld[247]: hpk brcm: cannot find picture start code at 0x2b30608d

even more stuff in tvlog
Sep 16 18:19:08 (none) myworld[247]: hpk brcm: VIDEO PES stream buffer overrun!
Sep 16 18:19:08 (none) ApgCamInterfaceBase[239]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Sep 16 18:19:08 (none) ApgExprEvaluator[239]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Sep 16 18:19:09 (none) source[247]: Detecting a discontinuity in the stream. Recovering : 0
Sep 16 18:19:10 (none) myworld[247]: hpk brcm: unexpected picture code: 0xff (whole byte) at: 0x2b2aab30, assuming B picture
Sep 16 18:19:17 (none) myworld[247]: hpk brcm: unexpected picture code: 0xff (whole byte) at: 0x2b46aab0, assuming B picture
Sep 16 18:19:19 (none) myworld[247]: hpk brcm: unexpected picture code: 0xff (whole byte) at: 0x2b4dbf60, assuming B picture

 

[jg167]

Boy it seems unlikely that this can cause the errors I see in the log files which all appear to be problems in decoding the sat signal, digital issues not analog isues. But perhaps aging components on in the s-video path might be causing problems for the unit in general yet not showing analog degradation in the output??? Still seems far fetched, but if it works its hard to argue with that. I've unplugged the s-video output and am using composite. The picture is slightly worse when viewing the guide, but I can't tell the difference (I don't think, its hard to know) when actually viewing content. We'll see if it helps with the problem. So far so good, no pixilation could be found on any channel.

update: after no breakup for a day on any channel that I could find, I plugged the s-video cable back in and it didn't take long to find the old problem. Swapped back to composite and it went away. Color me a believer!

Many thanks to those that discovered this one. Sadly I doubt there is a fix for the s-video since I've run my tivo with it for years with no problem, i.e. it must be aging components.

 

[jg167]

If this is an age related issue, we should see that in our own data. So how old are the units that have had this issue (the one fixed by using composite video). My Philips DSR7000 was four years and a month or two when this started.

 

[jg167]

Saw this today on the Disney Channel this morning (Hanna Montana) and a bit this evening watching the UCLA game on 652. Both on my HDVR2, upgraded HD at the beginning of the summer. Changed the channel each time I saw it and the other channels were fine. Back to the show we were watching and sure enough, looks like it's not my HDVR2 but what's coming down from the sattelite.

Certainly it can be what's coming down, but for those of us that have seen it correlate with the use of the s-video output (right next to the inputs), that would seem to indicate its a DVR issue with an input going bad or the s-video output going bad in a way that it effects the neighboring input.