v2.1.46 b506: GetStartTime function not working correctly?

Archive mAirList 2.x (English)
1

I’m starting to write some scripting code which will ideally use start times of Items in Playlists, but running the code below gives bizarre results:

var
  i, iMax: integer;
  pi: IPlaylistItem;
  s: string;
begin
  iMax := CurrentPlaylist.GetCount - 1;
  for i := 0 to iMax do
  begin
    pi := CurrentPlaylist.GetItem(i);
    s := 'Item ' + IntToStr(i) + ' times: Fixed=';
    s := s + FormatDateTime('hh:nn:ss ', pi.GetStartTime(sttFixed));
    s := s + ' Plan=' + FormatDateTime('hh:nn:ss ', pi.GetStartTime(sttPlanned));
    s := s + ' Est=' FormatDateTime('hh:nn:ss ', pi.GetStartTime(sttEstimated));
    s := s + ' Real=' FormatDateTime('hh:nn:ss ', pi.GetStartTime(sttReal));
    SystemLog(s);
  end;
end.

In all cases, and whether in AUTO/playing, AUTO/stopped, ASSIST/playing, and ASSIST/idle, I see the following results:

[ul][li]Fixed times return a value of 00:00:00 if the Item does NOT have a Fixed time (hopefully you can see why this could cause enormous problems? :o)[/li]
[li]Planned times always return a value of 00:00:00 (same problem as with Fixed times).[/li]
[li]Estimated and Real times always return a value of [empty string] (after being formatted by FormatDateTime!).[/li][/ul]

It looks like Estimated and Real (presumably Real is an already-past Start Time, i.e. for Items already played/playing but still shown as History Items in the Playlist?) simply don’t return any value at all. It doesn’t seem to matter if the Item is playing, cued, stopped, or already played.

Fixed does return correct values if the Item has one, though I’m not sure what to write to find the type (soft, fixed) of ‘fixed’ time? BUT if the Item DOES NOT have any ‘fixed’ time, whatever is returned works out as 00:00:00, i.e. midnight. I strongly suggest it would be better to return nil (or should that be null?) for ANY GetStartTime if a time genuinely does not exist; returning (presumably zero?) the equivalent of midnight could lead to some horrible problems!

Is there a difference between Estimated start time and Planned start time? I’m confused as to the exact meaning of each of the four stt enumerations.

Slightly off-topic, but there also does not seem to be any way for a script to find out the Category (File, Dummy, Command, etc.) of a PlaylistItem, or am I being stupid again?!! That would be another huge help (for example, I might want to process only COMMANDs or BREAKs).

Finally, am I right in thinking that IPlaylist.Delete(iItem) is the correct way to Delete (remove) a PlaylistItem from a Playlist? I need to be sure of that before I write any scripts which delete any current Playlist items which would start after the ‘top of hour’ before Appending the next hour’s music etc. :wink:

BFN
CAD

