ProppFrexx ONAIR User-Forum

Hi there!

We tried it, still the same We changed the command file, now it looks like this:

ASYNC
PLS_CURRENT_AUTOPLAY_OFF
PLS_CURRENT_PAUSE_CURRENT 1000
EXEC_DIRECTPLAYER_CREATE Alert|C:\MediaLibrary\Alarm\Test2.mp3|OUT
SLEEP 500
EXEC_DIRECTPLAYER_PLAY Alert|false|0.0|0

The result is the same, the track paused and the next one played simultaneously with the alert.

We tried the following command:
as a result, after 1000ms, the current track was paused, and the next track automatically played, although, according to the idea, we turned off autoplay and paused.

Perhaps somewhere we can set up automatic playback at another level?

That’s what I meant above. Maybe you have set it somewhere else, eg. silence detection… else, there is no default setting.
Ie. you might need to turn on Debug Logging and send me the result.

Dear colleague, after some pause we would like to come back to our reserch

Here are the extended logs.

We turned them on before playing the command through event comands, everything is the same as before:
1. The current track stopped.
2. The audio notification (alert) started playing.
3. Another track started playing in the same time with it.
4. After which the first track stopped before the alert continued its playback.

Here is another topic on this forum where you helped me to insert jingles. Perhaps the settings described there are somehow related to the problem that the commands do not work out as they should. After all, with the standard configuration of the ether, the commands work as they should.

For jingles, this setting is used, it seems that the autoplay that is used when an alarm is triggered is related to these settings:

Yes, this is almost exactly what I meant above.
In your script, you have explitily set the for the script-lines the options: AutoPlayNext and StartAutoPlay.
These options should be removed, as else, the global AutoPlay setting (the AutoPlay button in the ribbon toolbar) is always overruled. Why have you even set it here? I don't see any reason for it.

I.e. when you have set the global AutoPlay setting, then a next track is automatically played. When AutoPlay is deactivated, this does not happen - this is also what we use for the Alert.
But with your two options, you always turn it back on - so please remove these options from your script-line.

Thanks for helping us solve our problem! We edited the script that we talked about in the previous message, now the command is:
The command is doing the right: pauses the current track, plays Dnipro_state_start.m4a and resumes the current track on the air.

If I may, one more question:

Let's simulate the situation when we sent two such commands to our application but with different audio files for playback, can we somehow edit this script with internal commands so that they do not interrupt each other on the air, so that thy system understands that these are notifications and they cannot be interrupted, and if the track from the air then it could be iterrupted.

Is it possible? Or in this case we simply cannot issue these commands at the same time and is it necessary to wait until the previous notification ends to start the next one?

So you mean, that not two Alerts are played in parallel?
Can you explain again in a bit more detail, what the exact condition is to play resp. not play an alert?

E.g. don't play an alert, if an alert is currently already playing.

so that the notifications caused by the commands do not interrupt each other in case of a simultaneous call, but play one after another.

E.G. in case then we have air alert in three regions at the same time. there will be 3 commands from API, the system will have to play three different notifications. We need them to be played one after another.

I am afraid, that there is currently no way to implement your requirement with the existing commands, as this requires some kind of 'sepmaphore' or 'queue' around your multiple Alert requests. So I am afraid, that you might need to implement that currently on your external side. E.g. wait til the first Alert has finished and then fire the next Alert...
I will continue to think about an internal solution, but that might take some time...