[Marijn0]

Fixes an issue where /picture/<id>/current did not return JPEG images when no frame was available yet.

The retry logic previously used IOLoop.add_timeout(), which scheduled a retry but immediately closed the HTTP request.
As a result, the client could receive a response with Content-Type: image/jpeg but an empty body.

The retry now runs within the same request using an awaited sleep, keeping the request open while waiting for the first JPEG frame from the internal MJPEG client, up to the intended retry limit.

This behavior matches the existing comment in the code, and I think it reflects the intended behavior?:

motioneye/motioneye/handlers/picture.py

Lines 114 to 116 in 4f1b7b5

	# picture is not available usually when the corresponding internal mjpeg client has been closed;
	# get_current_picture() will make sure to start a client, but a jpeg frame is not available right away;
	# wait at most 5 seconds and retry every 200 ms.

#2978

[MichaIng]

This looks like an elegant solution, many thanks.

Do you have a set of settings or timing to replicate the issue with an empty response? Keeping the request open seems benefitial in any case, but replicating the exact issue with some added debug output might be a good learning, and probably the same affects other part of the code.

[Marijn0]

Do you have a set of settings or timing to replicate the issue with an empty response?

Yes, of course, this can be replicated by:

• Closing all connections to the motionEye server.

• Waiting 10 seconds (or the number of seconds set in motioneye.conf here) for the mjpg client to close.

• Request a snapshot using: curl -i http://127.0.0.1:8765/picture/1/current, and check the content-length.
  (this should now be 0)

• Try again within 10 seconds and check the content-length again.
  (this returns a valid JPEG because the mjpg client was started by the first request).

Keeping the request open seems benefitial in any case, but replicating the exact issue with some added debug output might be a good learning, and probably the same affects other part of the code.

As far as I can see, this only affects /picture/<id>/current, since it relies on retrying while waiting for a frame to become available, and I did not find other handlers using this same retry pattern

Maybe we could add an HTTP error when no picture is available? For example:

raise HTTPError(503, f'Failed to get current picture for camera {camera_id}: no frame available',)

[MichaIng]

Works perfectly. A curl to the API in case also takes a little longer if no image is available yet (the retry loop), so one can "feel" in action what is going on 👍.