Closed marc-portier closed 3 months ago
I added an issue so that we can fix this for real in the future, however this will require some re-architecting so it will take some time.
In the meantime I think adding a special case for the announcement makes sense, To make this easy to use one options would be to have the announcement's timeout default to something like 10 or 15 seconds. Another would be to fail with a useful message to set/increase the timeout.
The HTTP-POST call to
/announce
waits for the actual mp3 to be played before the HTTP response is returned. For (not even that) lengthy announcements this easily conflicts with the standard 10s timeout baked into thepyampli.client.Client
As things are one either needs to:
Both options have their drawbacks which could be overcome by
timeout=«custom for this call only»
into thepyamplipi.ampllipi.Amplipi.announce()
pyamplipi.client.Client.post()
If this sounds like a reasonable approach, I can provide the PR While at it we might consider having this kind of call-basis-override possibility for other functions too? (Although I do not know if any other calls have a similar lengthy wait for the response?)
Finally. Note that there is somewhat of an opportunity for @micro-nova to reconsider this synchronous wait behavior for the
/announce
service: Another approach, with a more web-like prompt response, would be to have an immediate response using an202 Accepted
- possibly accompanied with aLocation:
pointing to a resource that reports on the progress and eventual completion of the announcement being played. This however is outside the realm of this python client-library.