Repeating FTEs out of place on initial schedule

[Bo98A]

I'm using a top of the hour FTE and am scheduling a long overnight program (9 hours) using the Playlist Template Wizard. When I do so, the FTEs get later and later until I get something like this:



Scrolling past the FTE and back to it fixed where it should have been placed but that would break any script rules that were enforced (example in the screenshot doesn't show that):



In this example, I'm using FTEs with a soft start time with a large maximum delay. However, the only difference that seems to make is that the "Schedule" column would always display {HH}:00:00 if it fell out of the maximum delay or if it was of Fixed type. I deliberately set the maximum delay very high in this example so that wouldn't happen so we could see how it gets progressively worse over multiple hours but you can still see the issue if you didn't do that.

There's nothing particularly special about the FTE: it's in cartwall mode and has the SuppressHistoryCheck and ForceLibraryHistoryCheck options enabled.

Contents of the script does not seem to matter: a single line of Random from a Music library with no options still results in the same issues.

I've tested both folder and DB music libraries. The audio files do not have metadata on them. The cartwall library used by the FTE is a folder-based one.

This will be that "weird ordering issue" that I described when asking about script rules after FTEs. I thought it was fixed but that was just because I was using a very small media library and scheduling a very small time period that I didn't notice.

Are you getting the same thing?

[Bo98A]

When do they get later and later? Initially when scheduled or over time when you play the pre-generated playlist?
I do not fully understand your issue?

The FTEs are not as close to the hour as it should've been. This seems to offset following hours when dealing with multiple hours.

When using the 'Playlist Template Wizard' all tracks are initially scheduled, thus, I assume at this point in time the FTE's should be at their correct location? Or are they not?

They are not until you scroll down the playlist and back up. It seems to correct itself then but then this means the script rules are not followed properly (I'm talking about when ~[IsFixTimeElement] = True is used in the previous track condition).

So when exactly are they getting delayed?

It just isn't scheduling as close to the hour as it should have, with the exception of the first item. See this screenshot for an example of what the first hour looks like (I simplified the script to a single line in Random mode for this example):

And finally the most important question, are the incorrectly played out (not at their given time)?
Or are they finally played out correctly?

It fixes itself on scroll. I will test how it is if it's played without scrolling.

And have you maybe ACPD (Automatic Cue Point detection) enabled? And did your track do have all cue-points already calculated or not?
The reason I am asking this is, because at the time the tracks are initially scheduled, the FTE position is calculated based on the effective track length 'known' at this time, e.g. as given in the playlist.
Later on, when reading in the TAG data or in case ACPD takes place for tracks loaded to the DJ Players, these timings might change, as now a 'better' information is available, e.g. the effective playtime including any segue and mixing settings.
The same happens by the way, in case you are playing out tracks manually from that pre-generated playlist and e.g. pause a current track for some time - this of course also changes the overall timing and an FTE position might become temporarily 'incorrect'.

As such, there might be moments in time, where the position of an FTE is NOT perfectly aligned with the scheduled time.
When ProppFrexx detects this fact (it checks this at least every time a track finished playing), it rearranges the FTE's position accordingly.
I guess this is what you are seeing as explained above!

I do have ACPD enabled and the tracks do indeed not have any cue points but this does not explain why it fixes itself when I scroll down the playlist.

In addition I am sorry to say, that your ScriptRules can not consider FTEs! I assume this is logic and a pure matter of priority. ProppFrexx considers the time of an FTE to be more important than your script rules.

I'm checking for FTEs in the previous track condition. But I still get the ordering issue described if I use no script rules.

A simply way to overcome this behavior is to make sure, that the effective length of all your tracks are known upfront. Meaning no ACPD takes place and all relevant cue-points are pre-defined.
Only this can guarantee, that tracks are perfectly scheduled ahead of time in advance. Else, as explained above, timings might change and need to be aligned on-the-fly.

I'll try disabling ACPD and see if that makes a difference but it does correct itself before I even start playing/loading anything.

[radio42]

Then all sounds like it works as designed.
As your tracks do not have a 'proper and perfect' length, duration resp. effective playtime available, the FTEs might initially be scheduled to an 'incorrect' place - thus ProppFrexx auto-corrects this once it gathered all the correct info.
This is how ProppFrexx works, and I guess this is perfectly fine

Please try to read me above post again, as it should almost answer all your new questions.

E.g. Script rules are ONLY evaluated when tracks are scheduled, when FTEs need to be later re-adjusted, of course these rules can not be checked again. FTEs do have a higher priority, rescheduling or suppressing tracks back into the future is not possible.

The tracks might have initially an 'incorrect' duration (that's why FTEs are initially placed to their initial location!), then after loaded to the playlist, as only then (at a later time) the TAG data might be read in and better timing information is available - they must be re-arranged, as they are detected as to be 'now' incorrect.
I guess this is even exactly what you want - but is not a bug.

In your case it sounds the media libs your are using doesn't have properly read in all TAG data?!

As said, it all depends on how your media libs and TAG data is already available.
So I guess only disabling ACPD will not really help.
Again, a simply way to overcome this behavior is to make sure, that the effective length of all your tracks are known upfront. Meaning no ACPD takes place AND all relevant cue-points are pre-defined!

As said, ProppFrexx rearranges the FTE at certain times automatically, at least once a track was played - but also at certain scrolling operations.

I assume, that you want ProppFrexx to have all information pre-calculated upfront. But ProppFrexx relies on the information given in the audio files; thus, if all the TAG info, mixing and segue info is there upfront, then I assume all would have been correct.
It is a chicken and egg issue.
ProppFrexx however assumes the egg (all info) to be there upfront. If not, things are adjusted at a later stage - with the effect, that FTEs are having a higher priority then scripting rules, which can later on not be reevaluated again - this is simply logically impossible.

[Bo98A]

I assumed adding a folder media library would copy in duration info from the audio file into _synced_.pfp, unless I'm missing something? Shouldn't that info be available for ProppFrexx to use without any additional steps?

I did indeed forget about duration in the DB media library which is why I quickly tested a folder media library as I thought that would cover it.

I'll properly fix the DB tomorrow and see if that works. DB libraries is what I'm going to want to be using anyway so I'll focus on getting that working and I will get back to you if I notice anything.

Other than that, ProppFrexx's behaviour does indeed make sense. Duration is something I thought might be at fault here but I didn't initially find a reason to why it would not be reading it properly.

I'm away from the studio so I will get back tomorrow.

[radio42]

Yes, folder based media libs should have the proper duration/track length set.
With them only the ACPD issue might arise over time... e.g. when 3 tracks are initially loaded to the DJ Players and each track is adjusted by something between 3 to 20 sec. effective playtime (note the importance of the next cue-point) the FTE's might initially be off by lets say 10 to 60 sec.

[radio42]

When do they get later and later? Initially when scheduled or over time when you play the pre-generated playlist?
I do not fully understand your issue?

When using the 'Playlist Template Wizard' all tracks are initially scheduled, thus, I assume at this point in time the FTE's should be at their correct location? Or are they not?
So when exactly are they getting delayed?

And finally the most important question, are the incorrectly played out (not at their given time)?
Or are they finally played out correctly?

And have you maybe ACPD (Automatic Cue Point detection) enabled? And did your track do have all cue-points already calculated or not?
The reason I am asking this is, because at the time the tracks are initially scheduled, the FTE position is calculated based on the effective track length 'known' at this time, e.g. as given in the playlist.
Later on, when reading in the TAG data or in case ACPD takes place for tracks loaded to the DJ Players, these timings might change, as now a 'better' information is available, e.g. the effective playtime including any segue and mixing settings.
The same happens by the way, in case you are playing out tracks manually from that pre-generated playlist and e.g. pause a current track for some time - this of course also changes the overall timing and an FTE position might become temporarily 'incorrect'.

As such, there might be moments in time, where the position of an FTE is NOT perfectly aligned with the scheduled time.
When ProppFrexx detects this fact (it checks this at least every time a track finished playing), it rearranges the FTE's position accordingly.
I guess this is what you are seeing as explained above!

In addition I am sorry to say, that your ScriptRules can not consider FTEs! I assume this is logic and a pure matter of priority. ProppFrexx considers the time of an FTE to be more important than your script rules.

A simply way to overcome this behavior is to make sure, that the effective length of all your tracks are known upfront. Meaning no ACPD takes place and all relevant cue-points are pre-defined.
Only this can guarantee, that tracks are perfectly scheduled ahead of time in advance. Else, as explained above, timings might change and need to be aligned on-the-fly.

So I assume, that what you discovered is by design and not a bug

[Bo98A]

I haven't fixed the DB library yet but I have been testing with folder libraries, and it still seems to happen but the repositioning happens when the playlist is opened rather than on scroll like it was before. I've disabled ACPD and it made no difference. I checked _synced_.pfp and the duration info is there. Note that I'm not even playing or loading anything into the players yet.

Is there something I'm missing?

[radio42]

I'll take a look...

Update 1: I am at least now able to reproduce it... need to check what is going on, I'll let you now when I find anything.

Update 2: Yes, there was indeed an issue with the very initial 'BacktimeCalculation' of the loaded playlist in case of the Template Wizard.
The internal playlist had been calculated correctly so far, but when displaying/adding the track the the playlist window initially, there was a bug. Luckily the bug almost 'heals' itself during playback and scrolling, as then the original ordering of the tracks is restored, but this is anyhow not good and looks 'false'! So no real need to worry, as playout etc. all works fine again.
But I'll provide a fix (hopefully) tomorrow anyhow...

[Bo98A]

Thank you, it's working better now!

There is still one case though where if the FTE has a "Max. Early" > 0. It seems like it is originally scheduled as if Max. Early was 0 but then corrects itself for that. I don't see it repositioning like before but the script rules are enforcing as if the FTE was where it would be if Max. Early was 0. Set "Max. Early" to something exaggerated like 300 and create a script rule with "~[IsFixTimeElement] = True" as the previous track condition and you'll see what I mean.

[radio42]

Yes, the 'Max Early' case can not really be considered upfront (and is such at the moment ignored during the initial playlist generation) and I guess/hope it will be much unlikely, that this causes much trouble.