Script rules and (previous) FTEs
Script rules and (previous) FTEs
I realise script rules don't apply to FTEs but are FTEs not looked at when used in "Previous Track Condition"? I tried setting the previous track condition to "~[IsFixTimeElement] = True" but it seems to not work. Is this intentional? If so, is there any other way to apply rules to tracks playing after a FTE?
Re: Script rules and (previous) FTEs
Hi,
no, that should work fine (FTEs are only excluded in the next/current track evaluation; but not in the previous evaluation)!
I just made a quick test here myself and it worked just fine.
In my test I did the following:
a) I created a script with 4 script-lines:
1. Cartwall, /StationIDs, Count=1
2. Random, /MyMusic, Count=1
3. Cartwall, /StationIDs, Count=1
4. Random, /MyMusic, Count=1
b) I created 5 FixTimeElements at :10:00, :20:00, :30:00, :40:00 and , :50:00
All of MediaType Jingle!
Then I created the following script-rule (to prevent, that after a FTE of MediaType Jingle; a StationID is played:
Previous Track Condition: ~[IsFixTimeElement] = True And [EntryType] = 3
Current Track Condition: ~[EntryType] = 28
Applies To: (default, not changed), but you can also Select All
Action: Supress
I then created a playlist and added 50 tracks from that script.
As a result, there was never a StationID track being followed after a FTE!
So all worked as expected and even FTEs are considered.
no, that should work fine (FTEs are only excluded in the next/current track evaluation; but not in the previous evaluation)!
I just made a quick test here myself and it worked just fine.
In my test I did the following:
a) I created a script with 4 script-lines:
1. Cartwall, /StationIDs, Count=1
2. Random, /MyMusic, Count=1
3. Cartwall, /StationIDs, Count=1
4. Random, /MyMusic, Count=1
b) I created 5 FixTimeElements at :10:00, :20:00, :30:00, :40:00 and , :50:00
All of MediaType Jingle!
Then I created the following script-rule (to prevent, that after a FTE of MediaType Jingle; a StationID is played:
Previous Track Condition: ~[IsFixTimeElement] = True And [EntryType] = 3
Current Track Condition: ~[EntryType] = 28
Applies To: (default, not changed), but you can also Select All
Action: Supress
I then created a playlist and added 50 tracks from that script.
As a result, there was never a StationID track being followed after a FTE!
So all worked as expected and even FTEs are considered.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Script rules and (previous) FTEs
Ah, I got the idea of what the condition did the wrong way round! I thought the condition specified what the current track should be and not what it shouldn't.
I did have weird ordering issues afterwards though a restart of ProppFrexx seemed to fix it for whatever reason.
Thanks!
I did have weird ordering issues afterwards though a restart of ProppFrexx seemed to fix it for whatever reason.
Thanks!
Re: Script rules and (previous) FTEs
Maybe you accidentally clicked a column header in the playlist and thus enabled sorting on it... else than that I do not believe, that a restart would have changed anything.
But I am glad you figured the issue.
But I am glad you figured the issue.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Script rules and (previous) FTEs
On the PC I was testing it on at home, it had a very small library (as in as few as 2 items each - my full library is at the studio), so I don't think it could've sorted it in any way that the same item weren't grouped together. I do agree it made no sense. I also had issues where creating a new playlist over the same program scheduler entry would not schedule FTEs.
But that's not happening anymore so there's little that can be pursued. I'll let you know if for some reason I notice anything odd again.
But that's not happening anymore so there's little that can be pursued. I'll let you know if for some reason I notice anything odd again.