Question streams are too slow in XUI one compared to xtream UI

[Xpert007]

Hello Everyone, i'm facing an issue with streams speed in xui one , channels on demand are too slow to play , the ffmpeg are intgreted in xui one and im not using any code but streams can take up to 1 min to show and the source is a live stream

is theres a setting that i should configure so that streams can show up faster please ?

 

[jamess88]

Hello Everyone, i'm facing an issue with streams speed in xui one , channels on demand are too slow to play , the ffmpeg are intgreted in xui one and im not using any code but streams can take up to 1 min to show and the source is a live stream

is theres a setting that i should configure so that streams can show up faster please ?

for each on demand feed set the following:

On Demand Probe Size: 3000000
Headers: -i {INPUT} -c copy -analyzeduration 3000000 -probesize 3000000

this will make it super fast, along with enabling the " Instant Off"

 

[julian]

for each on demand feed set the following:

On Demand Probe Size: 3000000
Headers: -i {INPUT} -c copy -analyzeduration 3000000 -probesize 3000000

this will make it super fast, along with enabling the " Instant Off"

Hi, thanks for the info, I am also having the same problem. In my case, some times, the stream does not open at all. Then open quickly after changing channel and returning to the dark channel. The source is good. Are the above settings in conjunction with LLOD 2 or LLOD disabled? LLOD 3 should not use ffmpeg so I assume it does not apply. Also, will on demand probe size 3000000 cause streams to be delayed as compared to live?
I just tried the settings provided above and it makes the situation worse, at least for me it did not go well. The stream also fails multiple times while opening. Once the stream is up, uptime will be many hours
What settings do you use in general settings > streaming > Wait Timeout, Exit on Failure, Max Probe Time, ext? I cant seem to get this right. Thanks

 

[jamess88]

Hi, thanks for the info, I am also having the same problem. In my case, some times, the stream does not open at all. Then open quickly after changing channel and returning to the dark channel. The source is good. Are the above settings in conjunction with LLOD 2 or LLOD disabled? LLOD 3 should not use ffmpeg so I assume it does not apply. Also, will on demand probe size 3000000 cause streams to be delayed as compared to live?
I just tried the settings provided above and it makes the situation worse, at least for me it did not go well. The stream also fails multiple times while opening. Once the stream is up, uptime will be many hours
What settings do you use in general settings > streaming > Wait Timeout, Exit on Failure, Max Probe Time, ext? I cant seem to get this right. Thanks

Leave everything else default and LLOD disabled, keep in mind, this only works if your source is play, if your source is on demand then you’re sol unfortunately,

 

[julian]

Leave everything else default and LLOD disabled, keep in mind, this only works if your source is play, if your source is on demand then you’re sol unfortunately,

Hi. Sorry to ask. When you say ‘you’re sol unfortunately’, do you mean it’s not possible?
In my post I was referring to on demand, in live online streams, the problem does not occur.
I have found that when using streams on demand, setting the on demand probe to 1024000 solves the problem with streams not starting and consequently the player not streaming in 99% of cases. moreover, in general settings > streaming ‘stream failure sleep’ set to 1 or 2 instead of 20 (default) and fail before sleep to 5 instead of 3 (default). That way the panel permits more retries before wait time in case of stream failure, and wait time is shorter

 

[jamess88]

Hi. Sorry to ask. When you say ‘you’re sol unfortunately’, do you mean it’s not possible?
In my post I was referring to on demand, in live online streams, the problem does not occur.
I have found that when using streams on demand, setting the on demand probe to 1024000 solves the problem with streams not starting and consequently the player not streaming in 99% of cases. moreover, in general settings > streaming ‘stream failure sleep’ set to 1 or 2 instead of 20 (default) and fail before sleep to 5 instead of 3 (default). That way the panel permits more retries before wait time in case of stream failure, and wait time is shorter

Hello, if you read my reply you should understand that if the source is on demand, like your provider has streams set to on demand on their server, it takes some time to start it’s not instant, you can’t change prove size on your server to improve your source, they need to play on their end for it to be fast on your end ondemand

 

[julian]

Hello, if you read my reply you should understand that if the source is on demand, like your provider has streams set to on demand on their server, it takes some time to start it’s not instant, you can’t change prove size on your server to improve your source, they need to play on their end for it to be fast on your end ondemand

In this case the source is not using on demand, so it does not apply.

 

[Infest84]

i have seen this

Hello Everyone, i'm facing an issue with streams speed in xui one , channels on demand are too slow to play , the ffmpeg are intgreted in xui one and im not using any code but streams can take up to 1 min to show and the source is a live stream

is theres a setting that i should configure so that streams can show up faster please ?

Hello friend! Let’s go straight to the point so you can fix your issue without wasting time.


Your problem is caused by how your segments (chunks) are configured in XUI One.

​

When you start a live stream, the player usually waits for enough segments to buffer before starting playback. If the segments are too large, or the playlist is too big, it takes longer to collect enough data — that’s why you see up to 1 minute delay before playback starts.

​

The two most important settings for playback speed and latency are:

• Segment Duration (seg_time)
• Segment List Size (seg_list_size)

​

If your current segments are too large (e.g., 10 seconds each), the player waits longer to download them.
If your playlist (list size) is too large (e.g., 6 or more segments), the player might buffer too much before starting.

​

• Segment Duration: 2 seconds
• Segment List Size: 3 or 4

With this setup:

2 sec x 3 segments = ~6 seconds buffer


This gives you faster start time and still some buffer for stability.

​

You might also see a setting called seg_delete_threshold.
This controls how many old segments are kept on the server before being deleted.
It does not directly affect startup time, but helps avoid "segment not found" errors if clients fall behind.

​

• Lower segment duration to 2 sec.
• Lower segment list size to 3 or 4.
• Clients will start almost instantly (a few seconds only).
• You will reduce big delays without sacrificing stability.

​

If your network is unstable or your clients have very bad internet, you can increase the list size a bit (for example, 5) to add more buffer.

 

[julian]

i have seen this

Hello friend! Let’s go straight to the point so you can fix your issue without wasting time.


Your problem is caused by how your segments (chunks) are configured in XUI One.

​

When you start a live stream, the player usually waits for enough segments to buffer before starting playback. If the segments are too large, or the playlist is too big, it takes longer to collect enough data — that’s why you see up to 1 minute delay before playback starts.

​

The two most important settings for playback speed and latency are:

• Segment Duration (seg_time)
• Segment List Size (seg_list_size)

​

If your current segments are too large (e.g., 10 seconds each), the player waits longer to download them.
If your playlist (list size) is too large (e.g., 6 or more segments), the player might buffer too much before starting.

​

• Segment Duration: 2 seconds
• Segment List Size: 3 or 4

With this setup:

2 sec x 3 segments = ~6 seconds buffer


This gives you faster start time and still some buffer for stability.

​

You might also see a setting called seg_delete_threshold.
This controls how many old segments are kept on the server before being deleted.
It does not directly affect startup time, but helps avoid "segment not found" errors if clients fall behind.

​

• Lower segment duration to 2 sec.
• Lower segment list size to 3 or 4.
• Clients will start almost instantly (a few seconds only).
• You will reduce big delays without sacrificing stability.

​

If your network is unstable or your clients have very bad internet, you can increase the list size a bit (for example, 5) to add more buffer.

I would expect this is valid only if ingesting hls and makes no difference if ingesting ts