ProppFrexx ONAIR User-Forum

I guess any external system is doing the same. So that wouldn't change things. It is more a question of either pre-schedule all at the same time in advance or schedule all in real-time. But... What PF can do is the following: When you pre-schedule a show the above is happening. However when that pre...

Yes PF can almost do the same, as you can define so called program conditions.
E.g if a file exists execute a different script as if the file would not exist.
See here for details:
viewtopic.php?f=4&t=1016

Yes I can follow. However PF can only check the histories at its creation time. Meaning tracks are added to the history and checked against the history at the time when they are scheduled. That is for your the pee-scheduled playlist the time when you do that. And for any later playlist as well at it...

Are you maybe still using an 'Auto. Script Path' in parallel which points to that same folder?

A questions first: Are you using a 'shared' config folder for both your PCs? If yes, where exactly is your config file "ProppFrexx ONAIR.scriptlibs" be located? And what config paths are you using on both PCs...? The "ProppFrexx ONAIR.scriptlibs" contains the defined additional s...

You might sync the data manually
I'll put your consideration onto my list...as always

But real stations are not forced to 'share' the script lib folder/file - but that is not the point! In any case, what you describe only happens, if you do share the config - and this is what I call a special situation (no one said, that it might not be common for many; what you call real; stations)....

See above, I tried to explain it. And all this is a very special situation where you 'share' the same script config (file) between multiple ProppFrexx instances running on different PCs. And that special situation is another good reason for not deleting it...as a reliable warning could not even be d...

So that could indicate an issue I was already thinking about... It sounds, like your (global) history is again the issue. When forwarding a program takes very long (I guess it didn't even get fully stuck; but you aborted it before it can continue). Are you may be somewhere using a Media Library Hist...

As just discussed via eMail: If some of your media libs have a History set to -1, that might indeed explain the long forwarding time, as -1 is resolved to the number of media entries minus one – which might lead to that number of tries once an entry is found during scripting – especially when in add...