Whats the difference between Stream targets and Startup Streams?

[Kay_Werner]

Right now I’m using stream targets to restream to youtube (and others) with WSE 4.8.10. This looks good and the configuration works as expected.
I came around the question if the targets retries the connection to the destination:

1. if the source disconnects and connects later (several hours/days) again?
2. if the destination is not available for several hours/days and becomes online again?
3. if the WSE server boots or restarts?

Does any body has experience on these 3 usecases? I could not find a doc regarding the default behavior of retries and reconnects.

While searching I came around Startup Streams. This feature looks like suitable for the same usecase (restreaming to multiple other platfomrs). What is the difference? When to use what?

Thanks, kind regards

[Dorota_Szafer-Kwasik]

Hi.
Stream Targets - configured, running - working
Wowza restart - works again
Disable source - Stream Target: waiting for source
Turning on source - Stream Target broadcasts to destination
Once configured Stream Target will always wait for the indicated source. As soon as it appears it will start broadcasting to the selected target.

Startup Streams - once the source is configured and started, for example, sample.stream / IP camera / works.
After rebooting Wowza will not reappear.
To appear sample.stream you need to add it to Startup Streams, also.
Then after a restart - your sample.stream appears
That’s all

[Connessione]

@Kay_Werner I understand that you are using Stream Targets that is used for streaming to other external supported destination. The issue you mentioned is use cases of disruptions. There was a similar post about Facebook API on this forum the other day about disruption in the 24x7 stream. The suggestion was to take a few minutes break.

Startup streams are good for other use cases - specially IP cams, live repeater, etc. I did not find stream targets listed there. Startup streams are useful if your server crashes or is manually restarted etc and you want to resume the supported stream actions.

In your case it is more about automation I believe. If the server isn’t already doing it the way you want you can use the APIs to make it do what you want.

1. if the source disconnects and connects later (several hours/days) again? - I assume if the configuration persists then the stream target should still be valid. when the broadcast resumes the stream target should resume. Youtube streamkey does not change but FB or others might have issues. In that case, you will need some DevOps script to automate the setting up or the stream target via Stream Target API once more.

2. if the destination is not available for several hours/days and becomes online again? - The stream target config once into the error state may not retry to connect again after the destination is back. It is not aware of the external service state. Once again here you can try to make use of the REST API. Also, see this.

3. if the WSE server boots or restarts? - Stream targets seem to be a persistent configuration I believe. In which case with the restart of the server, the config will come back, and as publish resumes the streaming will too. Once again if it does not make use of API for automation.

Hope that helps.