Excessive delay before stream starts.

[Heyes]

I had a recent issue with an excessive (4 second) delay between 'play' and stream starting/restarting.

 

With my current host, there's almost no delay when initially playing - and restarting is instant.

 

For a new project, in wanting to develop a relationship with an additional provider, start/restart times were each 4-seconds.

 

Unable to get a definitive answer on 'why?' from them, and unwilling to accept 'this is normal' and 'try a different player', I've switched the project to my current host.

 

I'm keen though to get a better understanding of the cause of this... whether a user-configurable setting in Centova, or something set elsewhere to which I didn't have access.

Edited June 19, 2018 by Heyes

[djgary72]

Are there any buffer settings? You would need to lower the buffer from 4000ms to something more manageable (1000ms = 1 second)

 

If its not that then I'm not sure what to suggest.

[Heyes]

Are there any buffer settings? You would need to lower the buffer from 4000ms to something more manageable (1000ms = 1 second)

 

If its not that then I'm not sure what to suggest.

 

Thanks.

 

Your suggestion seems logical, but I'd no access to any such setting - and hence suspected it to be part of the 'something set elsewhere to which I didn't have access' stuff.

 

Although my knowledge of this is relatively small, I can't imagine why a provider would set such a high default. (Although a possible answer might be that 'they don't know enough' - for which potential evidence might be the 'that's normal' response I got from them.)

[BWorld]

Thanks.

 

Your suggestion seems logical, but I'd no access to any such setting - and hence suspected it to be part of the 'something set elsewhere to which I didn't have access' stuff.

 

Although my knowledge of this is relatively small, I can't imagine why a provider would set such a high default. (Although a possible answer might be that 'they don't know enough' - for which potential evidence might be the 'that's normal' response I got from them.)

 

Many providers using shared-type hosting or cheap servers will set the initial buffer high so that the client has 4-30 (I've seen settings of 30!) of buffer, so they can claim "buffer-free" service. In the end it is typically trying to account for crappy servers or bandwidth so the client's listeners don't complain.

 

Otherwise it wouldn't make much sense to set the buffer very high. Now on the other hand, if the provider is servicing customers that have very poor internet connections that can go in and out, this would potentially help by keeping a continuous stream as well.

[Heyes]

Many providers using shared-type hosting or cheap servers will set the initial buffer high so that the client has 4-30 (I've seen settings of 30!) of buffer, so they can claim "buffer-free" service. In the end it is typically trying to account for crappy servers or bandwidth so the client's listeners don't complain.

 

Otherwise it wouldn't make much sense to set the buffer very high. Now on the other hand, if the provider is servicing customers that have very poor internet connections that can go in and out, this would potentially help by keeping a continuous stream as well.

 

Thanks.

 

That all sounds sensible, and helps me to better understand.