How do you handle streaming with connection lost

[marceliano13]

Basically that, how do you handle HLS or LL-HLS when you have video stream that can have multiple connection lost. I know that for every stream restart it will create a new .m3u8, but how will i manage that on the Frontend (in OvenPlayer or any other Web Browser Player).

How do you guys handle this? I'm i thinking the problem the wrong way?

[naanlizard]

We have robust logic for stream start and end, and disconnects go through the normal flow

…

On Mon, Jun 9, 2025 at 16:15 marceliano13 ***@***.***> wrote: Basically that, how do you handle HLS or LL-HLS when you have video stream that can have multiple connection lost. I know that for every stream restart it will create a new .m3u8, but how will i manage that on the Frontend (in OvenPlayer or any other Web Browser Player). How do you guys handle this? I'm i thinking the problem the wrong way? — Reply to this email directly, view it on GitHub <#1860>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABV4BWICCHVRDLTTM67RGTT3CWQHNAVCNFSM6AAAAAB65GHMP6VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGQZTGNJRG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[marceliano13]

My problem is not the robustness but its the fact that every time the stream starts again, it will create a new .m3u8.

I had the ideia of using LL-HLS for my live app but i have the following challenge

Lets say:

1. Start Streaming
2. Creates 1.m3u8
3. Stop Streaming
4. Start Streaming again
5. Creates 2.m3u8

Now i have two .m3u8, where the 1.m3u8 has like 1h of segments and the 2.m3u8 has another hour of segments. So i have a stream of 2 hours already, but in the web browser player i can only deliver one .m3u8 file.

[getroot]

You can create a permanent channel with Scheduled Channel.
https://docs.ovenmediaengine.com/live-source/scheduled-channel

[marceliano13]

I've read about it, it didn't appear to suit my use case but i'll do some tests and let you know.
Thank you very much

[marceliano13]

Hello @getroot regarding this we detected a behavior that happens when we don't stream immediatly for the Channel.
If we create the channel and after 10 min start stream, it looks like it will fill the 10 min that didn't have video with the first video frame, so we will have 10 more minutes than the reality.

We can see this happens when we check the Dump of the channel. The dump will have the first 10 minutes fill with the first frame of the video.

I know that this happens if we used a fallback program, but i was not expecting this to happen without a fallback program.

I'm i wrong? Can be something on our side? Could you help us on that?

[getroot]

@marceliano13
Is this the situation you are describing?

1. The scheduled channel starts and a live input comes in, so the stream begins.
2. The live input is disconnected for 10 minutes.
3. The live input comes back.
4. When you check the dump, the 10-minute gap is filled, even though there is no FallbackProgram.

If this is what you mean, this is the intended behavior. The scheduled channel is designed to fill the entire timeline. Usually, a VoD such as “Not On Air” is configured in the FallbackProgram to cover such periods.

[naanlizard]

For our setup the llhls playlist doesn't change names. So e.g. a user connects to their stream name and then when they disconnect and reconnect, they're always connecting to the same stream

…

On Mon, Jun 9, 2025 at 16:39 marceliano13 ***@***.***> wrote: My problem is not the robustness but its the fact that every time the stream starts again, it will create a new .m3u8. I had the ideia of using LL-HLS for my live app but i have the following challenge Lets say: 1. Start Streaming 2. Creates 1.m3u8 3. Stop Streaming 4. Start Streaming again 5. Creates 2.m3u8 Now i have two .m3u8, where the 1.m3u8 has like 1h of segments and the 2.m3u8 has another hour of segments. So i have a stream of 2 hours already, but in the web browser player i can only deliver one .m3u8 file. — Reply to this email directly, view it on GitHub <#1860 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABV4BWKXMU4E2T2VBNWOF4T3CWTBTAVCNFSM6AAAAAB65GHMP6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNBRGE2DONQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[marceliano13]

Correct me if im wrong or doing something wrong, i've done some testing and when i enable DUMP on LL-HLS the behavior its like this when i stop and start the same stream.

I still have two different LL-HLS .m3u8's

[naanlizard]

Why are you not just using /appname/stream name/llhls.m3u8 (could have the formatting wrong there, this is off the top of my head)

…

On Mon, Jun 9, 2025 at 16:57 marceliano13 ***@***.***> wrote: Correct me if im wrong or doing something wrong, i've done some testing and when i enable DVR on LL-HLS the behavior its like this when i stop and start the same stream. image.png (view on web) <https://github.com/user-attachments/assets/e6781c4b-b75b-48f3-8c9c-ea6b53ad04b1> I still have two different LL-HLS .m3u8's — Reply to this email directly, view it on GitHub <#1860 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABV4BWKUJTERCV5FWIJNGB33CWVHBAVCNFSM6AAAAAB65GHMP6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNBRGE3DGNI> . You are receiving this because you commented.Message ID: ***@***.*** com>

[marceliano13]

Because that llhls.m3u8 will only have the current .m3u8.
Lets say im streaming, it create a llhls.m3u8 that points to "chunklist...Bnow9A...m3u8", i stop streaming.
When i start streaming, it will create the new "chunklist...QXSdkYjD....m3u8" and llhls.m3u8 will point to "chunklist...QXSdkYjD....m3u8" and i "lose" the data from the first m3u8 on web player

[naanlizard]

Ah I understand the problem better now. Unfortunately I don't have a fix for that. Probably you'd have to do some custom player logic or something?

…

On Mon, Jun 9, 2025 at 17:03 marceliano13 ***@***.***> wrote: Because that llhls.m3u8 will only have the current .m3u8. Lets say im streaming, it create a llhls.m3u8 that points to "chunklist...Bnow9A...m3u8", i stop streaming. When i start streaming again the llhls.m3u8 will point to "chunklist...QXSdkYjD....m3u8" and i "lose" the data from the first m3u8 on web player — Reply to this email directly, view it on GitHub <#1860 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABV4BWPTYHKXRS4EF3FUTWL3CWV6FAVCNFSM6AAAAAB65GHMP6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNBRGE3DSNA> . You are receiving this because you commented.Message ID: ***@***.*** com>

[marceliano13]

The problem is not in the web player, it's on how the .m3u8 are handled. For example FFmpeg has a way of solving this problem with this flag: -hls_flags delete_segments+append_list

It will add a #EXT-X-DISCONTINUITY tag when we get input back after losing it, and will keep writing the segments on the same .m3u8.

Do you think Scheduled Channels feature will help me on that?

[tzarebczan]

Looking into this as well for our use case, but not only for connect/disconnect/connect, but also service upgrades/restarts. Let's say a user is streaming, and then we reload the docker - this creates a new stream, and all old hls segments are gone right? On the playback side, players generally don't handle this nicely and require custom recovery. And it would be nice to still go back further in the stream when it happens.