ProppFrexx ONAIR User-Forum

Hi All,

At the moment i am running into some trouble trying to set up automatic recordings for our live shows.

Our situation:
Due to the fact that we are working with all volunteers who have normal day jobs our station runs automatic for the most part of the week. Only in the evenings and in the weekends we play live dj shows. During the nonstop automation hours PFOA will schedule the playlists, but for the live shows i scheduled playlists as well, so that, if for any reason a dj is not available for his show, the system will play a playlist with appropriate content.

Furthermore we play every hour 24/7 at the TOH a news bulletin and during daytime this newsblock will be preceded/followed by a block with commercials. The commercial blocks could be empty depending on the amount of commercials available for a given timeslot.

The goal is to record every live show, but without the news and commercials, to use the recording for a listen on demand service.

Our hardware/software setup:
PFOA is connected to an external mixer with 4 faders assigned to player A/B, Cartwall and other (trackboard, pfl, segue editor, etc) The overlay player is not on a fader! The external mixer's start/stop signals are send to PFOA with a Velleman card.

What i tried so far:
1. Schedule playlists with the recording start/stop commands in it. This is no good solution because the dj's will normally create a new playlist when they arrive in the studio. So, the scheduled playlist will normally NOT be used, only in the case the dj is absent for some reason.

2. Schedule the recording start/stop commands in the commercial blocks in the ON_OVERLAY_PLAYED events. This is no good solution because it is not a guarantee that every liveshow will be preceded and followed by a commercial block.

3. Because we start every liveshow with an opening jingle i came up with the idea of creating an extra overlay block just to play this opening jingle and assigned the recording start/stop commands to this block. Unfortunately this is working irrationally. Sometimes it works, but most of the time it does not. As i think this would be the best solution to my problem i will show the setup of my overlay blocks in the following screenshots: https://www.jekare.nl:11001/ns/sharing/mFVo9 (probably too much to embed in this message).

The mixer channel IN1 in PFOA is ON and not muted. I cannot think of anything why the recording is not started, help is appreciated.

With kind regards,

Jack Reitsema
ITC Havenstad.FM

What exactly is not working in case 3.?
I assume the play out order is okay?!
But is just the recording not always started?
I assume you use the combine parallel overlays option?
Unfortunately I am now for 2 weeks on holiday so I cannot fully recreate your scenario during that time.

But what you might try is to remove the recording OFF command. I assume all commands are executed at the same time and as such the recording OFF and ON might happen in parallel.
As any new recording will regardless always stop any other currently running recording, there is no need to turn that OFF in parallel.

Hi Bernd,

Please enjoy your holidays first, i will understand it if you refrain from answering until you return home.
I will do some further tests and let you know.

Regards,

Jack Reitsema
ITC Havenstad.FM

No problem. Just try what I explained above.

Hi Bernd,

I did some more testing and here are my findings. As you suggested i removed all MIXER_INPUT_REC_OFF commands.

I scheduled all OVERLAYS on the same time with a prio setting as indicated and if i add REC to the blockname it is the block with the MIXER_INPUT_REC_ON command in the ON_OVERLAY_PLAYED event.

Tested scenario's:

1. Scheduled 1 block prio0_REC: everything works as expected. Recording starts and if a recording is already running it will be stopped first.

2. Scheduled 2 blocks prio0 and prio1_REC: the blocks play out in the correct order, but the REC command is not executed.

3. Scheduled 2 blocks prio0_REC and prio1: the blocks play out in the correct order and the REC command is executed.

4. Scheduled 3 blocks prio0, prio1, prio2_REC:
4a. All 3 blocks have content: the blocks play out in the correct order, but the command is not executed.
4b. Block prio1 is empty: the blocks play out in order, block prio1 is simply ignored, but the command is not executed.
4c. Block prio0 is empty: the playout order changes to prio2_REC and prio1. Now the REC command is executed but the prio1 block is played after the prio2 block.


I did not find the time for a conclusive test, but a prelimanary conclusion from these results is :

1. If multiple overlays are scheduled at the same time the prio works allright as long as all overlays are filled.
2. If one or more overlays have no content the prio order is not consistent.
3. If multiple overlays are scheduled only the commands defined in the first block will be executed.

Perhaps you can do some more testing after your vacation and start from here.

Kind regrads,

Jack Reitsema
ITC Havenstad.FM

Yes I'll do some more testing after my holiday.

I just double checked my code, but from a code perspective the above can not happen!
Meaning, if there are multiple overlays scheduled at EXACTLY at the same time! (which must have the exact same Start Time AND also the same Show In Advance time!) - they are sorted regardless if they have content or not.
So I assume, that in your tests the overlays are not using exactly the same time?!

I even made some tests, like yours above but can not reproduce.

The only issue which is currently true is, that the 'parallel' control-commands are currently not combined.
Meaning 'only' the 'first' overlay's commands are executed.
I'll take a look, that this will be changed in a next release.

Hi Bernd,

I did a lot of tests and am sure i used the exact same Start Time and Approx. Duration. I'm not certain of the same Show in Advance times in every test i did. Does it matter if the first overlay has an EndsAt time and the next overlays have a Fixed start time? Could that be a reason for the prio's to reorder?

If the parallel control-command issue is fixed that would help a lot and i will try to find the time to do some more testing regarding the correct order. I'm pretty sure there was an issue with the order somehow.... I will let You know.

Again, thanks a lot for your great support!

Kind regards,

Jack Reitsema
ITC Havenstad.FM

Hi Bernd,

I did a lot of tests and am sure i used the exact same Start Time and Approx. Duration. I'm not certain of the same Show in Advance times in every test i did. Does it matter if the first overlay has an EndsAt time and the next overlays have a Fixed start time? Could that be a reason for the prio's to reorder?

If the parallel control-command issue is fixed that would help a lot and i will try to find the time to do some more testing regarding the correct order. I'm pretty sure there was an issue with the order somehow.... I will let You know.

Again, thanks a lot for your great support!

Kind regards,

Jack Reitsema
ITC Havenstad.FM

Yes in order to combine parallel overlays they need to have the same start type.