connection closed by peer on stopping the RTMP stream

[talhatsk]

connection closed by peer on stopping the RTMP stream

[shogo4405]

I see. I believe the fix is simple, so I'm looking forward to your PR.

[xoraingroup]

@shogo4405 - It seems it might need to rename the command to deleteStream()

But I am not sure, if a separate method should be used to not break the API?

[xoraingroup]

@shogo4405 is this ok? I am waiting for a Yes or No :)

[shogo4405]

No. You need to consider the behavior when viewing, the behavior when using FCPublish, and the behavior when not using FCPublish. I have no knowledge regarding deleteStream, so I don't know. It will need to be investigated.

[xoraingroup]

closeStream closes stream but does not unpublish (delete) stream from rtmp server. This causes the rtmp server to not send webhooks because the stream is still there in rtmp server but in closed state and it waits for timeout of rtmp ingestion. The delete stream makes sure that the stream is unpublished from rtmp server and rtmp server sends the relevant webhooks to notify the relevant services. The webhooks are important part of creating flows and this is where we are stucked using this library.

From viewing perspective, the FCUnpublish with deleteStream unpublishes the stream and the client player just stops loading hls fragments. If fetching stream as rtmp pull, it just stops with error that stream does not exist.

I am not sure if i am making sense.

[levs42]

It makes sense in the context of your specific RTMP server. There are many of them, and they tend to have different implementations of RTMP spec. Therefore the best options is to create a PR with an optional deleteStream call. Here #1393 is a good example of handing undocumented FCPublish command in an optional manner.