WebDriverAgent MJPEG Server Not Reconfigured/Restarted When appium:mjpegServerPort Changes #1046
Description
My specific use case involves managing multiple iOS devices (e.g., 5 devices) on a single machine. For these devices, the iproxy forwarding ports (and thus the appium:mjpegServerPort values) are often dynamic or random to avoid conflicts.
The current implementation appears to use appium:mjpegServerPort to dictate both the Appium-side iproxy forwarding port and the internal port on which WebDriverAgent listens for MJPEG streams on the device. When appium:mjpegServerPort is changed for a subsequent session (without a full WDA re-install/rebuild), WDA often continues to listen on the previous internal port, leading to a mismatch.
This disconnect causes iproxy errors (e.g., ECONNREFUSED) because iproxy attempts to connect to the newly specified port, but WebDriverAgent's MJPEG server is not listening there (or is still listening on the old port).
The root cause appears to be that the single appium:mjpegServerPort capability simultaneously dictates both the iproxy's local forwarding port and the internal listening port for the MJPEG server within WebDriverAgent on the device.
When this capability changes, WDA on the device does not seem to reliably reset its internal MJPEG server port to match the new value, especially when WDA is reused (e.g., via appium:noReset or appium:usePrebuiltWDA). This creates a mismatch where iproxy tries to connect to a port that WDA isn't listening on.
As a potential solution or a more flexible approach, consider introducing two distinct capabilities:
One for the iproxy's local forwarding port (the port Appium connects to).
Another for WebDriverAgent's internal MJPEG server listening port on the device.
This would allow iproxy to handle dynamic port assignments independently while WDA could reliably adhere to a potentially fixed or more stable internal port, or at least be explicitly managed. Alternatively, ensuring the MJPEG server is explicitly stopped, unbound from the old port, and cleanly restarted with the new configuration within WDA's lifecycle would resolve this.