I have INDI library: 1.9.0 running as a server on a Linux Mint PC and I run kstars/Ekos from another connecting to the server via 5GHz wi-fi.
I have 2 ZWO cameras, a 120MC-S for guiding and 294MC. Both cameras stream from from the INDI control panel in Ekos when connected individually but the 120MC-S always freezes when the 2 cameras are connected at the same time. They have their own USB 3 connections to the server. I tried using USB 2 for the 120 and also connecting via the 294 but with the same result.
I have had a few problems with the 120MC-S outside of INDI, it does tend to behave a bit erratically sometimes so I do wonder if it's a problem with the camera. It's certainly less reliable than the 294. Both cameras are new so I don't think it's a firmware issue. I the only update fw for the 120 seems to suggest it's only for USB 2.
It probably doesn't matter too much because I tend to use a local capture app running on the INDI server for the imaging but wondered if there's an easy fix/workaround. The streaming is quite useful when setting up the telescope.
Once possibility is that one driver controls the two cameras, so one camera could be saturating the channel making the other camera unable to stream reliably. However, most of these operations are actually asycnhronous as well.
Just to close this thread off. I spent about a week working with ZWO support trying to diagnose this issue but it wasn't resolved. In the meantime I bought myself an ASIAir pro, mainly because I liked the look of the case. I did consider StellarMate but because it uses the indi_asi_ccd driver it was unlikely to work for me. Although the ASIAir does use indiserver, it doesn't use it for imaging so the 2 camera problem isn't present. Maybe a solution for INDI would be to have 2 separate drivers, one for the guider and one for the imager, this is what ASIAir does.
Just as an aside, you can use Kstars to move the mount with ASIAir because it is using indi_eqmod_telescope.
I have the exact same problem with my two ASI cams for several weeks now. In my case it's a 294/294Pro combination. The main cam streams ok but streaming from the guide cam freezes the driver and lsusb doesn't show any ASI cam anymore. No other possibility than to reboot then. While streaming from the guide cam the main come does absolutely nothing so traffic from the main cam does not cause the guide cam to fail.
ZWO were suggesting it was a USB bandwidth problem but USB 3 is pretty fast and even having the cameras on different busses, the imager on USB3 and the guider on USB2 didn't help.
I also had instances when the guide camera would stop working completely and only a disconnect/reconnect would make it work again.
The debugging from the indiserver is a bit confusing, plus the information is being truncated making it hard to understand what's going on. The ASI ccd driver debug is a bit clearer - you enable it by modifying the ~/.ZWO/ASIconfig.xml file to set <DebugPrint type="3">01</DebugPrint> and the log file is in ~/.ZWO/asicamerasdk/asicamerasdk.log
Here's an excerpt
2021-07-15 21:22:30,997: INFO ASICamera : [WorkingFunc]: head:0xaa11 tail:0xf200
2021-07-15 21:22:30,997: INFO ASICamera : [WorkingFunc]: drop frames:4
2021-07-15 21:22:31,048: INFO ASICamera : [AutoExpGain]: Dest:100 Mean:1 gain:50 exp:95000 reg:0x43a
2021-07-15 21:22:31,152: INFO ASICamera : [AutoExpGain]: Dest:100 Mean:1 gain:50 exp:95000 reg:0x43a
2021-07-15 21:22:31,231: INFO ASICamera : [WorkingFunc]: head:0xaa11 tail:0xf200
2021-07-15 21:22:31,232: INFO ASICamera : [WorkingFunc]: drop frames:5
2021-07-15 21:22:31,232: INFO ASICamera : [WorkingFunc]: try lowing pkg!!
A single camera can for sure stream fine. So if there is an issue, it is probably related to a specific model and/or platform. Sometimes reducing USB bandwidth helps.. perhaps because it makes it slower so less frames are getting dropped. But I failed to stream from BOTH cameras at the same time. Need to investigate that again.
I can confirm this is a ZWO SDK issue. ASIGetVideoData always times out when two cameras are connected when one camera is already streaming. Looks like some limitation of the SDK. Probably the only solution this is to have a single camera per executable.