simple solution : don't use real times for music elements.

make all music selections 1 minute long and [for example] schedule a group
of 4 then an event that sync's the log to wall time

the sync bumps the last track if necessary

I have 6 or 8 tracks at the end of an hour each scheduled on the CLOCK as
1minute duration but we know the average song length here is about 3:30

with a bit of observation it is possible to build clocks that always over
fill the hour, and bump selections you can live with.

my sync's preceed an ad break so we always get the ad breaks.

regards

Robert Jeffares
Big Valley Radio
Thames
New Zealand

On Sat, Sep 24, 2011 at 6:37 AM, <[email protected]> wrote:

>
> We just discovered that we are having some scheduling and Top of the
> Hour issues as well.
>
> We aren't using any external programs just Rivendell.  We are very
> possibly doing something wrong because we don't understand exactly how
> things work.
>
> We generated 24 clocks several months ago and one problem I discovered
> yesterday is that when it generates a log many times an hour comes up
> several minutes short, like yesterday there was an hour that only had
> 53 minutes of music scheduled.
>
> I examined it more closely and one problem I see now is that the guy
> that created clocks has (I think) too many long slots (like six
> minutes) for our "Gold" category.  I looked through the Gold songs and
> there are only 7 songs that are longer than 6 minutes and one 8 minute
> song.
>
> So in yesterdays log it filled some of the six minute slots with 3 and
> 4 minute songs, making those hours short.  I'm having him go through
> the clocks and adjust so there is only 1 six minute slot per day and
> only a few 5 minute slots.  But we don't know if that 8 minute song
> will ever get scheduled now?
>
> I thought we could just overschedule every clock by one song and then
> it will get dropped if the hour runs long (that seems to work fine in
> our tests).  But he says he won't let him create clocks that are
> longer than 59:99.
>
> Are we completely off base here?
>
> Thanks,
>   Scott
>
> _______________________________________________
> Rivendell-dev mailing list
> [email protected]
> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
>
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev

Reply via email to