-
-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
request.dynamic
invoked when not expected
#3134
Comments
request.dynamic
invoked when not expected
I would like to bump this issue with a new reproduction and my explanation of the problem. SummaryIf the number of requests in Reproductiont = ref(true)
def next()
print("Next called #{time.up()}")
if t() then
t := false
request.create("/tmp/test/music/1.mp3")
else
null()
end
end
q = request.dynamic(next, retry_delay=10.)
output.dummy(q, fallible=true) Expected behaviorLog
Current behaviorLog
Version
Install methodsavonet/liquidsoap:v2.2.4 |
This is still an issue in 2.2.5 and 2.3.x rolling. It appears to happen after the first successful request starts playing. If prefetch can't successfully queue up the next request, the function continues to be called repeatedly. In fact, I ran the summarized version above (thanks @vitoyucepi) and it looks like it's running on every frame (0.02s in 2.3.x):
And every 0.04s in 2.2.5:
Notes:
lastTime = ref(0.)
...
def next()
rid = ref(null())
currentTime = time()
elapsedSeconds = currentTime - lastTime()
if (elapsedSeconds > 5) then
lastTime.set(currentTime)
...
r = request.create(...)
rid.set(r)
end
rid()
end |
The old frame interval is 0.04, the new one is 0.02. So liquidsoap tries to get a new request every frame. |
Describe the bug
Requests are being made when they shouldn't need to be during bad / error states. Related to #3026.
To Reproduce
Test script:
Expected behavior
Case 1
State: tcp endpoint down, no script changes, test mp3 file available
Expected behaviour: get_request should only be called when required, ie pre-fetch or the previous one is finishing, vs on error - only a reconnection should be happening on failure and not also a get_request. Streaming should just resume on the reconnected output once it becomes available if the request has already been made and is playing on the other output, ie dummy.
Log:
Case 2
State: output.external commented out, test mp3 filename changed to non-existent one / bad uri
Expected behaviour: get_request should be throttled to the retry_delay value, in the script's case - 5 seconds.
Log:
Version details
Install method
Official docker images
The text was updated successfully, but these errors were encountered: