sc_trans - long delay when reloading new playlist

[glr]

Hi

I am new to SHOUTCast and I am turning to the community to find a solution to the following challenge:
I am streaming a default playlist and upon some trigger I would like to play another playlist (with one or two MP3 files) and then switch back to the default playlist. E.g. music is playing by default and then some voice starts playing and when it is finished the music would continue. (It does not matter where the music resumes playing.)

I have tried the following approaches:

1)
When the triggering condition happens, I changed the content of the playlist file and issued a SIGUSR1 signal to sc_trans to reload the updated playlist. The problem is that it takes more than 40 seconds for the new playlist to start playing. I can see from the sc_trans logs that it receives the signal, loads the updated playlist but it is still sending the music from the old playlist for some time and it is only after about 40 seconds that the "new file" is being sent to the server.

2)
I also tried to take advantage of a priority playlist. I set a default playlist with the music and when the triggering condition happens I copy the new playlist with the voices to the priority folder. Again, although sc_trans notices the priority playlist it takes more than 40 seconds for the priority playlist to take effect.

Can you explain to me what causes that delay and if it is possible to make it much shorter. Ideally, I would like that the new playlist starts immediately.

Thanks in advance,
Richard.

[clmiami]

It's been a problem literally for YEARS

This delay issue has been an ongoing problem literally for years.

Perhaps as long as 15 years.

I read a while back this delay was intentional, to provide some automatic cutover smoothing or something, so that the server could handle connect/disconnect issues, such as when your own server drops connection, and then reconnects.

I imagine this was done so that a series of rapid reconnects and disconnects from a crappy source (in your home or office) to the internet, wouldn't hammer a relay server - essentially forcing the reconnect process to take longer to ensure the reconnect is in fact stable.

I wish there was a way to set it for a shorter amount of time because it makes testing, as well as reconnection after an outage a major pain in the ass.