AT&T U-verse → Picture freeze - what causes it?

I just had a freeze, about 1 hour ago.

Note that this is the first such in 4 months of service, so I am not complaining. I'm just wondering about causes.

The picture froze. Attempts to change channel were ignored. Then, after about 2 minutes, it started working again.

If I had to guess, I would say that either the STB rebooted, or an upstream router rebooted.

Connection from RG to STB is cat 5e, so that should not have been a problem. The statistics on the RG look okay. They currently show 21 uncorrected blocks for the last 24 hours, and the most recent is at around the time of the freeze. I had looked earlier today and saw 17 uncorrected blocks. So there could have been no more than 4 during the freeze incident, which I would think is too small to have any effect other than minor pixelation.

Could be some uncorrected blocks although if its frozen for several seconds it could be some of those nasty "severely-errored" blocks.

The most recent "severely errored seconds" shows as almost 3 days ago, which was when the profile switch to 32/5 took place.

I was not watching. My wife was watching the TV. She called me to look. By the time I got downstairs it was still frozen. That had to be around 2 minutes of freeze, so longer than "several seconds". That's why I am thinking that either the STB or something upstream may have rebooted.

It could be any number of problems, first was it a local network affiliate channel like ABC, CBS, FOX or NBC or a national "Cable Feed"?

Do you have a DVR in addition to this STB and if yes, what was it up to during this time period?

Dave

It was on a local channel.

No, I don't have a DVR.

Hmm, I don't have a plan STB but on my Cisco DVR, I have the option to see the System Information which indicates the session connect time for the DVR.

Try Menu button > Options > System Options > System Information. Top line shows the current date / time and (session:HH:MM:SS)

Since your STB would not change channels, I would vote for a local STB issue just like you but your System Information might show more details. Also, did your link light blick or did it stay green on the front of the STB?

Dave

Lately here late at night in Columbus, OH i've seen the LOCALS freeze up .. I can up and down on the channels and all the LOCALS will be frozen but QVC and HSN and others near them are ok and further up the cable networks are fine... they usually unfreeze themselves after a few minutes.. no errors or block errors on the RG when this occours.

Okay. It shows session time of almost 2900 hours, so I guess it was not an STB reboot. Probably something upstream happened that temporarily interrupted transmission of the particular stream.Since that comes from a side comment by my wife, I don't have complete confidence that it is correct information.

I'll leave it as unexplained for the moment. As indicated in the OP, with this the first glitch in 4 months of service, it isn't anything I will be losing sleep over.

The ability for the STB to change or not change channels is key to understanding where the problem might lie.

When you make a channel change request on the STB a series of actions take place in the background relating to multicast streams and IGMP Leave / Join requests to the upstream devices from your STB. For example the RG and the VRAD both act as IGMP Proxys and if you look in the RG logs you can see examples of IGMP Leave / Join request to multicast streams.

Here is a key page with a filter that should show you some of the IGMP traffic:

»192.168.1.254/xslt?PAGE= ··· ILY=igmp

INF 2010-02-18T21:02:00-05:00 igmp: bridge1: IGMP proxy leaving group 239.193.102.28
INF 2010-02-18T23:02:00-05:00 igmp: bridge0: querier group 239.192.1.134 host 192.168.2.100 left, EXCLUDE mode, ver 3, 0 sources
INF 2010-02-18T23:02:00-05:00 igmp: bridge1: IGMP proxy leaving group 239.192.1.134
INF 2010-02-18T23:57:39-05:00 igmp: bridge0: querier group 239.255.255.250 host 192.168.2.114 joined, EXCLUDE mode, ver 3, 0 sources

In my sample log above, my DVR is at 192.168.2.100

Dave

Okay, thanks.

The first logged entry is from just after the picture freeze, probably at the time of the first successful channel change that I saw when checking on the problem.

I'm not sure whether I'm seeing a limitation of the log, or that there was no previous channel switch attempt. The event log shows other events ("fw" events) from at least two days earlier, but no igmp events. However, the TV was used during that period, so the igmp log entries must have rolled off the log.

I could be anything from something locally all the way up to the video ring.

I could fill a page with possible causes of freezing.

Basically picture freezes are usually caused by interruptions in the stream coming to the STB. This interruption could be at any point in the network.

This happened to me once long ago. Haven't seen it again since though.

I had to give up uverse because of the picture freezing and the STBs not responding. In my case the Gateway was losing the Broadband connection due to interference on the line. When it lost connection it would flash red on the Gateway. Sometimes it would reconnect on its own, other times I had to unplug the gateway for 10 seconds and then plug the power cord back in.

