You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue is this. Imagine a pool of asynchronous tasks each submitting unrelated MPD commands. The pool grows as new tasks come in. I know MPD is a serial protocol so the main (library) mpd task linearizes the requests, but otherwise the tasks are independent. Now for whatever reason the client is disconnected, so let's follow the queue of MPD commands.
The first few commands interrupted mid-response will raise ProtocolError and be retried, bumped to the end of the queue.
The next commands will have no response and raise ConnectionError. They'll await a new connection and then retry the command, bumped to the end of the queue. The point is that for each disconnected command beyond the first I'll be making a redundant reconnection.
Then we get to the commands issued after the first successful re-connection. They'd have been successful if I hadn't reconnected again. Perhaps they'll work, or perhaps they'll raise a ProtocolError, but worst-case-scenario they raise ConnectionError and trigger another re-connection. It'll be an avalanche of connection errors.
The main mpd task needs to track the connection state to prevent unnecessary connections. I really hope I'm wrong and that there's a better way to do this, but right now I'm tracking the time I submit each MPD command and each time I reconnect to reconstitute the current connection state. But please - correct me if there's a better way.
The
connected
property is rather meaningless. There's no rhyme or reason to its value. Test output, and test program:The text was updated successfully, but these errors were encountered: