MODStream behavior with overlays

You have a question or need an advice about how to do something? Ask it here!
Maartenvn
Posts: 101
Joined: 21 Aug 2022 19:47
Re: MODStream behavior with overlays

Post by Maartenvn »

Yes, I have checked the option. Overlays are also still showing up and playing on top of the MODStream player.

Image

I am opening the MODStream using:

Code: Select all

MODSTREAM_WATCHER_START <url>||True|True|True
Maartenvn
Posts: 101
Joined: 21 Aug 2022 19:47
Re: MODStream behavior with overlays

Post by Maartenvn »

I did some testing. The regular MODStream that is configured in the settings works as expected, but when the MODStream is created using the control command the Supress option is ignored.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: MODStream behavior with overlays

Post by radio42 »

The new option is completely independent of how it is started. And the control-command and the ribbon tab button do actually call the same method in the end - so there should be absolutely no difference. Very strange...

And can you post your command, as the above doesn't really look according to the definition:

Code: Select all

MODSTREAM_WATCHER_START <url>[|<length>|<stopPlaylist>|<startWithNextTrack>[|<songTitle>[|<playonce>[|<introfile>[|<outrofile>[|<url2>[|<alwaysPlayIntroOutro>]]]]]]]]
So your command might be for example:

Code: Select all

MODSTREAM_WATCHER_START url|3600|True|True|My SongTitle|True
Maartenvn
Posts: 101
Joined: 21 Aug 2022 19:47
Re: MODStream behavior with overlays

Post by Maartenvn »

I forgot the append the songtitle in my previous command. I changed it to follow the spec:

Code: Select all

MODSTREAM_WATCHER_START <url>||True|True|Some Songtitle|True
I am still able to reproduce the issue though, the Overlay Player is not suppressed.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: MODStream behavior with overlays

Post by radio42 »

Found the issue, there was indeed a case I did oversee - a new v4.3.4.2 is available!
Maartenvn
Posts: 101
Joined: 21 Aug 2022 19:47
Re: MODStream behavior with overlays

Post by Maartenvn »

I seem to have found an edge case with the suppression.

When the Overlay is in "Waiting" mode (Waiting on track to end), it is not suppressed when the MODStream is opened.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: MODStream behavior with overlays

Post by radio42 »

Currently the Overlay is only cancelled when it was not yet started. I assume, that in your case you might have defined an Overlay as Soft start, but the Overlay time is already beyond its official start time.
Example:
An Overlay's Start Time is defined @ 15:00:00 to start Soft with a max. delay of 120 sec.
It is now e.g. 15:00:17 (after the official start time), but the Overlay is still 'waiting' as the current track's remaining time is still e.g. 47sec.
When you now start the MODStream (after the official start time of the Overlay) - that Overlay is NOT cancelled.

That is the only case I can see right now and yes, this is currently be design.
I.e. you should start the MODStream BEFORE the official start time of the Overlay - then it is always cancelled.
If you start the MODStream AFTER the official start time of the Overlay - then it is NOT cancelled.
Note, that this scenario can only happen with Soft start Overlays!

This gives quite some good control about defining what priority is currently more important: the Overlay or the MODStream.
This scenario was also the scenario you described initially:
* Overlay for 7:05 shows up at 7:00 with a 5 minute countdown.
* MODStream player becomes active at 7:01.
* Current playing track ends at 7:02.


But maybe another question (if you really want to ALWAYS) give the MODStream the priority:
How should the system behave, if the Overlay just started playing (or is about to start playing) and you then start the MODStream? Same, if you activate 'Allow Start Early' with the Overlay...
Should the MODStream interrupt/cancel any (already playing overlay)?
Should the MODStream "Start Delay Time" somehow be considered?
As else, the MODStream might start and wait that delay - but the Overlay is just 1 seconds before it's start cancelled - this might also result in some dead air (Playlist already stopped, Overlay cancelled, but MODStream initially waiting)?
Maartenvn
Posts: 101
Joined: 21 Aug 2022 19:47
Re: MODStream behavior with overlays

Post by Maartenvn »

Let me draw out how we are exactly using the MODStream player.

I have made some custom software to allow DJs in the studio to easily start a live broadcast. This is done by pressing a button which will start a countdown. This countdown is either the remaining time of the playing track or the remaining time of the playing overlay.

When the countdown reaches a specific remaining time (the latency on the connection) the program will automatically start a new track on the live DJ ProppFrexx instance, which makes sure that there is a clean, unnoticeable, takeover by the MODStream player.

With the new Suppress Overlays feature, this works great in almost every scenario, except when the overlay is in the state of "Waiting on track to End". I am unable to get the remaining time of the overlay using a macro before the overlay is started, and if I would it would make things a lot more complicated.

To answer your question about when to cancel an overlay: if it has not played any audio the suppression should close the open overlay. If the overlay is playing audio it should not be cancelled as this would cause abrupt transitions to the audio.

I hope this clears up everything. If you have any recommendations to tackle this differently, please let me know :)
Maartenvn
Posts: 101
Joined: 21 Aug 2022 19:47
Re: MODStream behavior with overlays

Post by Maartenvn »

Should the MODStream interrupt/cancel any (already playing overlay)?

No, this would cause abrupt changes.

Should the MODStream "Start Delay Time" somehow be considered?

I did not consider this case, as we use no Start Delay Time. But in this case it would be best that the suppression only kicks in once the MODStream is in the "Waiting" state rather than the "Connected" or "None" state. This way there is no dead air.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: MODStream behavior with overlays

Post by radio42 »

Well, the main issue is, that there is a difference in the "Waiting on track to End" state (it is not shown in the UI, as this might raises more questions than answers). I.e. there is a "Waiting on track to End" state before the effective Start Time and a "Waiting on track to End" state after the effective Start Time.
Regardless, I might try to allow the cancel a bit tighter as long as it is before the Overlay effectively plays - but there might always be some milliseconds in between, where an overlay can not be cancelled anymore.
So the start of the MODStream should always be at least a few seconds before the Overlay starts - I hope your SW deals with that.

Post Reply