# HDCP reauthentication every 3 hours



## unixguru (Jul 9, 2007)

Very frustrating that there is no way to report a technical problem to DirecTV electronically. Useless talking to a customer service rep about this kind of thing. So here I blow it into the wind on the slim chance...

My setup: HR34 -> Gefen 4K Ultra HD HDMI Extender -> Pioneer Elite SC-72 -> Sony XBR-65HX929

It appears that the DVR goes through an HDCP reauthentication process every 3 hours, exactly on the hour 12:00/3:00/6:00/9:00.

If there are no recordings starting or stopping the symptoms are a black screen with no sound for a second or so and then everything continues normally. If there is a recording starting or stopping the symptoms are:

flickers between black and picture; sometimes very "snowy" picture, sometimes pink
audio comes and goes too
pause/play/skip-back doesn't help
turning the TV or receiver off/on doesn't help
the only thing that clears it is changing the channel if watching live or going to live when watching a recording
Its not my cables, extender, receiver, or TV because none of them know what time it is (I don't set time on TV) or whether there is a recording starting or stopping. Any other time it works perfectly. I've never seen a hint of HDCP problems outside of those circumstances. That tells me that all the components in the chain are working correctly.

I cannot eliminate the extender - its there for a reason (DVR is on a different floor & ~50' away from TV).

It has to be the DVR.

So here is a suggestion to the DVR implementors... when you decide its time to reauthenticate HDCP, do some retries before treating it as failed; wouldn't hurt to increase the timeout either.


----------



## Tom Robertson (Nov 15, 2005)

Good analysis and report, unixguru. On their behalf, thanks.

To help some more, is there any chance you can temporarily remove the pioneer elite to see if it goes away? While I like your surmise that the DVR is initiating the verification, it probably would help to determine which device might be introducing the delay in the authorization. It's amazing how badly some devices can play with each other. And put another way, how hard DIRECTV has to work around the problem children. That's why your detailed info is a big help.

Would also be nice if you could remove the extender for a short test, though I realize that would require moving the DVR to the TV or using a LONG HDMI cable you might not have. Speak of the extender, which model are you using?

Thanks again,
Tom



unixguru said:


> Very frustrating that there is no way to report a technical problem to DirecTV electronically. Useless talking to a customer service rep about this kind of thing. So here I blow it into the wind on the slim chance...
> 
> My setup: HR34 -> Gefen 4K Ultra HD HDMI Extender -> Pioneer Elite SC-72 -> Sony XBR-65HX929
> 
> ...


----------



## harsh (Jun 15, 2003)

HDCP updates take 100ms or less. What you're experiencing sounds like a cold HDMI handshake.

Consider temporarily replacing the Genie with some other source (like a Blu-ray player or a streamer).

Reasoning can only take you so far -- at some point you have to roll up your sleeves and physically test the theories.


----------



## unixguru (Jul 9, 2007)

harsh said:


> HDCP updates take 100ms or less. What you're experiencing sounds like a cold HDMI handshake.
> 
> Consider temporarily replacing the Genie with some other source (like a Blu-ray player or a streamer).
> 
> Reasoning can only take you so far -- at some point you have to roll up your sleeves and physically test the theories.


Even if it is a cold handshake why doesn't it recover? It should go blank for a couple of seconds and then continue on.

I don't see the logic in replacing the Genie with something else. It runs 6+ hours a day and *never* has an issue except at those specific times and only when recording. Seems pretty obvious to me that putting some other device there is not going to have the issue. We could speculate that something else in the chain somehow knows the time and decides to do something funky. But we cannot speculate that something else in the chain knows when a recording is happening.

I will try what Tom suggested re bypassing the receiver.

At some point there are no theories left that can be physically tested. Its reasonable to do what testing can be done - to a point. Unfortunately with DTV setup the theories can quickly get to impractical testing which means it won't happen. And then they can claim _there is nothing wrong_ simply because a customer wasn't willing to hang upside down from their roof to test some theory.

In this case I've been seeing these symptoms consistently for months. It probably started last summer when I installed the extender. So here is another _out_ for DTV - _its obviously the extender that is the problem!_ (Which is flawed logical since it doesn't know about recordings or time.)

If that is indeed the approach then this is the classic finger pointing of the tech industry. _It couldn't be our fault._


----------



## inkahauts (Nov 13, 2006)

Is there a hdmi splitter involved somewhere? Or is the pioneer splitting the signal for you? I use redmiere hdmi cables and don't have this issue over very long runs. But I don't have any experience with the extenders so can't compare for you on that end.


----------



## unixguru (Jul 9, 2007)

inkahauts said:


> Is there a hdmi splitter involved somewhere? Or is the pioneer splitting the signal for you? I use redmiere hdmi cables and don't have this issue over very long runs. But I don't have any experience with the extenders so can't compare for you on that end.


No splitters. The pioneer is a recent model so its an HDMI switch.

I had Cat5E in the wall so that is what I used.


----------



## unixguru (Jul 9, 2007)

Tom Robertson said:


> Good analysis and report, unixguru. On their behalf, thanks.
> 
> To help some more, is there any chance you can temporarily remove the pioneer elite to see if it goes away? While I like your surmise that the DVR is initiating the verification, it probably would help to determine which device might be introducing the delay in the authorization. It's amazing how badly some devices can play with each other. And put another way, how hard DIRECTV has to work around the problem children. That's why your detailed info is a big help.
> 
> Would also be nice if you could remove the extender for a short test, though I realize that would require moving the DVR to the TV or using a LONG HDMI cable you might not have. Speak of the extender, which model are you using?


I bypassed the pioneer, setup a recording to start at 3:00, and watched another channel until the witching hour arrived. Like clockwork it flickered briefly at 3:00 and then continued working. So the presence of the pioneer is causing the issue - or perhaps it is just the accumulation of delays surpasses some threshold that makes the DVR unhappy.

Its a Pioneer Elite SC-72 - a recent model. It has latest firmware.

The extender is Gefen, LLC - 4K Ultra HD ELR-POL Extender w/ RS-232 and 2-way IR. Model just came out last year I believe. I've had other Gefen stuff and they have always been bulletproof.

I sympathize with the difficulties in supporting supposedly standard conforming devices; I know from experience that standards are never 100% complete. I've also seen bending to work around one fringe case breaking another case.

Regardless, I have a reasonable setup of higher-end equipment that doesn't work.

With it acting up based on time of day and recording activity I'm not inclined to pursue with Pioneer - the first thing they would say (reasonably I might add) is that its the DVR. They would say put some other device in place of the Genie - and then the problem would almost certainly go away. It would be right back pointing at the DVR.


----------



## inkahauts (Nov 13, 2006)

I understand and agree with everything you said. But if you could somehow bypass the pioneer and the geffen stuff and go direct via one hdmi cable and see if the issue still exists it would help narrow down the issue. For all we know it's between the DVR and the tv or has to do with all the intermediaries between them. But without some changing to test we can't know. All we do know for sure is it's completely repeatable which generally makes figuring out what two devices are causing the issue easier. But it does take two devices to cause this issue. We just don't know which two. 

By the way are you internet connected? I know it's a crazy idea but disconnect the DIRECTV stuff from the Internet and see if the issue is still there. That's a super easy thing to try even if it doesn't seem to make much sense.

If I had to guess who has causing the issue based on past experience (not with your current gear but the manufacturers) Id point to it being an issue with the Sony and the DIRECTV unit.


----------



## harsh (Jun 15, 2003)

unixguru said:


> They would say put some other device in place of the Genie - and then the problem would almost certainly go away. It would be right back pointing at the DVR.


Wouldn't it be nice if you could assure them that it wasn't the DVR?

I had a neighbor that had a problem similar to yours. It turned out that he had a water softener that did some sort of periodic cycle and it put some sort of interference out that caused his weather station to register .01" of rain with the start of each cycle.


----------



## Bill Broderick (Aug 25, 2006)

harsh said:


> I had a neighbor that had a problem similar to yours. It turned out that he had a water softener that did some sort of periodic cycle and it put some sort of interference out that caused his weather station to register .01" of rain with the start of each cycle.


... and I had a SiriuisXM Internet radio that kept resetting itself. It turned out that Cyberlink PowerDVD has a module used to view things stored on a PC with an Android device. That module was sending a signal that caused the SiriusXM radio to crash and reset itself.

I went through 3 radios and a new access point before I figured out what was really causing the problem.


----------



## Tom Robertson (Nov 15, 2005)

Regardless of whose fault it is, DIRECTV has historically gone above and beyond to eliminate the problems caused by other companies' incompatibilities. So the more information we can create as to what elements have what part to play, the easier it becomes for DIRECTV to find a workaround. 

In this instance I'm pretty sure it isn't DIRECTV's fault, but it doesn't matter. Even if we here agree it isn't DIRECTV's fault, someone somewhere else with a similar problem will blame DIRECTV. 

Again, the DVR is almost certainly starting the process but that does not mean it is the DVR's fault. The DVR is likely required to do this and if the components aren't playing nice, the DVR falsely is blamed for doing what it is required to do. 

I can see the accumulation of delays as part of the problem. Or it might be as simple as one handshake is not being resent through one of the items, forcing the DVR to cold reestablish the connection. If the handshake goes through, there isn't a cold reset at all. There shouldn't be a cold reset anytime after the units are all fired up. So something is preventing the ongoing handshake from being sent.

So by removing the pioneer we still had cold restarts, sounds like that wasn't the real problem. The DVR still had to reset, though it did so better this time. It shouldn't be resetting at all.

Peace,
Tom


----------



## Tom Robertson (Nov 15, 2005)

I see that gefen has unlimited support. You might call them to see if they can suggest what handshake is being dropped. They have a stake in this too. If they are dropping a handshake signal, they would want to know. 

Peace,
Tom


----------



## slice1900 (Feb 14, 2013)

Rather than assuming it is a bug in Directv's software, have you considered the possibility that the DVR hardware is defective? Any chance you can borrow one from someone else for an afternoon and hook it up in place of yours to see if it does the same thing? If there's no problem with that experience, you have a bad DVR, but good luck getting Directv to replace if it you are honest and try to explain the problem :rotfl:


----------



## unixguru (Jul 9, 2007)

I appreciate people reading this thread and offering ideas but... please comprehend what is said.

I said I had bypassed the pioneer and the problem went away (other than a brief 1 time flicker).

The TV and receiver and DVR are older than this problem. The DVR used to be connected directly to an HDMI switch to the TV - no problem. Then the DVR was moved and a C31 put in its place - no problem. Then the pioneer replaced the HDMI switch - no problem. Then the C31 was replaced with the extender. I don't recall this problem being there immediately at that point but it did show up within a couple of months - it is possible that it appeared with a software update. So I'm not going to do a test configuration that repeats a previously working situation.

People will say the problem is the extender. And I'd consider that likely *if* the problem occurred at times when no recording is starting or stopping. And if it was the extender, why did removing the pioneer make the problem go away?

So without extender it worked (in the past). Without receiver it works. With both it doesn't.

I've been an enterprise-scale software engineer for 35 years; I have some idea about how to isolate problems and logically determine likely causes. Including massive interaction between many components all compliant with some set of standards.

I don't know why anyone would be pretty sure it isn't DirecTVs fault. The DVR has to do something and it does it acceptably all the time *except* when it is starting or stopping a recording only at very specific times of day. It does look like a timing problem that is exasperated by recording activities and time of day.

It is likely an accumulated delay situation. Which means it isn't the fault of any of the devices in the chain. The same delay is always there and, once again, it works except when recordings are started or stopped. So its probably additional overall delay + some time-of-day-based renegotiation of HDCP + recording start/stop. Two of three of these factors are internal to the DVR. The third is a totally reasonable - intended - configuration of HDMI.

I don't care if it is a cold restart. A cold restart would go blank for a few seconds and renegotiate a connection and then return to normal - it doesn't.

Its not a hardware problem. I can have 5 recordings starting/stopping at any other time of day and nothing breaks. I'm not going to lose many recordings on another shot in the dark guess.


----------



## unixguru (Jul 9, 2007)

harsh said:


> Wouldn't it be nice if you could assure them that it wasn't the DVR?
> 
> I had a neighbor that had a problem similar to yours. It turned out that he had a water softener that did some sort of periodic cycle and it put some sort of interference out that caused his weather station to register .01" of rain with the start of each cycle.


The DVR potentially does this 8 times a day. On a day when there are no recordings starting or stopping it does it 0 times.

So how is another device going to be any different than the DVR? Its obvious that different device is not going to exhibit this problem.

Some interference that fires exactly at 12:00, 3:00, 6:00, 9:00 every day like clockwork - and I don't mean approximate time, I mean exact time like atomic/GPS synchronized time - would be unlikely. Even if we take the leap to imagine that existing - why does its burst not affect anything unless there is a recording starting/stopping? That is just irrational.


----------



## unixguru (Jul 9, 2007)

Tom Robertson said:


> I see that gefen has unlimited support. You might call them to see if they can suggest what handshake is being dropped. They have a stake in this too. If they are dropping a handshake signal, they would want to know.


It works when the pioneer is removed. Its not the gefen.

Sony, Pioneer, and Gefen would have even less interest in solving this. As soon as you say certain time of day they will laugh. As soon as you say only when recordings on the DVR are starting/stopping they will be on the floor laughing.

Strange how problems always seem to be related to DirecTV. I moved the DVR because of noise/heat and mess of wires. I dumped the C31 because it was slow and overpriced (service). Now this problem is triggered by recordings. But my bills keep going up at multiples of inflation and the content quality is declining just as fast. Maybe I should just dump DTV.

As a software engineer I recognize the difficulty in supporting things like this. But I also see a box with internet connection that they should have the ability to get into remotely and debug. No idea if that is possible but even if it was there seems to be no way to get their attention enough to have it looked at seriously.


----------



## slice1900 (Feb 14, 2013)

Does the problem only occur when recordings are started and stopped at 12 / 3 / 6 / etc. or anytime a recording is in progress at those times?

If the former, a very simple solution would be to set the Genie to automatically pad its recordings to start 1 minute early and finish 1 minute late.


----------



## jimmie57 (Jun 26, 2010)

unixguru said:


> *It works when the pioneer is removed.* Its not the gefen.
> 
> Sony, Pioneer, and Gefen would have even less interest in solving this. As soon as you say certain time of day they will laugh. As soon as you say only when recordings on the DVR are starting/stopping they will be on the floor laughing.
> 
> ...


Have you looked for an update to the Pioneer since it is the problem ?
Do they have a Forum / Community to discuss things like this ?


----------



## unixguru (Jul 9, 2007)

jimmie57 said:


> Have you looked for an update to the Pioneer since it is the problem ?


Yes. Running latest firmware.

Its not the problem. In the past I didn't have the extender in the chain and it worked fine.


----------



## jimmie57 (Jun 26, 2010)

unixguru said:


> Yes. Running latest firmware.
> 
> Its not the problem. In the past I didn't have the extender in the chain and it worked fine.


It works when the Pioneer is out of the chain but it is not the problem.
If the extender is out of the chain it works fine.
I guess I am just confused and that is pretty easy to do but how does that make it a DirecTV programming problem ?


----------



## Tom Robertson (Nov 15, 2005)

So let me understand this:

Things worked, you added the extender, things broke, but it can't be the extender... Huh?

Your logic is that the extender doesn't know the time. 

My logic is the DVR knows the time and because the extender isn't working right, the DVR has to do what it is required to do. It is required to reset the connection when the extender isn't passing something. If the extender worked, the DVR wouldn't be required to do the reset. If it didn't have to reset, you wouldn't see even a blip. I never see blips--my signals are passing between the DVR and TV without fail. 

You've probably heard of watchdog processes and protocol acknowledgements. HDCP has a watchdog constantly verifying the content is protected. When the TV acknowledgement signal doesn't get back to the DVR, the watchdog causes the reset--as it is required to do. You should never see the flash except as part of a channel change.

So if the extender did its job, the DVR wouldn't have to do the fallback reset. Hence, this is something gefen would be very interested in solving. They don't care about time, but they do care that their device is or is not passing the proper signals back to the DVR. 

The other reason I suggest contacting gefen is they are easier to contact for this level of support. If you tell them it's just time based they might not listen. If you tell them the HDCP is resetting when it shouldn't, they should be very interested. Their products depend on not being a problem in the HDCP chain.

Peace,
Tom


----------



## Tom Robertson (Nov 15, 2005)

When you say "it is not a problem", to me that means there are no blips except on channel changes. If you still see blips when there is no channel change, that is a problem.

Peace,
Tom


----------



## inkahauts (Nov 13, 2006)

It sounds like you haven't actually tried any not the situations without these other pieces with the c31 and its latest software so that to me means you don't know which two devices or more are actually having issues. 

And this isn't a one unit causing the issue. It takes two units. 

And if anyone at geffen laughed they should be fired. They should always want to know if their products are having issues with anyone else's no matter if its on a schedule or not. They don't make cheap stuff. They make bullet proof stuff and they do that by investigating any and all issues and getting it worked out as DIRECTV does with their hdmi issues. And believe me there have been tons they have had in the past and fixed before it ever made a national release. I haven't seen any in eons though. 

My point is if anything I. The system changed (which it sounds like many things have including DIRECTV software) then you can't simply state it worked before and it's not the problem. 

If I understand right you used a DVR before and now a client in something similar to this configuration. Well DVRs aren't hdcp all the time on all Channels. Clients are. So you could have had this issue all along and never actually seen it.


----------



## peds48 (Jan 11, 2008)

the writing has been on the wall since the OP, but when a thread starts with *"Its not my cables, extender, receiver, or TV" *the troubleshooting process goes south as the TS is hell bent that is it the DVR, and cases like this, is very hard to change someone's opinion.


----------



## Tom Robertson (Nov 15, 2005)

We don't need to bring down the OP. That doesn't help anyone. Let us help each other.

OP has some good points--the DVR is the only device that knows the time and when HDCP is required. The DVR is initiating the reset--because it is required to. But that doesn't make it the DVR's fault.

There still exists the possibility that the gefen is passing through the acknolwledgements in an acceptable manner that is ambiguous in the specification. DIRECTV might not have seen this type of implementation prior to now. Is there fault? Maybe not. Is it broke? Yes. And both gefen and DIRECTV are motivated to ensure they work no matter what.  (As is Pioneer. For some reason TV makers don't seem to care and get away with all kinds of sloppy implementations.)

Peace,
Tom


----------



## peds48 (Jan 11, 2008)

Tom Robertson said:


> We don't need to bring down the OP. That doesn't help anyone. Let us help each other.


Tom, that was not my intention, rather that since the OP, I wanted to help, but since I am in the field and do this daily, when someone says IT IS my DVR, is hard to trouble shoot and try to find the real problem.

Sorry if it came like I was putting the TS down, again that was NOT my intention.


----------



## unixguru (Jul 9, 2007)

slice1900 said:


> Does the problem only occur when recordings are started and stopped at 12 / 3 / 6 / etc. or anytime a recording is in progress at those times?
> 
> If the former, a very simple solution would be to set the Genie to automatically pad its recordings to start 1 minute early and finish 1 minute late.


Thanks, *that* was a useful suggestion.

Tonight I have a recording that ends at 9:00 which I have extended to 9:02. I have another recording that starts at 9:00 which I extended to 8:58. We shall see what happens.


----------



## unixguru (Jul 9, 2007)

jimmie57 said:


> It works when the Pioneer is out of the chain but it is not the problem.
> If the extender is out of the chain it works fine.
> I guess I am just confused and that is pretty easy to do but how does that make it a DirecTV programming problem ?


Everything in the chain is going to add some small amount of signal/acknowledgement delay. The problem appears to be the sum of the delays combined with things happening in the DVR.

If the Pioneer without the extender works then it probably doesn't have a protocol problem. Ditto with extender without Pioneer.

You can't "fix" this by removing necessary components.

*IF* this was not correlated to recordings start or stopping then there would be a lot more reason to doubt these other components.

AGAIN, think about this - when no recordings are starting or stopping then this could run forever and NEVER show symptoms. Why is that if the Pioneer is to blame or the extender or the TV?


----------



## unixguru (Jul 9, 2007)

Tom Robertson said:


> So let me understand this:
> 
> Things worked, you added the extender, things broke, but it can't be the extender... Huh?
> 
> ...


I don't remember seeing this problem immediately after installing the extender. Even if I did, again, any component in the chain is going to add a delay. The sum of my delays is more than the DVR is happy with. Again, I can't/won't remove necessary components.

Your logic... so no recording is starting or stopping and the DVR "has" to do something at a certain time. It does it - and the problem doesn't appear. One could blame the momentary blink on other components. One cannot blame the failure during recording start/stop on them.

Full hard reset doesn't mean anything. Full hard reset would recover and then continue on. The DVR is the only thing that knows the channel changed and that is all that brings it out of this broken state. So again, it has to be the DVR.

The flash is because the DVR *first* assumes that the link is unauthenticated (going black) and then tries to reauthenticate. Which in my software engineers mind is the wrong way to do it. The extra delays add up to a fraction of a second that happen to be visible. Its probably flashing black in every situation its just so fast that nobody sees it.


----------



## unixguru (Jul 9, 2007)

inkahauts said:


> It sounds like you haven't actually tried any not the situations without these other pieces with the c31 and its latest software so that to me means you don't know which two devices or more are actually having issues.
> 
> And this isn't a one unit causing the issue. It takes two units.
> 
> ...


I don't have the C31 any more.

No, its not two units. Its only more than 2 - pick any more than 2.

Your statement about gefen is right. And it applies absolutely equally to DTV. Now compare the boxes - DTV is a computer with a Linux-like software environment and a full time internet connection. The gefen is mostly hardware with a little bit of firmware. Which is easier to debug?

Next thing you guys are going to tell me to put an HDMI protocol analyzer in line :bang

"So you could have had this issue all along and never actually seen it."

:nono2: The blink doesn't bother me. I think I would have seen it locking into a state of HDCP failure.


----------



## unixguru (Jul 9, 2007)

peds48 said:


> the writing has been on the wall since the OP, but when a thread starts with *"Its not my cables, extender, receiver, or TV" *the troubleshooting process goes south as the TS is hell bent that is it the DVR, and cases like this, is very hard to change someone's opinion.


You say prove its the DVR. I say prove its not. I've done a lot of stuff to analyze this situation - I've done a lot to *eliminate* those possibilities. I didn't just puff it out my... The *probability* is high that it is the DVR.

I don't have a spare Pioneer Elite to try. I don't have a spare Gefen to try. Or TV for that matter. Nobody is going to send a replacement - free or otherwise for any of those components. For the 100th time, if it wasn't tied to time-of-day and record start/stop then they might care.

Representing the "company" you are going to do what everyone else here is doing - place the blame anywhere but DTV. Good old finger pointing.


----------



## unixguru (Jul 9, 2007)

This pattern of finger pointing is something I easily recognize from my professional activities. It doesn't happen as often as it used to but it still happens. In those cases I am one of the vendors involved.

I don't go around implying the customer is obviously wrong. There is only so much a customer can do. You don't demand that they prove it is broken. You look at the data that they are able to give. Unless you have a rational idea of what is wrong - an idea that they can easily test - you don't push it back. Customers don't have the tools it takes to debug these things.

As a vendor we have spent tens of millions of dollars buying equipment for compatibility testing. We get a lot of hardware on loan too. When we have a compatibility problem we put together the closest situation we can if we can't debug it in other ways (like instrumenting code for the customer to run). We have protocol analyzers - truly expensive test hardware. In other words, tons more resources than a customer.

The most obvious thing I can say is this - we actually take customer problems seriously. We answer the phone/email/whatever. We actually have qualified people looking at things after they have been properly escalated. What does DTV do? First they prevent customer communication with anybody that has a clue. They take problem reports and flush them as far as I can tell. This is why I waste my time posting info here.

I think I could spend days doing all the testing that is being proposed here and be no closer to the answer. The response will always be that it couldn't be DTV - it must be the other guy; go do something with them. Thanks but no thanks. I'll do a bit more then I'm done.

I once sat at a customer site debugging a problem on a new superminicomputer. I found a microcode flaw (for ye young ones thats firmware that implements a CPU). I sent the details to hardware engineering and they fixed it. It occurs to me that I could point at the line of code that is broken - if I could see it - and some would still say it wasn't DTV's fault; not to mention there would be no way to communicate the problem to DTV.

The world of disposable junk is just getting worse and worse...


----------



## Tom Robertson (Nov 15, 2005)

I'm trying to help. Most of us here are trying to help. We are volunteers, not spokespersons for any company.

What did you do when the customer refused to run the diagnostic tests recommended? 

I am NOT saying it is not the DVR's fault. I am definitely saying the DVR is probably starting with what it is required to do, verify the hdcp. You should never see it happen. That does not imply the DVR is wrong, it does not imply the DVR is right, beyond initiating a reset it is required to do. Because you see the reset, it does imply something is very wrong. 

I would like to reset this conversation, go back to the beginning and basics. My goal is to see if we can create an understanding of the problem that will help DIRECTV, Gefen, Pioneer, and perhaps Sony. The tasks are not necessarily to define fault, but to help diagnose the problem players.

Peace,
Tom


----------



## harsh (Jun 15, 2003)

Tom Robertson said:


> OP has some good points--the DVR is the only device that knows the time and when HDCP is required.


HDCP shouldn't have any interaction with the recording process; it should be uniquely a playback thing. Reasoning that the start or stop of a recording is creating a HDCP request of any kind doesn't make sense -- although it is possible that the DVR is doing it anyway because of brain dead programming.

HDCP refreshes happen much more often than every three hours. When it does do the refresh, it is supposed to be happening during the VBI so it isn't apparent. This suggests that something is dragging its feet past the VBI and this would be either the extender or the TV itself absent the AVR. I would guess that the negotiation is handled in hardware and software wouldn't have much impact on how quickly it was processed by each device.

It would appear that the AVR is bamboozled by the delay and causing an full HDMI handshake negotiation.


----------



## Tom Robertson (Nov 15, 2005)

That is my point. The refreshes should be ongoing and continuous. And "something" is preventing the watchdog from getting the refresh acknowledgements. So every three hours the DVR is doing the next right thing, a full reset.

So what is causing the watchdog from seeing the acknowledgements? In theory, the gefen should not be the cause, based on the description, it should be just a passive signal regenerator. Not even decrypting and re-encrypting the data.

The Pioneer should be acting as an HDCP repeater, decrypting and re-encrypting the data. And the TV decrypting as a sink device. From a Crestron white paper on hdcp: http://www.crestron.com/downloads/pdf/featured_articles/152/The_Complexities_of_HDCP.pdf


> Repeaters. Adding an HDCP repeater to an installation greatly increases occurrence of problems. Repeaters are especially prone to problems because they have responsibilities of both a transmitter and a receiver. Add multiple inputs and outputs to the repeater, and the problem increase accordingly.


So we have at least one, possibly two hdcp repeaters: the pioneer (definitely) and gefen (possibly.) Neither company wants to be the one that is not playing nicely, not passing back the proper acknowledgements. Gefen particularly so, that is their only job. And my thinking is that gefen has a support structure that DIRECTV does not--handling problem hdcp connections.

My goal is to completely get rid of the blips. They are the symptom someone isn't playing nice. The DVR is doing the right thing by reseting, which causes the blips. But who is preventing the DVR from getting the acknowledgement? The DVR? The Gefen? The Pioneer? The TV itself? (In this case, I actually don't think it is the TV as the Pioneer "should" acknowledge its own receipt of the signal--but the TV could be doing something so wrong it gums up the whole chain.)

Peace,
Tom


----------



## slice1900 (Feb 14, 2013)

The process of starting/stopping a recording is probably a fairly high priority task in the Genie's software. If the HDMI reauthentication is not happening for whatever reason as Tom suggests and the 'watchdog' reset is delayed by that higher priority processing, who's fault is that? Perhaps ideally the watchdog reset should be a higher priority task, but if it is a problem with the other equipment that causes HDMI reauthorizations to fail that necessitates the reset, I'd point the finger at them.

I don't have any idea what the true cause is, but the insistence that the HR34 must be to blame because it only occurs when recordings are starting/stopping on a three hour boundary seems misplaced. There isn't enough evidence to conclusively rule out anything being to blame - the Pioneer may have worked before with the HR34, the rest of the chain may work fine with a Client in place of the HR34, but that doesn't mean it couldn't be some sort of incompatibility between the Gefen and the Pioneer or the Pioneer and the TV that is the root cause. There could have been a problem with the Pioneer and TV all along but HDMI resets were occurring silently enough before that the problem was invisible until the chain got longer.


----------



## inkahauts (Nov 13, 2006)

Ok here is a wild idea. If this is in fact an hdcp issue maybe get a hdmi splitter that does hdcp. Put it right after the hr and then it in theory will take care of all hdcp and then if this is in fact the issue it won't come up again. 

Monoprice has them for about $32 plus shipping. I have one works great. 

And now that I see its a genie what software is it running right now?


----------



## inkahauts (Nov 13, 2006)

unixguru said:


> I don't have the C31 any more.
> 
> No, its not two units. Its only more than 2 - pick any more than 2.
> 
> ...


Does it happen on any channel? Because I'm not to sure it checks for hdcp if you aren't on a channel that requires it. I'm under the impression only the clients would do that.

And do you have any other non genie units in the house you could swap with the genie to see if the issue disappeared?


----------



## unixguru (Jul 9, 2007)

slice1900 said:


> Does the problem only occur when recordings are started and stopped at 12 / 3 / 6 / etc. or anytime a recording is in progress at those times?
> 
> If the former, a very simple solution would be to set the Genie to automatically pad its recordings to start 1 minute early and finish 1 minute late.


Last night I had a recording from 8:00-9:00 that I changed to end at 9:01. Also another recording that was 9:00-10:00 that I changed to start at 8:59. I was watching NBC live at the 9:00 transition. I even had a video camera recording it.

Nothing. Absolutely nothing wrong. Not even brief flash to black. Went back and looked at what the camera recorded - no black.

I am 99.9% certain that if I had not changed the start and stop times that it would have gone into the failed state and stayed there until I changed the channel or exited playback of a previously recorded program.


----------



## unixguru (Jul 9, 2007)

The Pioneer is definitely a repeater. I also have a Mac Mini connected to it and it reports the device as a Pioneer, not a Sony.

I still believe it is highly unlikely that any of the devices in the chain are not operating correctly. As has been said, the HDCP is refreshed/verified constantly. If one of the devices happens to drop the ball momentarily what is the expected behavior? The DVR should think the link is potentially broken and it should reestablish it. That process should have a period of retries (that is, when first suspecting trouble, don't immediately terminate the link). If the retries fail over some *reasonable* period then the link should be terminated (black screen/no audio). Then what? It should immediately return to the same state it has when first powered on - "cold" setup. Worst case, black screen/no audio for a somewhat longer period and then return to normal.

In my OP I said

turning the TV or receiver off/on doesn't help
By receiver I meant the audio receiver. So they both go to a cold state with no link. *Why isn't the DVR resetting the link then?*

Again, going into this failed state only happens when a recording is starting or stopping. Getting out of the failed state requires changing the channel or exiting playback. Again, none of the other devices have any knowledge of those.

Is there a list of channels that use HDCP? The majority of these events are not premium movie channels on any of the recordings, live, or playback. Perhaps this isn't HDCP related as I only see snow or pink rarely - perhaps those are the times when the recording/live/playback is a premium movie channel. Maybe its just HDMI problem in general.

I suppose I could try an HDMI splitter. I have been thinking of putting a switch at the DVR so maybe I will look for a small matrix switch (yes, I realize that matrix is required as that is the only way it would contain a HDCP repeater).

Has anyone ever connected their storage to a computer and looked for log files? Surely this event would be logged.

HR34 is running 0x987.


----------



## unixguru (Jul 9, 2007)

Tom Robertson said:


> What did you do when the customer refused to run the diagnostic tests recommended?


It depends on how many tests they *did* run. If they refuse to do the most basic/reasonable things then I can't help them.

Tests usually have escalating demands for complexity and time required. At some point it becomes unreasonable to expect a customer to do it.

Compare this issue to an enterprise situation. Lets say two computers separated by miles with a network switch at each with a fiber link between the switches. Is it reasonable to ask the customer to "remove the extender"? Move one computer to another to eliminate the extender? Regardless, its pointless to just throw ones arms in the air and point the finger at the network. The network vendor will do the same. The way it needs to be solved is for the software/computer vendor to provide detailed information *proving* that it is a network problem. The level of info that can be taken to the network vendor and they will accept it as proof. Why not the other way around? The network is a much lower level element and it has less state and is more difficult to debug. Ideally both the software/computer and network vendor would work the problem together but that usually doesn't happen; even if they did, debugging starts at the computer.

Contrary to popular belief, the customer is not the vendors QA and engineering department.

*People pay money for products that work*. They don't pay money for the privilege of helping the vendor fix their products.


----------



## damondlt (Feb 27, 2006)

I'm guessing you don't have a friend or family member you can borrow another HR34 or even a 44?

Sorry if it was already answered, but there was alot of guff in response to your questions that I didn't feel like reading.

I had a similar issue, it ended up being a faulty HDMI on the HR34, it was swapped out and the issue disappeared.

I think your problem is you need to get rid of that door stop.


----------



## damondlt (Feb 27, 2006)

Also forgot to add I have $16 dollar extenders. Nothing fancy, they were extending about 50 feet.


----------



## tritch (Jan 15, 2008)

unixguru said:


> Very frustrating that there is no way to report a technical problem to DirecTV electronically. Useless talking to a customer service rep about this kind of thing. So here I blow it into the wind on the slim chance...
> 
> My setup: HR34 -> Gefen 4K Ultra HD HDMI Extender -> Pioneer Elite SC-72 -> Sony XBR-65HX929
> 
> ...


Looking at your OP, I've highlighted your original statement. What conclusive evidence do you have that this issue has anything to do with HDCP? You haven't mentioned ever seeing any DVR messages pop up on the TV indicating a HDCP problem. Generally, HDCP compliance will either work or doesn't. It shouldn't be doing anything different at any fixed time intervals.

IMO, your bullet point issues don't seem to be symptomatic of a HDCP problem. Your TV screen should simply go dark w/ a likely pop-up message. Your TV screen flickering, sometimes going snowy or pink is not indicative of an HDCP shutdown. It still may be a faulty DVR, but I would definitely be digging deeper for any other possible causes.....


----------



## WestDC (Feb 9, 2008)

or change out the 5 yr old AVR and the problem will be solved


----------



## dennisj00 (Sep 27, 2007)

How about simply posting in the issues thread for your firmware version with a Report ID (search for Sendreport if it's not in your Misc. Options) and send that Report ID to Gefen and Pioneer in support emails with the details? They should be able to contact the DTV engineers to resolve the problem.

Posting in this thread with finger pointing or defending anything in the chain does no good.


----------



## unixguru (Jul 9, 2007)

tritch said:


> Your TV screen flickering, sometimes going snowy or pink is not indicative of an HDCP shutdown.


Do tell. Snowy or pink has frequently been a symptom associated with HDCP on this forum.

I'm not an HDMI engineer nor do I want to be. But finger pointing by vendors - and pundits here - forces one to narrow the possibilities. It could very well have nothing to do with HDCP. I may simply be HDMI in general. But it doesn't matter. The connection from the DVR to the TV has a problem.


----------



## unixguru (Jul 9, 2007)

WestDC said:


> or change out the 5 yr old AVR and the problem will be solved


Wow. The SC-72 was released in May of 2013. The math is *<2* years. I purchased it new about a year ago.

Perhaps you were attempting to inject some humor here - what others would recommend as the solution; i.e. replace anything and everything but the likely cause.


----------



## WestDC (Feb 9, 2008)

unixguru said:


> Wow. The SC-72 was released in May of 2013. The math is *<2* years. I purchased it new about a year ago.
> 
> Perhaps you were attempting to inject some humor here - what others would recommend as the solution; i.e. replace anything and everything but the likely cause.


Sorry I upset you  I put this response in the wrong thread - The Receiver in that thread was new in 2010 - The op was having same issue only blank screens

Should have been directed to this

http://www.dbstalk.com/topic/216868-hdmi-issues-with-brand-new-hr44-and-pioneer-receiver/


----------



## unixguru (Jul 9, 2007)

dennisj00 said:


> How about simply posting in the issues thread for your firmware version with a Report ID (search for Sendreport if it's not in your Misc. Options) and send that Report ID to Gefen and Pioneer in support emails with the details? They should be able to contact the DTV engineers to resolve the problem.
> 
> Posting in this thread with finger pointing or defending anything in the chain does no good.


I'm not familiar with sendreport. When I search for it I don't see any explanation of what it does. I imagine it uploads some diagnostic data and tags it. Fine.

I don't think this problem appeared with the current release. So it is still correct to report this to that thread just because it too has the problem?

I couldn't help but notice that you say send the report id to Gefen and Pioneer - *you don't mention DTV*. Why in the world would I start with them first? Either one can be removed from the chain and the problem goes away. Without the Gefen Pioneer will say its not their problem; without the Pioneer Gefen will say its not their problem.

I would also mention that I cannot see the screen enough to be able to do a sendreport when it is happening. What possible value could it be when things are working? Surely DTV can trigger a dump of the diagnostics any time they want.

*The problem is how does a customer get the attention of DTV engineering?????* I know what happens when one calls/chats/emails - *nothing*.

I'm posting here because of the frustration of not being able to get *anyone* to care about looking at the problem.


----------



## inkahauts (Nov 13, 2006)

unixguru said:


> I'm not familiar with sendreport. When I search for it I don't see any explanation of what it does. I imagine it uploads some diagnostic data and tags it. Fine.
> 
> I don't think this problem appeared with the current release. So it is still correct to report this to that thread just because it too has the problem?
> 
> ...


Do a send report right after. They can look at its logs and see. They don't really pull those logs I think. It's easier to shuffle through and look for the report that you send and state exactly what was going on. Not sure if they can initiate a log report on their end like that anyway to be honest.

And honestly I still haven't seen you say anywhere that you tried removing everything and adding one at a time back in with this particular device on this particular software. Did you? Or was it when you had the other unit connected? A lot going on in this thread so hard to tell.

Do you know anyone with a hr44? I'd see about borrowing it and see init has the same issue. I'd almost bet it doesn't.


----------



## dennisj00 (Sep 27, 2007)

unixguru said:


> I'm not familiar with sendreport. When I search for it I don't see any explanation of what it does. I imagine it uploads some diagnostic data and tags it. Fine.
> 
> I don't think this problem appeared with the current release. So it is still correct to report this to that thread just because it too has the problem?
> 
> ...


When you do a keyword search for 'SENDREPORT' it sends diagnostic information to DTV engineers -- the best way to get their attention is post this report ID - it's in the form of 2015mmdd - xxxx - in the current issues thread for your HR.

They monitor the issues threads but not others.

And then send this ID # to Gefen and Pioneer for them to reference with DTV.

You may or may not hear from anyone. It may just start working correctly with the next update of one or the other.

You also have to realize that your configuration is fairly rare and may not get the attention you think it should.


----------



## unixguru (Jul 9, 2007)

inkahauts said:


> Do a send report right after. They can look at its logs and see. They don't really pull those logs I think. It's easier to shuffle through and look for the report that you send and state exactly what was going on. Not sure if they can initiate a log report on their end like that anyway to be honest.
> 
> And honestly I still haven't seen you say anywhere that you tried removing everything and adding one at a time back in with this particular device on this particular software. Did you? Or was it when you had the other unit connected? A lot going on in this thread so hard to tell.
> 
> Do you know anyone with a hr44? I'd see about borrowing it and see init has the same issue. I'd almost bet it doesn't.


I have removed the Pioneer because that was pretty easy. The problem didn't occur. So that means the Gefen is working. I said that before in this thread.

Before I installed the Gefen the DVR was right beside the Pioneer and worked fine. So its not likely its the Pioneer. To get to that configuration requires hauling equipment between floors - I'm disabled and that isn't easy. Doing so will prove nothing. If it still didn't work then the blame here will be aimed at Pioneer, which is still illogical given the association of time-of-day and recording activity. If it did work then the blame will be aimed at the Gefen. Which I just proved above is working correctly. It is more likely that the problem simply won't show up without *both* the Pioneer and Gefen in the chain.

Why don't we add wire to these circular finger pointing exercises.

The Sony TV, Pioneer AVR, and DVR all have firmware that has likely been updated over time. There is no way to roll this back.

My son is home from college next week so I will have him help get our other DVR, a HR24, down to the source end of the extender. He also has a Mac with an HDMI connector so I will check to see if the Gefen extender looks like a Gefen to the Mac or a Pioneer - I'm betting it looks like the Pioneer. So what will the HR24 prove? If the problem is still there then it could still be a DTV software problem. If the problem isn't there... it could still be a DTV software problem (in the Genie only) [or, a problem with the speed of an HR34!].

I don't see any scenario where I can prove that it is *not* a DVR problem. Pulling pieces out of the chain changes the timing so could easily be the difference between the DVR software problem being apparent or not. Putting any other non-DVR device at the source simply isn't going to show this problem - they don't start/stop recordings.

So I'm right back to where I started. It doesn't work. Its all HDMI compliant equipment connected in a supported way. No way to prove who is at fault. No way to get anyone to look into it.


----------



## unixguru (Jul 9, 2007)

dennisj00 said:


> When you do a keyword search for 'SENDREPORT' it sends diagnostic information to DTV engineers -- the best way to get their attention is post this report ID - it's in the form of 2015mmdd - xxxx - in the current issues thread for your HR.
> 
> They monitor the issues threads but not others.
> 
> ...


Ok, fine, I'll do sendreport, post to issues, and refer to this thread.

Yep, blowing in the wind. Standard operating procedure these days. As is only paying attention to the problems that are big enough to impact revenue.

I hear the same excuse about RAID. Sounds like they are getting ready to stick a fork in that too. At this point I'm half hoping they do - will be the last straw and I'll just toss all DTV crap out.


----------



## Beerstalker (Feb 9, 2009)

Cutouts/pixelization/discolored pink/green are not signs of HDCP issues. Those are signs of a weak HDMI signal. Its usually caused by a defective cable, or too long of a distance.

HDCP issues results with no picture at all, because as soon as there is an HDCP handshake issue DirecTV receivers kill all video output.

So to me it sounds like you are stretching your HDMI signal too far, and by the time it goes through all those components and that lenght it is right on the verge of being too weak when it reaches your TV. That is why sometimes it works fine, and sometimes it doesn't. That is why removing any one component (which reduces both the length the signal is travelling, and the items it is travelling through) seems to help.

Is there any way you can swap out your HDMI cable with shorter versions, or Redmere cables, or cables with larger gauge wires?


----------



## unixguru (Jul 9, 2007)

Beerstalker said:


> Cutouts/pixelization/discolored pink/green are not signs of HDCP issues. Those are signs of a weak HDMI signal. Its usually caused by a defective cable, or too long of a distance.
> 
> HDCP issues results with no picture at all, because as soon as there is an HDCP handshake issue DirecTV receivers kill all video output.
> 
> ...


Which would all be completely reasonable... until you know that it never does this other than specific times of day, exactly on the hour, and then only when a recording is also starting and/or stopping. If it were a cable problem then it should be random. In 6+ months of this I have never seen it under any other circumstances with 6+ hours of viewing a day.

HR34 to Gefen transmitter: 3' or less
Gefen to Gefen: <50' of Cat5E (extender supports up to 330')
Gefen receiver to Pioneer: 3' or less
Pioneer to TV: ~15' (heavy duty HDMI cable)


----------



## unixguru (Jul 9, 2007)

My son and I just connected his MacBook in place of the HR34. The Mac "sees" the Pioneer Elite SC-72 as the device. Gefen support also confirmed that the extender is not an HDMI repeater.

So the extender is just an electrical extender (with appropriate signal regeneration to cleanup edges and timing). It should do nothing other than have a fixed delay + fixed propagation delay for the wire.

I guess I have to buy a splitter or matrix switch and put it between the DVR and the extender. Then there will be an HDMI repeater right on top of the damn thing. I'm not convinced that will hide the timing issues.


----------



## Beerstalker (Feb 9, 2009)

I don't think a splitter or matrix switch is going to do anything. Like I said, this is not an HDCP error, if it was you would lose all video output instead of getting a garbled/discolored picture.

Do you have a way to test the Cat5e cable and make sure it isn't introducing too much loss?

Have you tried replacing the HDMI cables with Redmere cables?

Personally the first thing I would try is replacing the 3ft HDMI cable from the Gefen to the Pioneer with a Redmere cable, and the 15' cable from the Pioneer to the TV with a 15' Redmere cable. I don't believe you can replace the 3 ft cable between the gefen and the HR34 as I don't think it can get enough power from the Gefen to work.


----------



## unixguru (Jul 9, 2007)

Beerstalker said:


> I don't think a splitter or matrix switch is going to do anything. Like I said, this is not an HDCP error, if it was you would lose all video output instead of getting a garbled/discolored picture.
> 
> Do you have a way to test the Cat5e cable and make sure it isn't introducing too much loss?
> 
> ...


I've ordered a cheapo $15 splitter on eBay. That is an HDMI repeater so we will see.

I don't have a cable tester let alone one that measures signal quality.

What is with this Redmere stuff that keeps coming up? That is just a cheapo signal regeneration method that lets them make cables with a lot less copper in them (cheaper). The Gefen extender is also a signal regeneration device and its top-of-the-line stuff - it cost me a bit over $300 (list is $499!). There is nothing wrong with the Gefen or my cat5e.

Redmere cables at 3ft makes no sense whatsoever.

Cables don't know the time of day or recording activity.

There has not been a single post in this thread that presents a credible argument for anything other than the DVR being the problem.


----------



## Beerstalker (Feb 9, 2009)

Well, it seems to me like you had a few people trying to help, but your inability to take anyones advice into consideration has run most of them off, including me now. Good luck.


----------



## peds48 (Jan 11, 2008)

Exactly what I said a few post back. I saw this from the beginning, even one of the mods wanted to help, but with so little cooperation, is hard to try to help. Although I did wanted to get to the bottom of this. It was vey interesting.


----------



## unixguru (Jul 9, 2007)

Suggestions have been:

 Eliminate devices or wires
Replace devices or wires
Dump the problem on any vendor other than DTV
Repeat some test that has already been done
I have done a *lot* of things to try to isolate the problem. The general theme here has been that if any single action removes the problem then the problem is solved. Of what use is that? Especially when the item removed can be placed back in and another item removed and the problem also goes away *strongly* suggesting that the problem is neither of them.

How many of you would spend hundreds of dollars to just "try" some replacements? Or any other time consuming exercise that couldn't possibly help isolate the problem. I mean really, how can a cable have anything to do with a problem that appears based on state that is only known within the DVR? Thats called a wild goose chase. Pardon me for not playing.

Many people in these forums offer opinions that are beyond their qualifications. I understand that they are trying to help but I wish they would consider that their opinions are doing the opposite. If one objectively observes this forum there is far too much fanboy stuff going on and useful information is like a needle in a haystack. Less information of higher quality is always better.

I knew this was a poor place to discuss this kind of problem. I wouldn't be here if it weren't for the utter failure of DTV to provide useful support for complicated problems.

I don't know why I bother visiting here. Every problem is either my non-DTV equipment or my failure to comply with every wild idea presented. So I guess I'm the one that has to run off - permanently.


----------



## texasbrit (Aug 9, 2006)

I think there is a strong feeling that you have blinders on also. There's nothing in what you have presented that pinpoints the issue as being in any one of the elements in your system. You also seem to think the "cable" can't be part of the problem, but it's an active device, not simply a passthru. If you replace the Gefen with a regular HDMI cable, the problem goes away, yes? Your frustration seems to be that DirecTV won't invest resources in trying to find out why your particular configuration does not work. Gefen and Pioneer won't do that either. In many ways I don't blame any of them. You might be the only person in the world with this configuration, and DirecTV and Pioneer would probably tell you the config is non--standard, and the commercial reality is that they are not going to invest resources in a one-off. IMHO if anyone "should" look at this more closely it's probably Gefen.


----------



## slice1900 (Feb 14, 2013)

unixguru said:


> Many people in these forums offer opinions that are beyond their qualifications.


Just as you are offering a diagnosis that is beyond yours.


----------



## unixguru (Jul 9, 2007)

texasbrit said:


> I think there is a strong feeling that you have blinders on also. There's nothing in what you have presented that pinpoints the issue as being in any one of the elements in your system. You also seem to think the "cable" can't be part of the problem, but it's an active device, not simply a passthru. If you replace the Gefen with a regular HDMI cable, the problem goes away, yes? Your frustration seems to be that DirecTV won't invest resources in trying to find out why your particular configuration does not work. Gefen and Pioneer won't do that either. In many ways I don't blame any of them. You might be the only person in the world with this configuration, and DirecTV and Pioneer would probably tell you the config is non--standard, and the commercial reality is that they are not going to invest resources in a one-off. IMHO if anyone "should" look at this more closely it's probably Gefen


The "dumbest" component in the chain. It is an electrical repeater - nothing more. It adds a tiny fraction of a second to signal propagation. If that is the problem then what you're saying is that DTV won't support any kind of extender.

Part of this is trust in companies. I've used a number of Gefen products over the years and they have never ever once had a problem. The complete inverse of DTV.

So much discussion here is about components in the chain (placing blame other than DTV). Everybody just wants to gloss over the detail about it only happening at time-of-day plus recordings start/stopping. *I have yet to hear a single reason why any of the components in the chain could or would behave that way.*


----------



## unixguru (Jul 9, 2007)

slice1900 said:


> Just as you are offering a diagnosis that is beyond yours.


Degrees in physics, electrical engineering, and software engineering are as qualified as it gets here. Plus 35 years practicing large-scale software/computer engineering.

I can only diagnose given the tools that are available to me. These are all essentially black boxes. Not much to work with.

Sorry that I don't illogically conclude that it couldn't be the DVR.


----------



## inkahauts (Nov 13, 2006)

unixguru said:


> The "dumbest" component in the chain. It is an electrical repeater - nothing more. It adds a tiny fraction of a second to signal propagation. If that is the problem then what you're saying is that DTV won't support any kind of extender.
> 
> Part of this is trust in companies. I've used a number of Gefen products over the years and they have never ever once had a problem. The complete inverse of DTV.
> 
> So much discussion here is about components in the chain (placing blame other than DTV). Everybody just wants to gloss over the detail about it only happening at time-of-day plus recordings start/stopping. *I have yet to hear a single reason why any of the components in the chain could or would behave that way.*


Well there's no way this is one components fault. It's two or more. And everyone has asked you to try a few things to determine what exact products are causing the issue then to get in touch with all the manufactures of the products having the issue and. Hovering them all the info you can so they can work it out.

And the test need to all be done now with the latest software on all machines. It sounds like you've done some of the different configurations before and some after. I have never been clear on this. Only that you have the HR34 now and seems like you bypassed the pioneer.

It will be one sided I'm sure they don't tell people what they find or often when the fix it it just works again someday.

You also assume you know exactly what is causing the issue. I'm not positive especially with one component being an HR34.

Again Id ask for a hr44 and keep at it till I got it.

Also do you only have genies and minis? And have you tried swapping places again since you tatted this thread to see if the other DIRECTV recieres have this issue now as well?

And by the way it did just hit me, you can send a report about the server from a client during one of these issues. Pm me and I'll explain how.


----------



## texasbrit (Aug 9, 2006)

unixguru said:


> Degrees in physics, electrical engineering, and software engineering are as qualified as it gets here. Plus 35 years practicing large-scale software/computer engineering.
> 
> I can only diagnose given the tools that are available to me. These are all essentially black boxes. Not much to work with.
> 
> Sorry that I don't illogically conclude that it couldn't be the DVR.


I could stack my experience aginst yours any day. But my issue is that you seem to logically conclude it IS the DVR. None of the tests you made lead to an absolute conclusion. And the Gefen isn't just an electrical extender. There's almost certainly buffering involved at both ends. And the HDCP compliance test involves going through the cable at least twice. So if the TV isn't responding quickly enough to the HDCP compliance test the DVR requires (passing through the AV receiver and the extender) the results would be as you see,


----------



## unixguru (Jul 9, 2007)

texasbrit said:


> I could stack my experience aginst yours any day. But my issue is that you seem to logically conclude it IS the DVR. None of the tests you made lead to an absolute conclusion. And the Gefen isn't just an electrical extender. There's almost certainly buffering involved at both ends. And the HDCP compliance test involves going through the cable at least twice. So if the TV isn't responding quickly enough to the HDCP compliance test the DVR requires (passing through the AV receiver and the extender) the results would be as you see,


It is impossible for any of us to come to an absolute conclusion. We wouldn't be having this conversation if vendors supported their customers.

My understanding (I have *not* read the entire spec nor am I an HDMI engineer) is that the TV does *not* respond to the DVR in this setup. The Pioneer is an _HDMI repeater_ which means the DVR "sees" the receiver, not the TV (confirmed with a Mac). A repeater is a licensed HDMI product - the signal becomes decrypted within a repeater; that is, the encryption on the source side link is completely different from the encryption on the sink side link. It follows that the negotiation is therefore independent. HDCP is based on point-to-point trust based on the license. The DVR trusts the Pioneer and the Pioneer trusts the TV. This is only logical - it eliminates the timing issues you suggest. If it didn't work this way, how would a splitter work? If there was a hierarchy of a dozen TVs connected through multiple nested splitters... is the DVR going to know about every one of them? Unlikely.

I repeat ( :roundandr ) once again: *Why does this never happen outside of the limited circumstances of time-of-day and recordings starting/stopping?*

To conclude that it is any device other than the DVR requires that it happen outside of those circumstances.

Once again: *If any other component is behaving badly such that the DVR breaks the link, why doesn't the DVR recover? If the failure to recover is due to another flaw in another component, why does changing the channel on the DVR fix it?*

Fault analysis is about probabilities. The symptoms here reduce the probabilities of it being a problem with the chain of devices and increase the probability of it being the DVR.


----------



## jimmie57 (Jun 26, 2010)

Do you or a friend have another DVR, maybe and HR2X that you could swap out for a little while to see if the HR2X model does this also ?


----------



## harsh (Jun 15, 2003)

unixguru said:


> I have done a *lot* of things to try to isolate the problem.


The concern for me is that some of the recommended tests have been conducted in theory rather than physically executed.

Reasoning/rationalization is a crutch that assumes you understand all aspects of what is going on.


----------



## slice1900 (Feb 14, 2013)

unixguru said:


> HDCP is based on point-to-point trust based on the license. The DVR trusts the Pioneer and the Pioneer trusts the TV. This is only logical - it eliminates the timing issues you suggest. If it didn't work this way, how would a splitter work? If there was a hierarchy of a dozen TVs connected through multiple nested splitters... is the DVR going to know about every one of them? Unlikely.


This is not correct. The HDCP spec requires the DVR know about every TV connected through a hierarchy of splitters or other repeaters, unless it doesn't support enough keys in which case only some of the TVs will display video at all. You may want to read this article: http://www.crestron.com/downloads/pdf/featured_articles/152/The_Complexities_of_HDCP.pdf

I also looked up the frequency of HDCP reauthentication. It happens "approximately" every two seconds, so whatever your issue is, it has nothing to do with HDCP reauthentication timing out after three hours.


----------



## peds48 (Jan 11, 2008)

This part from that document is very interesting...



> Repeaters. Adding an HDCP repeater to an installation greatly increases occurrence of problems. Repeaters are especially prone to problems because they have responsibilities of both a transmitter and a receiver. Add mul- tiple inputs and outputs to the repeater, and the problem increase accordingly.





> http://www.crestron....ies_of_HDCP.pdf


This leads me to believe that these folks would appreciate learning what is causing trouble with their gear, unlike popular belief


----------



## slice1900 (Feb 14, 2013)

peds48 said:


> This leads me to believe that these folks would appreciate learning what is causing trouble with their gear, unlike popular belief


Crestron makes very high end gear - very expen$$$ive, makes Gefen gear look like Monoprice and Pioneer like no-name "ships from mainland China" on eBay by comparison! But they do provide _very_ good support for that price, or so I hear.


----------



## peds48 (Jan 11, 2008)

slice1900 said:


> Crestron makes very high end gear - very expen$$$ive, makes Gefen gear look like Monoprice and Pioneer like no-name "ships from mainland China" on eBay by comparison! But they do provide _very_ good support for that price, or so I hear.


Yeah, I ised to deal with Crestron products a lot on my days I used to deal with those kind of folks. What I dislike about their products besides their prices of course, is the lack of consumer support. A reprogram of a remote requires an installer visit which of course can get very expensive.


----------



## unixguru (Jul 9, 2007)

harsh said:


> The concern for me is that some of the recommended tests have been conducted in theory rather than physically executed.
> 
> Reasoning/rationalization is a crutch that assumes you understand all aspects of what is going on.


I'm not going to do them because they won't prove anything to the satisfaction of everyone here. Its all cost with no benefit.


----------



## unixguru (Jul 9, 2007)

slice1900 said:


> This is not correct. The HDCP spec requires the DVR know about every TV connected through a hierarchy of splitters or other repeaters, unless it doesn't support enough keys in which case only some of the TVs will display video at all. You may want to read this article: http://www.crestron.com/downloads/pdf/featured_articles/152/The_Complexities_of_HDCP.pdf
> 
> I also looked up the frequency of HDCP reauthentication. It happens "approximately" every two seconds, so whatever your issue is, it has nothing to do with HDCP reauthentication timing out after three hours.


I stand corrected - sort of. That document is very superficial. Try http://www.digital-cp.com/files/static_page_files/DAD40C4C-1A4B-B294-D0E92C72CFE974A0/HDCP%20Specification%20Rev1_4_Secure.pdf The keys (and topology info) are used for revocation and limiting the topology. Revocation is the ability to revoke a previously issued key (license). Encryption is still done point-to-point.

The 2 seconds you refer to is only part of the protocol and only applies to each point-to-point link independently. I also saw 1ms, 100ms, and 5s elements to the protocol. The 5s appears to be the point at which retries are halted and everything starts over again.

I never said the timeouts in the protocol were related to the 3 hours. I was never more specific because it never occurred to me that any protocol would have timeouts to that degree. What I didn't see in the spec (I'm not going to read 90 pages for this discussion) was what happens over the life of a link. It doesn't seem to say how often the entire topology and key set is probed; it appears that after first authentication (i.e. "cold") that it never looks beyond the point-to-point verification. I suspect that a repeater is required to convey downstream point-to-point changes to upstream. Barring any change in topology (i.e. adding or removing devices) it may be that higher level processing is not done. It *could* be that DTV choses to force a higher level re-authentication every 3 hours on the hour.

At any rate, my suspicion is that the DVR is bungling a HDCP (or just plain HDMI) operation in these circumstances. It could be prioritization of activities detracting from completing the link maintenance in time as I believe you suggested earlier. In other words, link failure is a side affect of something unrelated. The fact that the interval doesn't directly match anything in the protocol spec does not mean that other activities in the DVR can't break the protocol.

(The HDMI spec is not publicly available like HDCP - it requires registration to see it.)


----------



## unixguru (Jul 9, 2007)

peds48 said:


> This part from that document is very interesting...
> 
> 
> > Repeaters. Adding an HDCP repeater to an installation greatly increases occurrence of problems. Repeaters are especially prone to problems because they have responsibilities of both a transmitter and a receiver. Add mul- tiple inputs and outputs to the repeater, and the problem increase accordingly.
> ...


That document is a shorter version of http://www.crestron.com/downloads/pdf/product_misc/DMPS_HDCP_White_Paper.pdf

They are promoting their patent pending enhancements; pointing out deficiencies in the core standard. If you read the longer document you will see its all about computers at the source which default to HDCP on. I connected a Mac at my source and indeed the lights on the extender show that HDCP is on all the time.

The problems with repeaters they refer to are not this problem. Its not saying that repeaters are inherently unreliable.


----------



## unixguru (Jul 9, 2007)

peds48 said:


> Yeah, I ised to deal with Crestron products a lot on my days I used to deal with those kind of folks. What I dislike about their products besides their prices of course, is the lack of consumer support. A reprogram of a remote requires an installer visit which of course can get very expensive.


Like DirecTV.


----------



## jimmie57 (Jun 26, 2010)

unixguru said:


> Like DirecTV.


It is very clear that you are worrying / stressing over this way too much. For your health I would suggest you put some serious thought to just letting this problem go and find another provider. This kind of worry / stress will drive up your blood pressure for sure ( I know this from personal experience and experience from my friends ).

Way back when I was young, I am 71 now, an old man like I am now told me something that I took to heart and never forgot.
He said, "It is obvious that this work comes natural to you and you are very good at it, but, you do have a problem. You need to learn to Listen. No matter how smart you are and what you think you know you can always learn by listening".

Edit / Add: I am a retired Machinist, Estimator and CAD drawing person, NOT anything to do with electrical stuff. A lot of or most of the technical stuff discussed on here is way over my head for sure.

Over my years I have had many people give me advice that did not know what I was even doing and it helped. It is the fact that they have a different set of eyes and perspective of what you are trying to do.

Good luck.


----------



## peds48 (Jan 11, 2008)

unixguru said:


> Like DirecTV.


Dish Network, Comacast, and others are always accepting new customer applications. doesn't hurt to try....


----------



## inkahauts (Nov 13, 2006)

While i disagree with a lot of what the op surmises, especially about refusing to test different scenarios because he thinks it won't change anything, (I've seen far more odd things happen) this is a bit uncalled for IMHO. If for no other reason than he is using an HR34. He should be calling and talking to customer retention and asking for a manager till he gets a hr44.


----------



## unixguru (Jul 9, 2007)

jimmie57 said:


> Way back when I was young, I am 71 now, an old man like I am now told me something that I took to heart and never forgot.
> He said, "It is obvious that this work comes natural to you and you are very good at it, but, you do have a problem. You need to learn to Listen. No matter how smart you are and what you think you know you can always learn by listening".


Realize that what he said is half-baked advice. I've been on this rock for 55 years and my entire career spent navigating the mine-fields of personal interaction. Listening is good advice but it is also a 2-way street. I've heard that kind of advice a couple of times, given to me and others, that has always been a last resort in an argument where the person issuing the advice is basically saying they are right and I/we are wrong and that the only possible outcome is for me/us to shut up and accept their wisdom. Listening is half-baked because it is not the most important aspect - *discernment* is.

I also witnessed time and again that persistence in solving problems is the only way things progress. If people weren't persistent we would still be living in caves.


----------



## unixguru (Jul 9, 2007)

inkahauts said:


> While i disagree with a lot of what the op surmises, especially about refusing to test different scenarios because he thinks it won't change anything, (I've seen far more odd things happen) this is a bit uncalled for IMHO. If for no other reason than he is using an HR34. He should be calling and talking to customer retention and asking for a manager till he gets a hr44.