2
Fixed times return a value of 00:00:00 if the Item does NOT have a Fixed time (hopefully you can see why this could cause enormous problems?

Not a bug.

TDateTime is a floating-point value, where the integral part determines the day (since 30 December 1899) and the fractional amount the time (where 1/24 is one hour etc.).

For the start times, mAirList only considers the fractional part. The whole numbers are ignored. An empty (undefined) time is encoded as “-1”. You can easily determine which start times are set by comparing GetStartTime(sometype) to -1.

Your example script uses FormatDateTime, and it also looks only at the fractional part, because it only outputs the time. Of course, the fractional part of -1 is .0, which is displayed as 0:00:00.

As a programmer, you should know that “nil” and “null” are the same concept, because they are both encoded as the binary value 0. Using -1 was the easiest solution to mark an undefined value other than introducing any “StartTimeSet” flags or so.

Planned times always return a value of 00:00:00 (same problem as with Fixed times).

sttPlanned is unused at the moment. I plan to introduce it along with the scheduling features of mAirListDB in order to store the time for which the item was originally scheduled (in the database).

Estimated and Real times always return a value of [empty string] (after being formatted by FormatDateTime!).

Apparently a bug in Pascal Script. FormatDateTime is an overloaded function (with two parameter sets to choose from). It seems that PS references the wrong one. Will be investigated.

3

All understood, and thanks for the corrections!

[later]

Indeed, a test for <> -1 does the job, such as:

const
  TIME_NOT_VALID = -1;
var
  dtStart: TDateTime;
  pi: IPlaylistItem;
begin
  pi := CurrentPlaylist.GetItem(0);
  dtStart := pi.GetStartTime(sttFixed);
  if dtStart = TIME_NOT_VALID then
    SystemLog('The first Playlist Item does not have a fixed time.')
  else
    SystemLog('The first Playlist Item has a fixed time of ' 
    + FormatDateTime('hh:nn:ss ', dtStart) + '.');
end.

The reason I’m interested in start times is that I am developing a script to ‘drop in’ soft-fixed-time ad breaks during ASSIST mode shows (which is most of our broadcast output!); and at times other than top-of-hour.

To achieve that, the script will examine the (Estimated?) start times of existing PlaylistItems in order to ‘drop in’ the ad. break items at a sensible place which is ± five minutes of the ‘ideal’ ad. break time (for our station, this will probably be at nn:20:00 and nn:40:00).

BFN
CAD

4

Regarding the “empty string” bug, take a look at your original post. There’s a + sign missing before the last two FormatDateTime calls. I wonder why PS doesn’t complain about the syntax error. Instead, it executes the code but does not concatenate the strings, of course.

FormatDateTime works fine. I will close the Mantis ticket.

5

[quote=“Torben, post:4, topic:5081”]There’s a + sign missing before the last two FormatDateTime calls. I wonder why PS doesn’t complain about the syntax error.
I will close the Mantis ticket.[/quote]

:o AAAAARRRRGGGGHHH! :-[ A missing concatenation operator >SIGH<. Of course …

HOWEVER ;), now that I’ve corrected that, I see another problem and (I think) how to solve it. :smiley:

Referring to them by their constant names:

An sttReal returns blank or (obviously?) the current date and the actual start time. If sttReal returns a non-blank, it implies (?) that the Item is currently playing.

An sttPlanned always returns blank at present: it is not in use until mAirListDB exists, when it will show the DB-planned start time (and hopefully date as well!??) if one exists.

So far, so good! BUT …

An sttFixed returns blank or the fixed start time with a (constant) date of 30/12/1899. It would be MUCH better if the actual start date was returned instead of 30/12/1899. This would need to take account of any change of date when a Playlist runs ‘over’ midnight. For example:

[ul][li]=23:59:50 News jingle[/li]
[li]=00:00:00 Run News playout script[/li][/ul]

The dates returned by sttFixed for these two items will be different; or they SHOULD be. :wink:

An sttEstimated returns blank or the relative or actual estimated start time with a (constant) date of 30/12/1899. In a currently ‘stopped’ or ‘idle’ Playlist, these always start with 00:00:00 and follow as expected (for example 00:03:36, 00:08:01, … ). Therefore it is impossible to know whether the returned value is relative as in my examples, or an actual time of midnight. If actual estimated times were instead returned with the current date (same caveat as sttFixed about ‘crossing midnight’ applies), it would be very easy to tell whether a returned estimated start time is relative (date = 30/12/1899) or actual.

It’s not easily possible to write a script to insert Items based on existing start times in the Playlist, unless you can be certain that the estimated time you are picking up is actual and NOT relative. Which probably means I also need to check whether or not the Playlist has its Update backtiming when idle option set ON, as well as whether it is currently playing. :-\

So to sum up, this is now a Feature Request to return the current date (or maybe tomorrow’s date if it’s after midnight) instead of 30/12/1899 for sttFixed, and also for sttEstimated when it contains an ACTUAL estimated start time (not a RELATIVE one).

(PS: What I’m planning is a script to insert an Ads. playlist so it plays ‘as close as possible’ to, for example, nn:20:00 or nn:40:00, in a live-assist situation. This means I need to know start times of existing items to work out WHERE to insert the Ads. Playlist, if that makes sense? Of course, if the presenter is yakking on, I can’t move the inserted Ads. after the fact, but it still seems the best solution. ;D)

BFN
CAD

6

sttFixed contains the fixed time as entered in the Properties dialog. Remember that you only enter a time, but not a date. So even though it is saved in a TDateTime variable, mAirList only uses the time (fractional) part, and the date (whole number) is set to 0.

mAirList 3.0 will introduce another time value, sttEffectiveFixed. This is because of the new “reverse backtiming” feature available then, which will backtime the item so that it ends at a given time. For the “ordinary” fixed time items, it will contain a copy of the sttFixed value, for the “reverse” items, it will be the sttFixed value minus the duration of the item. I can easily add the date part to sttEffectiveFixed.

Adding the date part to sttEstimated should already be possible in v2.1. Can you please post it as a feature request to Mantis?

7

Excellent. I’ll post the Feature Request shortly.

It will now be even MORE useful to have StringToDateTime exposed and working in mAirList scripting. I can then make my ‘inject ads. playlist’ work across midnight in more situations. :wink:

BFN
CAD

8

I have looked into this issue again - and I might be confused, but isn’t the sttEstimated part the way you want it already?

For example, switch on the live backtiming and run this little script:

begin
  SystemLog(FormatDateTime('mm-dd-yyyy', CurrentPlaylist.GetItem(0).GetStartTime(sttEstimated)));
end.

Voilà, it will display the current date, because it’s an absolute time.

To check whether the time is absolute or not, you can just compare the value to, say, 1000. If it’s greater, it’s most presumably an absolute time (unless you happen to run mAirList in the year 1902).

9

[quote=“Torben, post:8, topic:5081”]Voilà, it will display the current date, because it’s an absolute time.
To check whether the time is absolute or not, you can just compare the value to, say, 1000. If it’s greater, it’s most presumably an absolute time (unless you happen to run mAirList in the year 1902).[/quote]

Actually, and having re-read all of this thread, my original problem was that I could not easily determine whether an sttEstimated time value is relative or absolute. Whic you have just rather neatly answered! A simple IF test for >1000.

I’ll test that later to check this, but assuming that it works :D, I think will solve my problem: THANK YOU!

BFN
CAD

10

For the threshold, just choose a value which is larger than your playlist will ever grow (3 years will do it, huh?) - and smaller than the current date.