(Login on the GitLab issue tracker is broken for me currently - "account has been blocked" - so I cannot report issues there at this time. Crosspost this there if you like.)
Currently, fallback files are sent potentially several times faster than the playback bitrate. This causes fallback-override to be very ineffective. Because you are sending the files faster than the client plays it back, its buffer gets fuller and fuller until it reaches its limit of what is potentially several minutes or hours worth of fallback file audio to play. When the client is moved back to the original mountpoint, they have to wait until they've played all of this extra fallback audio before reaching the live stream again which at that point will be very delayed compared to the the incoming stream.
Instead, the fallback files should be rate limited so that it only sends at most its playback bitrate every second. It may well be this bitrate has to be given in the form of a setting, but I feel this is an important issue to fix regardless. I'll be looking to see if there's any workaround in the meantime.
Bo98
commented
5 years ago
(Login on the GitLab issue tracker is broken for me currently - "account has been blocked" - so I cannot report issues there at this time. Crosspost this there if you like.)
Currently, fallback files are sent potentially several times faster than the playback bitrate. This causes fallback-override to be very ineffective. Because you are sending the files faster than the client plays it back, its buffer gets fuller and fuller until it reaches its limit of what is potentially several minutes or hours worth of fallback file audio to play. When the client is moved back to the original mountpoint, they have to wait until they've played all of this extra fallback audio before reaching the live stream again which at that point will be very delayed compared to the the incoming stream.
Instead, the fallback files should be rate limited so that it only sends at most its playback bitrate every second. It may well be this bitrate has to be given in the form of a setting, but I feel this is an important issue to fix regardless. I'll be looking to see if there's any workaround in the meantime.