Possible trouble on 72.7W, Transponder 15

[buckchow]

Just wanted to check if others on the forum here are encountering problems with channels on Transponder 15 (12.428 GHz) on 72.7W.

I'm seeing damage to the entire mux about once every 10-60 minutes causing brief (1-2 seconds) but sometimes quite ugly artifacts in the video on all available channels. The audio interruptions aren't as noticeable.

The channels on this transponder from "The List" are:

103 MOVIE
124 BET
126 BABY
127 OXYGN
128 WE
131 IFC
132 TCM
172 DISE
191 G4
195 MIL
198 SLTH
199 CHILR
212 EARTH
222 HSN (84)
260 TBN
263 DYSTR
267 CTN
400 TENIS
439 BIG10
493 FRESH
502 MOVIE
503 MOVIE
504 MOVIE
516 MOVIE
518 MOVIE
519 MOVIE
520 MOVIE
521 MOVIE

This problem was first observed on March 30th when it was once every few hours and has become worse since that time. An examination of the stream damage suggests that the data is probably going bad before the FEC encoding is done, but I suppose only the folks at Dish could verify this. Unless I'm missing something bizarre, the problem isn't on my end since the errors down to the bit level are seen identically on two separate receivers attached to two separate dishes both receiving signals from 72.7W.

 

[photoman76]

TSReader is showing continuity errors about every 12 seconds.

 

[buckchow]

TSReader is showing continuity errors about every 12 seconds.

It's "normal" for there to be continuity errors on that transponder with great regularity, so that's not the problem here. The problem is when the entire mux goes bad at once, not just the 0x1A0n PIDs since those always have lots of errors.

The display in TSReader is generally useful enough on a well-behaved computer for seeing if the damage has occurred at all so if you leave it running for a while you should see every PID go bad (and in some cases see some TEI errors) if the problem really is coming from Dish's end.

To get more detailed info on my end, I'm using another tool on stream captures that shows exactly when and where the damage occurs, the duration of stream interruptions (if > 100ms), what the extent of the damage is (error counts/durations by type - CC, TEI, Sync, PCR, PES, and known/expected data comparison), and a bit of other information. Seems a bit overkill at times, but it can be useful when odd stuff like this is going on.