ProppFrexx ONAIR User-Forum

Hi Bernd,

I'm not sure if this is a feature or a bug, please enlighten me...

The problem: Sometimes if a user logs off (click the padlock icon) the message 'Logoff in progress...' remains visible for a long time before the regular login window appears again. It took me quite some time to find the cause and to reproduce it, but here it goes:

• Set Use UAC to ON

• Create a few programs in the program scheduler, we use hourly programs. Make sure to set the type to 'Auto' and 'Show .. seconds in advance' to 300 (this will show the next playlist at HH:55)

• Close PFOA and restart it again

• Login as administrator and play the current playlist (Auto Play = ON)

• If at HH:55 the next playlist opens in a new tab try to log off

• Notice how the message 'Logoff in progress...' will be visible until HH:00 when the new playlist becomes active

In our studio we have dj changes taking place at HH:00. What will happen in a live show is that the leaving dj will play the last song(s) in his playlist on Autoplay as he logs off to enable the next dj to login again so he can prepare his show opening (using his own cartwalls etc.). It will be a problem if he has to wait until HH:00 to be able to login again.

Please let me know if i am missing something or if this logoff delay is a regular problem...

With kind regards,

Jack Reitsema
ITC Havenstad.FM

Never noticed that. I will check when back home.
But a 5 minute delay sounds like something is going wrong.

But I would never really set the start type of a program to Auto, as in certain situations this might mean it switches to manual start! Or is that wanted?
What happens if the program is set to Soft does that also happen then ?
And do you click on logoff before the new program started or do you logoff after the new playlist showed up?

Hi Bernd,

It does not matter if the program start type is set to AUTO or SOFT, in both cases the logoff delay will occur. And you have to click logoff AFTER the new playlist has showed up. Then the 'logoff in progress...' message will remain visible until the new playlist becomes active.

In our current setup (still testing, not live) i created program scheduler entries for every hour with a weekly repetition. We plan a program for each live show as well to make sure that, if the dj is not in the studio for some reason, a program with the appropiate music is played anyway. If the dj is present in time, he can import/create his own playlist and get rid of the scheduled playlist or just change the scheduled playlist.

Around the Top-Of-Hour we play the overlays for commercials - news - commercials where the first commercial overlay EndsAt hh:00 and the news (prio 1) and second commercial (prio 2) overlay will start at fixed hh:00. We only schedule commercials during daytime. All overlays are set to 'Suspend Program'. In a live dj show the dj will have to watch the overlay countdown to finish his show in time, because we play the overlays automatically.

For every program entry i used program type AUTO, Max. Start Delay 300 seconds and Show 300 seconds in advance. During my testing the new playlist is always starting automatically when the overlays have finished and the new playlist is always started with AutoPlay ON even if the playlist before hh:00 was played with AutoPlay OFF.

The only situation where i noticed the manual start of an AUTO playlist is when a manually created playlist is played with AutoPlay OFF. Then the next AUTO playlist will start manually, but AFAIK that is the only case where this happens, is it not? And perhaps in this case a SOFT start type might indeed be better.

With kind regards,

Jack Reitsema
ITC Havenstad.FM

No you are totally right with your above assumptions.

I also already look at the code (while just flying back home - good thing to now have internet even OnAir ... and yes, there was indeed some 'old Waiting-Code' in place, if the 'user change' was happening while the scheduler is currently starting a new program.
The reason was, that with an old UI lib there had been some problems, but I guess these issues have already been fixed by the UI vendor.
So I'll remove that waiting code in the next version... !

Fixed in the latest v4.0.1.27 - update.