So, I heard of a situation where all 4 Cox stations in Dayton OH's computer crashed during the time change. Has that ever happened to anybody else, and why does that happen?
-
Get involved.
We want your input!
Apply for Membership and join the conversations about everything related to broadcasting.
After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
If you use a disposable or false email address, your registration will be rejected.
After your membership is approved, please take a minute to tell us a little bit about yourself.
https://www.radiodiscussions.com/forums/introduce-yourself.1088/
Thanks in advance and have fun!
RadioDiscussions Administrators
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
It's that "TIME" again.
- Thread starter radiogeek07
- Start date
K
KMRichards
Guest
> So, I heard of a situation where all 4 Cox stations in
> Dayton OH's computer crashed during the time change. Has
> that ever happened to anybody else, and why does that
> happen?
I've never had it happen, but I can tell you why it is most likely to.
In the Spring, when we "lose" the 2:00am hour, the computer suddenly sees that it is "overprogrammed" by 60 minutes as it moves through the log. In the Fall, it sees either that it is "underprogrammed" or that the 1:00am hour is scheduled twice. Depending on what software you are using, there is either a built-in fix, or it does the best it can to correct it on the fly, or it crashes the system because of those "impossible" circumstances.
The best way I have seen to avoid this is to let the computer keep running on pre-flip time until the Sunday morning non-format programming (public affairs, infomercials, etc.) and reset the clock while the automation is off-line. This requires a bit of advance planning by the programmers to program the "wrong" hours correctly, but at least it prevents a crash.<P ID="signature">______________
</P>
> Dayton OH's computer crashed during the time change. Has
> that ever happened to anybody else, and why does that
> happen?
I've never had it happen, but I can tell you why it is most likely to.
In the Spring, when we "lose" the 2:00am hour, the computer suddenly sees that it is "overprogrammed" by 60 minutes as it moves through the log. In the Fall, it sees either that it is "underprogrammed" or that the 1:00am hour is scheduled twice. Depending on what software you are using, there is either a built-in fix, or it does the best it can to correct it on the fly, or it crashes the system because of those "impossible" circumstances.
The best way I have seen to avoid this is to let the computer keep running on pre-flip time until the Sunday morning non-format programming (public affairs, infomercials, etc.) and reset the clock while the automation is off-line. This requires a bit of advance planning by the programmers to program the "wrong" hours correctly, but at least it prevents a crash.<P ID="signature">______________
</P>
That's assuming, however, that the Sunday programs aren't also in the automation or that you can bring board ops in to cover those hours on however many stations are in the cluster to run them manually.
It'll be interesting to see what happens with Cox radio Dayton tonight, ast they've lost their long-time Chief Engineer and have had several changes since then.
Also, much of Indiana will join the rest of civilization and go on Daylight Savings Time for the first time in nearly 40 years. Interesting to see how much dead air there is in those markets overnight!<P ID="signature">______________
"Your right to know supersedes your right to exist"..Gary Burbank</P>
It'll be interesting to see what happens with Cox radio Dayton tonight, ast they've lost their long-time Chief Engineer and have had several changes since then.
Also, much of Indiana will join the rest of civilization and go on Daylight Savings Time for the first time in nearly 40 years. Interesting to see how much dead air there is in those markets overnight!<P ID="signature">______________
"Your right to know supersedes your right to exist"..Gary Burbank</P>
Where I am at, we use Audio Vault.
Moving through the time changes are actually really simple. You delete the 2AM hour from Selector, but leave the hour header there for AV Scheduler to see, but it has no contents. Take out all the updates from 12AM - 4AM. Go to station at 12AM, change clocks to 1AM and move seamlessly through the day. Your playlist may run a little long for a few hours but catches back up later in the morning. That's where a lot of stations have problems, they forget to take out the updates and the automation gets really confused when you change the time.
For fall back, selector sneaks an extra hour of music into the 2AM hour, because Audio Vault won't accept anything but a 24 hour day, so there is 2 hours of music in 1. Take out updates again between 12AM - 4AM, go in at 1 and change the clocks back to 12.
Granted, this is the best way I can do it with Audio Vault, other automation systems have their own ways. And of course, your mileage may vary.
> > So, I heard of a situation where all 4 Cox stations in
> > Dayton OH's computer crashed during the time change. Has
> > that ever happened to anybody else, and why does that
> > happen?
>
> I've never had it happen, but I can tell you why it is most
> likely to.
>
> In the Spring, when we "lose" the 2:00am hour, the computer
> suddenly sees that it is "overprogrammed" by 60 minutes as
> it moves through the log. In the Fall, it sees either that
> it is "underprogrammed" or that the 1:00am hour is scheduled
> twice. Depending on what software you are using, there is
> either a built-in fix, or it does the best it can to correct
> it on the fly, or it crashes the system because of those
> "impossible" circumstances.
>
> The best way I have seen to avoid this is to let the
> computer keep running on pre-flip time until the Sunday
> morning non-format programming (public affairs,
> infomercials, etc.) and reset the clock while the automation
> is off-line. This requires a bit of advance planning by the
> programmers to program the "wrong" hours correctly, but at
> least it prevents a crash.
>
<P ID="signature">______________
The power is yours!</P>
Moving through the time changes are actually really simple. You delete the 2AM hour from Selector, but leave the hour header there for AV Scheduler to see, but it has no contents. Take out all the updates from 12AM - 4AM. Go to station at 12AM, change clocks to 1AM and move seamlessly through the day. Your playlist may run a little long for a few hours but catches back up later in the morning. That's where a lot of stations have problems, they forget to take out the updates and the automation gets really confused when you change the time.
For fall back, selector sneaks an extra hour of music into the 2AM hour, because Audio Vault won't accept anything but a 24 hour day, so there is 2 hours of music in 1. Take out updates again between 12AM - 4AM, go in at 1 and change the clocks back to 12.
Granted, this is the best way I can do it with Audio Vault, other automation systems have their own ways. And of course, your mileage may vary.
> > So, I heard of a situation where all 4 Cox stations in
> > Dayton OH's computer crashed during the time change. Has
> > that ever happened to anybody else, and why does that
> > happen?
>
> I've never had it happen, but I can tell you why it is most
> likely to.
>
> In the Spring, when we "lose" the 2:00am hour, the computer
> suddenly sees that it is "overprogrammed" by 60 minutes as
> it moves through the log. In the Fall, it sees either that
> it is "underprogrammed" or that the 1:00am hour is scheduled
> twice. Depending on what software you are using, there is
> either a built-in fix, or it does the best it can to correct
> it on the fly, or it crashes the system because of those
> "impossible" circumstances.
>
> The best way I have seen to avoid this is to let the
> computer keep running on pre-flip time until the Sunday
> morning non-format programming (public affairs,
> infomercials, etc.) and reset the clock while the automation
> is off-line. This requires a bit of advance planning by the
> programmers to program the "wrong" hours correctly, but at
> least it prevents a crash.
>
<P ID="signature">______________
The power is yours!</P>
M
Mediafrog
Guest
This Sunday morning is also a good time for AM DX'ers, as there are always a number of stations that "forget" to do the power/pattern change an hour later, local time.
I used to pick up a lot of interesting DX that way..though with computerized switching it isn't as common. A few years ago I caught WGR, Buffalo doing a number on semi-local WKRC, Cincinnati the Monday after the DST switch at 5:30am.
I used to always hear the now defunct WPRT, Prestonsburg, KY the whole week after "fall back" when they didn't alter their sign off time like they should have.<P ID="signature">______________
"Your right to know supersedes your right to exist"..Gary Burbank</P>
I used to always hear the now defunct WPRT, Prestonsburg, KY the whole week after "fall back" when they didn't alter their sign off time like they should have.<P ID="signature">______________
"Your right to know supersedes your right to exist"..Gary Burbank</P>
- Status
- This thread has been closed due to inactivity. You can create a new thread to discuss this topic.