I continued to investigate and corrolated events and logs which helped to find some interessting details which hopefully help to get the helpfull hint for fixing from you.
There are 2 main reasons for switching between 2 Streams
1. encoder fail and tcp session from Encoder to EMS get closed
2. encoder fail and stop sending data or connection between encoder and EMS get "frozzen" in this case the tcp session stay open but no Data is arriving into EMS anymore. EMS close the stream after "streamsExpireTimer" from config.lua
In case 1. the RTMPingest inStreamClosed is detected first and the switching of Playlistitem works fine.
In case 2. the switching is not working, because the stream which is pulling the .lst stream expire first and this result into trouble with playlist as the current playing playlistitem get destroyed/shutdown. The RTMPingest get expired in same second, but in the log after the pulled .lst stream.
It means the main problem of not switching looks detected, but need your advice for a solution.
I run a few test by ingesting the Stream to another EMS with lower "streamsExpireTimer" which allows to detect the expired stream and related inStreamClosed from this EMS first. But this is not a solution as the additional EMS and related pull/push to the playlist EMS increase the delay, as well the main stream would pass more EMS which are a new potential point of failure. I did not found a solution to configure "streamExpireTimer" for a IngestPoint or dedicated stream, which I believe would fix the trouble.
Would it be possible to get a API command "setStreamExpireTimer" for an existing stream, which overwrite the config.lua "streamExpireTimer". In this case a RTMP Ingest could receive a lower streamExpireTimer after ingest started via EventHandler which should help to get this expired earlier than the outstream of .lst
Do you have any other proposal and/or solution?
The reported crash and trouble with Playlist may be related to the point that I send "insertPlaylistitem" when the ingest get closed, but the related .lst stream get closed just very shortly before which trigger action inside playlist handling, too.