Does audioplayer buffering state ever time out?

Apologies in advance, might be a bit long..
Does an audioplayer ever time-out if it's in buffering state for too long?
Also, if not, is there any negative effect if an audioplayer stays too long in buffering state? Memory leak or such?
I am working on a discord bot, that takes an opus/ogg stream as input, which comes from another certain older discord music bot that is capable of web streaming (not sure if I am allowed to mention it's name).
The stream is a response from an API call, which needs a stream token.
But my problem was, that the stream closes at certain actions, like stopping the playback manually or changing tracks via certain control buttons of the web UI. In this case, the audioplayer goes into idle state and the stream is considered ended, and cannot be resumed, a new token needs to be requested and a new call for a new stream made.
I got around this by watching the audioplayer state transition and when it goes from playing to idle, I make a new API call for a new stream.
I also play this new stream right away to account for if the stream ended between switching tracks, but this way, if the stream was stopped manually, I request a new one, it can still be played but will be basically playing nothing and the audioplayer stays in buffering state until the playback is not resumed again via the web UI.
So, question from the beginning: could there be any drawbacks from this?
Was this page helpful?