This used to be a frequent problem on D*, but it's been over a year since I've seen it.
However..... It's back.
The problem is: the clock data on some transponders, usually spot beams carrying locals, will become inaccurate, apparently requiring an engineer to manually set it.
This is currently the case with transponder 23 on 119 (the one that carries the New Orleans locals). This clock is currently almost 3 minutes slow!! (More precisely, about 2 minutes 40 seconds slow.)
This can be verified by displaying the clock on the screen, and tuning between a New Orleans local and a 101 CONUS channel. When tuned to the CONUS channel, the clock on the screen matches a good NIST time reference perfectly (e. g. an "atomic" clock or a computer running NTP). When tuned to a New Orleans local, the clock displayed on the screen is 2:40 slow.
This is a problem for DVR owners because when the DVR is obtaining its clock from the transponder with the inaccurate clock, recordings start 2:40 late.
It shouldn't be necessary to pad every recording to start 3:00 early, as this tends to create lots of conflicts!
I post this here because there is no way via phone or email to get this information to the D* engineers who can actual fix it. All you can get is the CSR reading a script explaining how networks don't always start their programs exactly on schedule. What I'm talking about is not networks not starting programs on schedule! The clock on transponder 23 at 119 is inaccurate, as can be proven by the experiment outlined above!
I am thankful for this an other DBS related forums, which is the means by which I and others have brought this to the attention of actual D* engineers in the past. I'm confident it will be effective this time too.
However..... It's back.
The problem is: the clock data on some transponders, usually spot beams carrying locals, will become inaccurate, apparently requiring an engineer to manually set it.
This is currently the case with transponder 23 on 119 (the one that carries the New Orleans locals). This clock is currently almost 3 minutes slow!! (More precisely, about 2 minutes 40 seconds slow.)
This can be verified by displaying the clock on the screen, and tuning between a New Orleans local and a 101 CONUS channel. When tuned to the CONUS channel, the clock on the screen matches a good NIST time reference perfectly (e. g. an "atomic" clock or a computer running NTP). When tuned to a New Orleans local, the clock displayed on the screen is 2:40 slow.
This is a problem for DVR owners because when the DVR is obtaining its clock from the transponder with the inaccurate clock, recordings start 2:40 late.
It shouldn't be necessary to pad every recording to start 3:00 early, as this tends to create lots of conflicts!
I post this here because there is no way via phone or email to get this information to the D* engineers who can actual fix it. All you can get is the CSR reading a script explaining how networks don't always start their programs exactly on schedule. What I'm talking about is not networks not starting programs on schedule! The clock on transponder 23 at 119 is inaccurate, as can be proven by the experiment outlined above!
I am thankful for this an other DBS related forums, which is the means by which I and others have brought this to the attention of actual D* engineers in the past. I'm confident it will be effective this time too.
