Re: Scheduling Broadcasts

On Tue, 24 Jan 2006 09:02:02 -0800, "Mark"
<Mark@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

OK I made & tested an example file so you can see how the techique
works. It's a simple 3 element playlist, with one long presnetation, a
live segment and a lead-out at the end. Here goes :

<?wsx version="1.0"?>
<priorityClass id="livesegment" peers="pause">
<media id="content"
dur="90s" />
<media id="livesource"
src=""; begin="wallclock(21:35)" dur="60s" />
<media id="advert"
begin="content.end" />

What we've got here is this :

The Brett Bentsen clip has a total duration of 45 minutes, I selected
the first 90 seconds with dur="90s". Had I specified a clipBegin time
of 180s, it would have started 3 minutes into the clip - skipping into
the clip and playing a 90 second segment of the clip from 3 minutes to
4.5 minutes.

That's pretty obvious. Now, by enclosing the elements in a
<priorityClass /> container, we can specify behaviours of how clips
interrupt each other.

In this case, I've used peers="pause", so everything in that
priorityClass section that's interrupted, will resume once the
interruptee (is that a word?) has finished playing.

We've told the Brett clip to be interrupted by the live stream,
pointed at my running encoder. That will happen when the live stream
is scheduled to start.

The encoder stream began at 9.35PM on the dot

At this point, the player stopped receiving the Brett stream and
started buffering the encoder broadcast. After 60 seconds (could be 1
hour e.g) of live broadcast, the encoder stream stopped as specified.

The Brett stream then resumed from the point it was interrupted, and
played for the remaining duration of the clip (i.e up to the final
time of 90 seconds)

Finally, the last clip call it an out-tro, was told to begin at
content.end : You'll notice the Brett stream has an ID of "content".

That's the determining way to link clips together. By using unique IDs
for each element of your playlist, you can have them loop around and
reference them back to each other.

Hopefully that example makes it a lot clearer, I'd have to say it took
about 20 minutes to knock together in a text editor.

In case you're more comfortable with a GUI, you can set up many of
these elements by using the wizard initially to create a blank WSX
(playlist) then going to the Source tab of the server. You'll be able
to edit each node (element) of the playlist, and see only the
available attributes for each node.

Plus - when you run the playlist, the server will display the
currently playing item in bold, the time it's played for (and
remaining) at the top of the source tab above the WSX element list.

Hopefully seeing those items switch over will give you the insight to
make much more complex playlists by close of play tomorrow ;-)

Cheers - Neil

>I'm having problems with the begin time.
><media src=""; begin="wallclock( 10:56 )" dur="60s" />
>This should mean that the stream will not start until 10:56AM and will run
>for 60 seconds. The duration of 60 seconds works fine, but the starting
>doesn't. Since the encoder is already running, clients/users are allowed to
>connect at anytime. I'm not sure what I'm missing.
>"Neil Smith [MVP Digital Media]" wrote:
>> On Fri, 20 Jan 2006 09:23:04 -0800, "Mark"
>> <Mark@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> >I'm streaming a radio show once a day during a 4 hour block. Is there a way
>> >to schedule Windows Media Services to start and stop a publishing point? Or
>> >is there a way to save the publishing point as a file and launch it with
>> >Scheduled Tasks?
>> It's somewhat simpler than that. You can set up a wsx (SMIL) playlist
>> to do it for you, and the format is very simple - it's just a text
>> file. No need to invoke 3rd party applications.
>> Obviously you need your server clock and time zone set correctly, but
>> the End setting for the playlist can be set to a 'wallclock' value on
>> windows server 2003 with SP1 :
>> HTH
>> Cheers - Neil