▲

[Ian @ un4seen]

It's quite interesting because I have another encoder which is logging the audio to files of 60 minutes each. Whenever the length of the logged audio is less than 59:59 then it's a sign something went wrong. This encoder has always had the QUEUE flag set, but I realise this means nothing with regard to the encoder which is being used for casting.

Are you using BASS_Encode_StopEx with queue=true to end those encodings? If not, that could explain them being slightly short, because BASS_Encode_Stop won't process any data waiting in the queue before stopping.

[Chris Oakley]

Are you using BASS_Encode_StopEx with queue=true to end those encodings? If not, that could explain them being slightly short, because BASS_Encode_Stop won't process any data waiting in the queue before stopping.

No I'm not using that. I'm just using:

Code SelectExpand

BassEnc.BASS_Encode_Stop(_LogEncoder)
That may explain why sometimes the length is 1:00:00 and other times it's 59:59.

I doubt this will be responsible for a length of 59:52 though.

[Chris Oakley]

I've been monitoring the malfunctioning machines over the past 10 days and so far they are all now working as expected.

This is leading me to believe the problem was exactly what we managed to pull out of this and the QUEUE flag on the encoder that was being cast has solved the issue.

One of the biggest offending machines had really bad jitter on the upstream of their internet connection. I did some ping testing and tracerouting and it was getting ping times of over 500ms and the same on some of the trace route hops. After rebooting their router this now seems to have cleared.

They wouldn't have stream disconnections, so you wouldn't think to look at the internet. After all, my thinking was, how can bad internet cause an issue with audio playback, but that TIMEOUT sending the meta to the IceCast stream when they were having issues was what lead me to look into it.

I'm going to continue to monitor.