Whatever. I am 'letting it go' for now. I will try a few more things which I will not share the results of here. If I still have a problem come August I will get a replacement HR44. If none of those things solve the problem then I will be reminded every time it happens that I need to find a solution that eliminates my dependence on DirecTV. And most of all I will avoid discussing problems on this forum.


----------



## harsh (Jun 15, 2003)

slice1900 said:


> Crestron makes very high end gear - very expen$$$ive, makes Gefen gear look like Monoprice and Pioneer like no-name "ships from mainland China" on eBay by comparison!


By the same token, reputation and/or high price can't replace diligent testing.


----------



## unixguru (Jul 9, 2007)

Just an update.

I have changed *zero* in my setup since having this problem. Same TV, receiver, HDMI extender, cables, etc, etc, etc.

I can't say exactly when things changed but it's been over a month since I've seen this problem.

So to all those experts that wanted me to discard equipment and do all kinds of silly debugging... none of that had anything to do with it.

I'm sure some fanboys will conclude that something environmental changed - i.e. outside of the DTV equipment. Like the temperature outside, the neighbor stopping his RF assault on my house, martians deciding to leave me alone - whatever. Because it couldn't possibly have been a problem with DTV software that has been corrected...


----------



## jimmie57 (Jun 26, 2010)

unixguru said:


> Whatever. I am 'letting it go' for now. * I will try a few more things which I will not share the results of here.* If I still have a problem come August I will get a replacement HR44. If none of those things solve the problem then I will be reminded every time it happens that I need to find a solution that eliminates my dependence on DirecTV. And most of all I will avoid discussing problems on this forum.





unixguru said:


> Just an update.
> 
> I have changed *zero* in my setup since having this problem. Same TV, receiver, HDMI extender, cables, etc, etc, etc.
> 
> ...


OK


----------



## unixguru (Jul 9, 2007)

jimmie57 said:


> OK


I may have said I was going to try more things but I didn't. I changed zero from when it was acting badly to not having this problem.

So now my word is being doubted too? I haven't visited this site much for awhile now. I don't know why I bother.


----------



## samrs (May 30, 2004)

I believe.


----------



## b52pooh (Mar 10, 2011)

I'm curious. What firmware version do you have now? And when did it download? Thanks.


----------



## unixguru (Jul 9, 2007)

b52pooh said:


> I'm curious. What firmware version do you have now? And when did it download? Thanks.


0x9f6 5/7

I could draw a conclusion...


----------



## unixguru (Jul 9, 2007)

unixguru said:


> 0x9f6 5/7
> 
> I could draw a conclusion...


Problem was gone... until 0x0a02.

Coincident that the problem goes away with software update and then comes back again with another software update? I think not.


----------



## Rich (Feb 22, 2007)

samrs said:


> I believe.


I believe the TS, too. And I'm not surprised by the issue suddenly clearing up. He's got a lot more patience than I have, I'd have swapped that 34 out immediately. The TS has always impressed me, both with his knowledge (which, admittedly, I have a hard time following because I just don't have the background he does) and his ability to write a post that makes sense. I just noticed this thread today and read the whole thing and from his OP, I was focused on the 34 as the culprit.

Rich


----------



## Rich (Feb 22, 2007)

unixguru said:


> 0x9f6 5/7
> 
> I could draw a conclusion...


And that conclusion would probably be correct. I think.

Rich


----------



## Rich (Feb 22, 2007)

unixguru said:


> Problem was gone... until 0x0a02.
> 
> Coincident that the problem goes away with software update and then comes back again with another software update? I think not.


Dump the 34 and get a 44. I'd be amazed if that didn't fix the problem.

Rich


----------



## unixguru (Jul 9, 2007)

Rich said:


> Dump the 34 and get a 44. I'd be amazed if that didn't fix the problem.


I am approaching that time of year were I can change equipment without losing a lot of programming.

I'm not spending $ to fix their problem. I'm not entering into another 2 year commitment. Even an unfortunate failure :blackeye: would not guarantee a 44. So easier said than done.


