Wrong stream status in database

[SebastienGautier]

Short description

We've had this issue a few times now where the stream status in the database does not reflect reality.
Last night a customer tried to stream but his connection got refused "because it's streaming" when it was not. In that specific case it somehow solved itself but I can't say how.
I suspect this is due to autoscaling shutting down the instance and not letting it update the state in the database.

We've had similar issues in the past.
I also have another example in mind where it was the opposite, the stream was ingesting properly but the status was "finished" in mongo.

Environment

• Operating system and version: Ubuntu 22.04
• Java version: openjdk 17.0.12
• Ant Media Server version: 2.12.0
• Browser name and version: unrelated

Expected behavior

When trying to stream we should be able to even if the database reports the stream as already broadcasting when it's actually not

Actual behavior

AMS refused the connection

Logs

[AMS] 2025-02-04 05:17:58,436 [NioProcessor-10] INFO  o.r.server.net.rtmp.BaseRTMPHandler - connectionClosed: VWPZYY0TVSVOS
[AMS] 2025-02-04 05:17:58,436 [RTMPConnectionExecutor-1] ERROR o.red5.server.stream.StreamService - You are not allowed to publish the stream ca629c14-47bc-2d27-bfb9-123456789101
[AMS] 2025-02-04 05:17:58,436 [NioProcessor-10] INFO  o.r.s.net.rtmp.RTMPMinaConnection - Connection is closed: VWPZYY0TVSVOS
[AMS] 2025-02-04 05:17:58,436 [RTMPConnectionExecutor-1] INFO  o.r.server.net.rtmp.BaseRTMPHandler - connectionClosed: VWPZYY0TVSVOS
[AMS] 2025-02-04 05:17:58,435 [RTMPConnectionExecutor-1] INFO  i.a.e.webrtc.WebRTCApplication - W3C x-category:session x-event:disconnect c-ip:192.168.222.187 c-client-id:4991
[AMS] 2025-02-04 05:17:58,435 [RTMPConnectionExecutor-1] INFO  i.a.s.AcceptOnlyStreamsInDataStore - Does not accept stream:ca629c14-47bc-2d27-bfb9-123456789101 because it's streaming

Do you check the status on a regular basis when ingesting a stream, if it does not have the broadcasting status then update it ?
Do you check the updateTime when a new connection comes to allow it if the updateTime is older than let's say 15 seconds ?
If not what do you think of my proposal or do you have better ideas to handle these cases ?

Regards,
Sébastien

[burak-58]

We discussed with @SebastienGautier in a meeting. There is already a control for checking broadcast status as suggested. We will observe the issue and check the logs with the latest version. I will close this for now and we can reopen if we encounter the issue again.