Fortunately, I am not having that kind of problem. The RG has been reliable. It has only restarted twice since I have had the service - once deliberately by me, and once with a firmware upgrade. For the recent profile switch to 32/5 it retrained but did not reboot.

Thanks, everybody, for the comments. I agree that the freeze was likely due to an interruption of the incoming stream. While I can't be certain, it is looking as if it was not a problem locally, but instead occurred somewhere upstream.

When I was on cable at some time in the past, I had more frequent interruptions than I have seen with u-verse. So I am not seeing this as a problem. I appreciate the input.

I was looking through some of the other logged info on the RG, and I came across this:

 
INF    2010-02-18T22:06:09-06:00   lmd:  ipnet0: DOWN on bridge1 with 99.175.xxx.xxx
WRN 2010-02-18T22:06:09-06:00 eth:  met0: filter session space exceeded
ERR 2010-02-18T22:06:09-06:00 mif:  mif_get_params: InternetGatewayDevice.ManagementServer.ConnectionRequestURL: No such file or directory
ERR 2010-02-18T22:06:09-06:00 cwmd:  cwmd_mgmt_map_sync: failed to get params, No such file or directory
ERR 2010-02-18T22:06:09-06:00 mif:  mif_get_params: InternetGatewayDevice.ManagementServer.ConnectionRequestURL: No such file or directory
WRN 2010-02-18T22:06:09-06:00 cwmd:  cwmd_mgmt_sync_paramattr: get params
ERR 2010-02-18T22:06:09-06:00 cwmd:  connreq: in sync, get port: No such file or directory
ERR 2010-02-18T22:06:09-06:00 cwmd:  Previous log entry repeated 1 times
INF 2010-02-18T22:06:09-06:00 httpd:  vhost mdc0:0 down on 99.175.xxx.xxx port: 50001
ERR 2010-02-18T22:06:09-06:00 mif:  mif_get_params: InternetGatewayDevice.ManagementServer.ConnectionRequestURL: No such file or directory
WRN 2010-02-18T22:06:09-06:00 cwmd:  cwmd_mgmt_sync_paramattr: get params
ERR 2010-02-18T22:06:09-06:00 cwmd:  connreq: in sync, get port: No such file or directory
ERR 2010-02-18T22:06:09-06:00 cwmd:  Previous log entry repeated 1 times
WRN 2010-02-18T22:06:10-06:00 vrsip:  Broadband connection lost
WRN 2010-02-18T22:06:10-06:00 cwmd:  httpc_req_start No such file or directory
INF 2010-02-18T22:06:10-06:00 cwmd:  session will be restarted
WRN 2010-02-18T22:06:10-06:00 cwmd:  httpc_req_start No such file or directory
WRN 2010-02-18T22:06:11-06:00 cwmd:  Previous log entry repeated 1 times
INF 2010-02-18T22:06:11-06:00 lmd:  ipnet0: UP on bridge1 with 99.175.xxx.xxx/22 GW:99.175.212.1
INF 2010-02-18T22:06:11-06:00 lmd:  ipnet0: UP on bridge1 DNS1: 68.94.156.1 DNS2: 68.94.157.1
INF 2010-02-18T22:06:11-06:00 cwmd:  session will be restarted
INF 2010-02-18T22:06:12-06:00 voiced:  Set 0 IP from 0 to 99.175.xxx.xxx
INF 2010-02-18T22:06:12-06:00 voiced:  reset port 0
INF 2010-02-18T22:06:12-06:00 voiced:  Set 1 IP from 0 to 99.175.xxx.xxx
INF 2010-02-18T22:06:12-06:00 voiced:  reset port 1
 

Those are at about the time of the picture freeze, so very likely related.

I'm not quite sure what it means. As best I can tell, this was an ethernet failure, not a vdsl failure, since there was no VDSL retrain at that time. Presumably it is a failure with the bridging of ethernet over the vdsl connection.

If you have an ethernet connection to the stb, call in random times to see if the customer service rep can run a test on your services performance to see if they see any "ethernet errors". Also ask to see if there are any outside line issues such as, Bridgetap, Crosstalk, Interference, Impedance Mismatch... these issues will cause random uncommon studders or frozen screen with your tv services.

If you have coax going to some other tvs, those connectors can also affect your ethernet connected stb. (all stbs communicate with each other, so essentially when a stb receiving errors every now and then sends information to the stb connected via ethernet, you will have problems).

Joshua Jarvis
Technician