Get playlist to take note of 'Fixed Time'

English Feature Requests
1

Hey,
Would it be possible for the ‘fixed time’ flag to ACTUALLY be used as a totally fixed time?

For instance - its fine at the moment but would it be possible so that the file definitely starts at that time? Because at the moment, if you run out of items in the playlist before that item, it will play out regardless of the fixed time state.

Ant

2

This would also require a change in the algorithm. We would need some sort of “waiting” state in which the playback control sits and waits for reaching the fixed time. This is not possible with the current algorithm.

As a workaround, insert a Silence item before the fixed-time one.

3

So, to check my understanding: at present, the Playback control treats a ‘fixed time’ as a ‘fixed start time’ if and only if there is either a) at least one item preceding it in the Playlist, or b) there is at least one item currently playing which would otherwise finish after the fixed time.

Is that correct? If so, I’d suggest that ‘fixed time’ should be renamed ‘start time’ or something else more accurate, as a first step towards creating a genuine fixed playout time feature. Fixed should mean fixed and inviolate in all circumstances (and if that means broadcasting several seconds of dead air, then so be it!). ‘Start time’ does not imply the same sense of ‘this item will definitely play out at the fixed time, regardless of what else is or is not happening at that time.’

BFN
CAD

4

The algorithm goes like this:

The playback control object scans the playlist, identifying the top-most, non-history item on which a fixed time is set. If such an item exists, a reference to that item is saved to a variable. Once per second, mAirList checks whether the current time has reached the stored fixed time. If so, an AutomationJump command will be executed, skipping all items up the fixed time one. When the item is reached in an “ordinary” way, that is, because the playlist was too short, it will be played normally, and possibly to early. This is the issue Ant is referring to.

If I wanted to make mAirList stop and wait for reaching the desired time, I would have to introduce a “waiting” state for the automation. At the moment, we only have “playing” and “not playing” (and, of course, “disabled”). Introducing another state is a task I would want to avoid at this time …

How about the following solution? When the automation encounters a fixed-time item during ordinary playback, and sees that the time has not been reached yet, it simply inserts a Silence item before the fixed-time one which will get “played back” first. This has the same effect as the above mentioned waiting state, does not break my current algorithm, and it makes the process transparent to the user. No more “Help! I think mAirList crashed!”, but rather “Hm, there’s a silence item playing, I think our log was too short this time”. The user could also specify the name of an “emergeny” playlist used instead of the silence item.

The term “start time” is a little too generic. mAirList maintains a number of “start times” for each item. The fixed time is only one of them. They are all displayed on the Options tab in the properties dialog. See the TStartTimeType enumeration in the CHM file for a complete list. In the playlist GUI, only the most applicable time is displayed (“real” for the history items and those currently playing, “fixed” for the fixed-time items, “estimated” for any other item).

5

Where is/are the Exact Time Markers in the Playlist ? If they’re at the end (for a top-of-hour), the usual practice is to over-schedule and place the ETM at the end. This would require the playout software to read the whole playlist and know that the last item had to start at a given time (and thus fade/stretch other items to fit).

6

I think, the situation discussed here is when the hour has not been over-scheduled.

If you want perfect backtiming (align the end of the last song with the start of the news jingle), this could easily be done with a script:

  1. Determine the fixed time of the news jingle.
  2. Kick out all songs at the end of the playlist which will not get played (not even partially) anyhow.
  3. Determine the overlap, i.e., the time the playlist needs to be shortened. (You can just check the sttEstimated start time of the news jingle, and compare it to the fixed time.)
  4. Divide that time by the number of songs minus one.
  5. Adjust the Fade Out marker of all songs but the last one by exactly the duration from step 4.
7

Torben, like the solution you describe but scritpting is beyond me. Perhaps time permitting you could post a scrit example.

Its not important to us so only if time allows.

Kind Regards tony

edit and spelling looking at the above

8

Mmm! Exact Time … I like that adjective! Sounds better to me than Fixed Time, and it’s even the same number of letters! ;D

BFN
CAD