'Busy' is too vague

[lee-b]

I cannot at all seem to use my Sony A7 II with indigo. Any attempt to connect to it directly, or connect other indigo agents (such as the imager agent) to it just refuses, saying that the device is 'busy', but no indi/indigo/alpaca clients are running.

Weirdly, my onstep mount (juwei 17) is reported as having a focuser(??) and I CAN configure that with the imaging agent, so it's at least capable of connecting SOME things, but the Sony... no. And there's no indication in the UX as to why.

This seems to be a common problem that people report, so I guess I'm really saying, whatever can make the device "busy" (i.e., lock/reserve it for use, or at least at low level instigate some long-running operation) should also log the reason why it is going to be / is busy, and 'busy' should be reported, not as a simple error flag, but as 'busy: doing X right now instead'. or ideally, 'busy: doing step x of y for client z right now, ETA: hh:mm:ss:microsecs' or something.

[lee-b]

I guess a better architecture would be if you could actually go in somewhere and see the current task queue, much like a print queue, and see what it's doing, why it's busy, when the job started, how long it's been running for, whether it's stuck, and so on.

In the meantime, is this is well understood issue? What's the best way to determine what's keeping it "busy"?

[polakovic]

I cannot at all seem to use my Sony A7 II with indigo. Any attempt to connect to it directly, or connect other indigo agents (such as the imager agent) to it just refuses, saying that the device is 'busy', but no indi/indigo/alpaca clients are running.

This seems to be a common problem that people report, so I guess I'm really saying, whatever can make the device "busy" (i.e., lock/reserve it for use, or at least at low level instigate some long-running operation) should also log the reason why it is going to be / is busy, and 'busy' should be reported, not as a simple error flag, but as 'busy: doing X right now instead'. or ideally, 'busy: doing step x of y for client z right now, ETA: hh:mm:ss:microsecs' or something.

If the camera reports just it is busy or the communication stalled, there is nothing more we can do and no more info we can show, it is on USB or camera protocol level. It may be camera misconfiguration or other application uses it (e.g. any Image Capture API based application if you're using macOS) or anything else.

You can try to set log level to TRACE to see the communication with the camera and maybe it will show something useful.

Weirdly, my onstep mount (juwei 17) is reported as having a focuser(??) and I CAN configure that with the imaging agent, so it's at least capable of connecting SOME things, but the Sony... no. And there's no indication in the UX as to why.

The reason is, that onstep doesn't report it doesn't have focuser until you try to use it and even then it reports just failure without any explanation :)

[lee-b]

Hmm. I see, thanks. I guess I might be stuck with having to manually reset this camera sometimes; will experiment.

Though, just for the sake of discussion/clarity... at least IDEALLY... doesn't the following mean that indigo is solely operating this device, and therefore indigo should know/track/manage its state, and report ERRORs (rather than Busy) if it's in the wrong state for too long, when it hasn't been tasked with anything that takes a long time?

# lsusb -s 1:3
Bus 001 Device 003: ID 054c:0a6a Sony Corp. ILCE-7M2

# lsof +c 15 /dev/bus/usb/001/003 
COMMAND        PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
indigo_worker 1310 indigo   25u   CHR  189,2      0t0  318 /dev/bus/usb/001/003

# ls -l /dev/bus/usb/001/003
crw-rw-r-- 1 root plugdev 189, 2 Dec 11 12:03 /dev/bus/usb/001/003

# groups indigo | tr ' ' '\n' | grep plugdev
plugdev

[polakovic]

The first problem is, that INDIGO PTP driver uses different backends depending on platform. In your case (linux) it is libusb and on e.g. macOS it is passthrough PTP channel on ImageCapture API. The driver doesn't have any control over low level device state (I mean USB level on Linux and PTP-over-USB level on macOS).

The second one and probably more important is, that firmware of the camera is really a piece of shit. It simply freezes in many situations and all you can do is to turn it off and on again (or to remove and insert the battery). In the rare situations when the underlying backend reports something sensible it is handled and reported to client, but this is probably not the case. So the driver doesn't have any control over hight level camera state.

BTW, PTP standard is not fully implemented by Sony, the extensions are undocumented, every Sony camera and maybe every firmware version has different bugs and quirks :)