----------



## jimmie57 (Jun 26, 2010)

unixguru said:


> I am approaching that time of year were I can change equipment without losing a lot of programming.
> 
> I'm not spending $ to fix their problem. I'm not entering into another 2 year commitment. Even an unfortunate failure :blackeye: would not guarantee a 44. So easier said than done.


They are both Genies so it is not an upgrade in their system. No extension of contract. Chew on their ears that yours is broken with this problem and you want it fixed.
When the tech calls to come out, ask him if he has an HR44 on the truck. If not tell him to call back when he gets one and cancel this appointment. This has worked with many others that have posted on here.


----------



## unixguru (Jul 9, 2007)

unixguru said:


> Problem was gone... until 0x0a02.
> 
> Coincident that the problem goes away with software update and then comes back again with another software update? I think not.


Finally got around to sticking a splitter between the DVR and the extender (via two 1' HDMI cables). As expected, no change.

Snowy screen bursts (with audio dropout) for a fraction of a second and reappears every couple of seconds. Returning to live programming is only thing that clears it up.

Yeh, I know, get a HR44. Another Hail Mary.


----------



## jimmie57 (Jun 26, 2010)

unixguru said:


> Finally got around to sticking a splitter between the DVR and the extender (via two 1' HDMI cables). As expected, no change.
> 
> Snowy screen bursts (with audio dropout) for a fraction of a second and reappears every couple of seconds. Returning to live programming is only thing that clears it up.
> 
> Yeh, I know, get a HR44. Another Hail Mary.


Have you tried hooking to a second / alternate TV to see if it is possible the trigger is coming from that TV ?


----------



## Shades228 (Mar 18, 2008)

unixguru said:


> Finally got around to sticking a splitter between the DVR and the extender (via two 1' HDMI cables). As expected, no change.
> 
> Snowy screen bursts (with audio dropout) for a fraction of a second and reappears every couple of seconds. Returning to live programming is only thing that clears it up.
> 
> Yeh, I know, get a HR44. Another Hail Mary.


I haven't read this whole thread but does the hdcp light turn off on the extender on that interval? If they do go out how long does it take to go back on? If there's a noticeable delay then you could write the company about that as well and see what their engineers have to say about it.

At this point I would write an email to the office of the president (normally I hate referring people there) and explain the behavior and then state which update resolved it and the latest update that broke it. They can forward it on to people who can actually review it. Most people here are screaming for a 44 because they think a 34 is garbage. However given the universal coding I would be skeptical at best to see a change in the behavior. It's possible a different HDMI controller could resolve the issue but it's a guess not an absolute.


----------



## unixguru (Jul 9, 2007)

unixguru said:


> Problem was gone... until 0x0a02.
> 
> Coincident that the problem goes away with software update and then comes back again with another software update? I think not.


Problem gone again as of 0xa05 on Tuesday. :roundandr


----------



## jimmie57 (Jun 26, 2010)

unixguru said:


> Problem gone again as of 0xa05 on Tuesday. :roundandr


Well, I hope they keep that flaw fixed for you.


----------



## Directvtechjosh (Jul 31, 2015)

unixguru said:


> Very frustrating that there is no way to report a technical problem to DirecTV electronically. Useless talking to a customer service rep about this kind of thing. So here I blow it into the wind on the slim chance...
> 
> My setup: HR34 -> Gefen 4K Ultra HD HDMI Extender -> Pioneer Elite SC-72 -> Sony XBR-65HX929
> 
> ...


Hdmi over cat5 powered extender same issue with my 34 it my 75 foot hdmi cable just couldnt cut it


----------



## unixguru (Jul 9, 2007)

unixguru said:


> Problem gone again as of 0xa05 on Tuesday. :roundandr


I spoke too soon.

The _witching hour_ (or _minute_ in this case) seems to have moved to 3 minutes past the hour.


----------



## unixguru (Jul 9, 2007)

Directvtechjosh said:


> Hdmi over cat5 powered extender same issue with my 34 it my 75 foot hdmi cable just couldnt cut it


Sorry to hear that. But nice that I'm not the only one 

Sadly, you aren't going to find any answer here or get any help from DTV. Just the last resort of trying to get them to replace it with a HR44.


----------

