I wanted to wait for clear sky and restest with nightly before asking for help. After reinstalling my asi178mm I now have an error where one camera will fail to download if the other is busy. I.E if the asi120-s is guiding, the asi178 counts to 0 and retries. log shows timeout even though no downloading time.

[2019-04-02T21:05:05.030 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI120MC-S : "[DEBUG] Upload complete "
[2019-04-02T21:05:05.048 EDT INFO ][ org.kde.kstars.fits] - Loading FITS file "/tmp/fitst15270.fits"
[2019-04-02T21:05:05.184 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI120MC-S : "[DEBUG] StartExposure->setexp : 2.000s "
[2019-04-02T21:05:07.447 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI120MC-S : "[DEBUG] Uploading file. Ext: fits, Size: 1235520, sendImage? Yes, saveImage? No "
[2019-04-02T21:05:07.506 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI120MC-S : "[DEBUG] BLOB transfer took 0.0450163 seconds "
[2019-04-02T21:05:07.507 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI120MC-S : "[DEBUG] Upload complete "
[2019-04-02T21:05:07.526 EDT INFO ][ org.kde.kstars.fits] - Loading FITS file "/tmp/fitsq15270.fits"
[2019-04-02T21:05:07.611 EDT INFO ][ org.kde.kstars.ekos.guide] - "Failed to find any suitable guide stars. Aborting..."
[2019-04-02T21:05:09.449 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI178MM : "[DEBUG] ASIGetExpStatus failed. Restarting exposure... "
[2019-04-02T21:05:09.550 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI178MM : "[DEBUG] StartExposure->setexp : 4.103s "
[2019-04-02T21:05:09.551 EDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI178MM : "[INFO] Taking a 4.103 seconds frame... "
[2019-04-02T21:05:13.847 EDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI178MM : "[INFO] Exposure done, downloading image... "
[2019-04-02T21:05:13.869 EDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI178MM : "[INFO] Download complete. "
[2019-04-02T21:05:13.966 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI178MM : "[DEBUG] Uploading file. Ext: fits, Size: 12885120, sendImage? Yes, saveImage? No "
[2019-04-02T21:05:14.233 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI178MM : "[DEBUG] BLOB transfer took 0.210128 seconds "
[2019-04-02T21:05:14.234 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI178MM : "[DEBUG] Upload complete "
[2019-04-02T21:05:14.426 EDT INFO ][ org.kde.kstars.fits] - Loading FITS file "/tmp/fitsp15270.fits"
[2019-04-02T21:05:14.478 EDT INFO ][ org.kde.kstars.ekos.focus] - "Image received."
[2019-04-02T21:05:14.743 EDT DEBG ][ org.kde.kstars.ekos.focus] - Focus newFITS # 1 : Current HFR 2.69565
[2019-04-02T21:05:14.757 EDT INFO ][ org.kde.kstars.fits] - Saved FITS file: "/home/hawk/.local/share/kstars/autofocus/2019-04-02/autofocus_frame_21-05-14.fits"

2019-04-02T23:16:46 Exposure timeout. Restarting exposure...
2019-04-02T23:13:15 Capturing 30.000-second lum image...
2019-04-02T23:13:15 Restarting capture attempt #1
2019-04-02T23:13:15 Capture failed. Check INDI Control Panel for details.
2019-04-02T23:13:15 Capturing 30.000-second lum image...
2019-04-02T23:13:15 Job requires 30.000-second lum images, has 3/20 frames captured and will be processed.
2019-04-02T23:12:46 CCD capture aborted
2019-04-02T23:12:39 Capturing 30.000-second lum image...
2019-04-02T23:12:39 Received image 3 out of 20.
2019-04-02T23:11:35 Capturing 30.000-second lum image...

random fails from both cameras. this system worked 2 weeks ago with the asi120-s and a pentax k5. something is still messed up with the asi driver.

Htop shows two asi threads, which seems right. Low CPU usage, bandwidth is only 120kb to the client end in the house pc.

In other BUG splatters. Restarting everything now leaves a usb port hanging locked, locking out the filter wheel requiring a reboot of the server.

To reproduce, guide with one camera and try to expose with the other..then to resume, stop guiding. The same can be done the other way around independent of which camera is shooting.
I added the K5 piggybacked and can manually trigger by entering an exposure time from the control panel while this is going on and get photos. It's not a bandwidth problem.

Last one tonight.
Considering a power/load issue, I tried moving the usb cables from the built in ports on the odroid-xu4 to a powered usb3 hub and updated the software again. The asi178mm failed to download on the second exposure in plate solving. Guiding was not running.

So I have the exact two cameras and as you can see in the video, I don't have this issue (both cameras running in StellarMate). Is there a way to trigger it? I was testing indoors at day.

HI! Thanks for checking this for me. I can hear you saying "What has he done now!?" lol
It's doing it from the time I first start guiding. I can even stop the asi120 and the asi178 will finish the shot it's working on and download it. Since you aren't seeing it and I had the problem before updating to nightly I now feel it's going to be some weird hardware problem. (this cut my problem in half!)
Other clues to apply:
- I do have an st4 cable plugged from the asi120 to the mount and have been trying to figure out how that stuff works which seems unrelated but is on my list to rule out by subtraction.(noise etc.) I tried both destinations -asi120 and eq6 in the guide module with no change. --lets just remove that for now as off topic.

- I had a bad cable not communicating and recently replaced it, right when I changed setups. - I'll try to get another today and replace the other old one just in case.

- I usually have both cameras plugged into the internal usb3 hub on the odroid. I did try plugging them into the powered hub just before shutdown but realized the hub was plugged into the usb2 port. I didn't have energy left to fix that so it's on my troubleshooting list for tonight.

- I compiled an older version of indi-asi and still had the trouble.
The pentax k5 I had piggybacked worked throughout, but I removed it from indiserver just to make sure it wasn't causing the problem. The camera was still plugged in though. Also on my list to be ruled out(noise from the supply getting to usb lines?)

Still troubleshooting as time allows.
I mildly suspect the powered hub may be playing a role but it is only plugged into usb2 items. A backfeeding regulator can cause serious havoc and is absurdly common these days.
I unplugged the pentax 120v power supply to remove that as a noise source.
I swapped cables between cameras with no change in symptom. One exposure and then restarting of the 178, timeout with no apparent delay.

Not sure if this is a related problem but it doesn't seem normal and imo could be destabilizing. dmesg shows the port being reset for every exposure.
edit:[it's related. A failed exposure in the guide scope showed as usb3]
i.imgur.com/ir08QdA.png

I wonder if some setting may be different that is causing my problem. I'll upload my xml files. The asi120-s refuses to let me change bandwidth. Also, the driver reports that auto bandwidth is being turned on regardless of checkbox setting.
Reconnecting this camera cleared the error and allowed me to set bandwidth so maybe it is related after all. Something left it broken but online?
I reset both camera modules to default xml. Then Kstars crashed to desktop. It had been pretty stable lately. Might be because I'm using nightly?

[18136.585209] Thread (pooled)[623]: segfault at 2afd50 ip 000056515c36d828 sp 00007f2eaa7fbc90 error 4 in kstars[56515c115000+aa0000]
[18136.585240] Code: 00 00 48 89 44 24 08 31 c0 39 ce 48 8b 47 30 73 71 66 0f ef c9 89 f6 83 c2 02 66 0f ef c0 48 01 c6 b9 02 00 00 00 0f 1f 40 00 <0f> b6 06 66 0f ef d2 66 0f ef db 48 83 c6 01 f2 0f 2a d0 89 c8 f2

Next session i'll only run the cameras unpluggine everything else to help isolate logs in hope of spotting new clues. This will also rule out that powered hub.

Next clear night the Pentax goes back on there so I can actually do some galaxy hunting(with heavy cropping) but I want this fixed. I might also try to test both cameras with alternative programs to see how things fair hardwarewise. The cross comparison may give up some clues.

The K5 was plugged into the usb2 hub. I tried moving the asi120 guide camera to the usb2 hub and leaving the asi178 on usb3 but will need more testing due to a lack of anything to guide on. I may also try the other way around but i'd rather have the high speed on the asi178 for upcoming planetary attempts.

Well that didn't work. I tried putting the asi120-s on a usb2 port along with the other controls and put only the asi178mm on the usb3 port. It worked swell in focusing and I even ran it in continuous mode for a while. I then used it to plate solve and align to M87 and started the asi120 to guiding through the mount driver. The asi178 stopped working when I went back to check framing. same timeout as before. It's just bizarre that a higher resolution DSLR with an old usb2 connection would be working better than the paired asi cameras. There must be a clue somewhere. I even put a new cable on the asi178 to rule that out. driver interaction?

I guess it's time to regress driver versions. This worked well last summer before I got the k5.

I'm going to start calling Kstars Kskylab for all the segfault crashes.
This time I saw it in my system monitor and got a copy:
I had just gotten the asi120 driver to turn off the autobandwidth by disconnecting , reconnecting and as first action unchecking the auto box, then changing 40 to 46 to verify it worked. Previous to this it refused to disable auto bandwidth with an error 16
then crash to desktop. this is with Kstars from Build: 2019-04-14T19:19:24Z and indi-asi compiled from an older stable version on the remote server.
and again when I tried to restart looks the same, happened soon after connecting and checking bandwidth:
<code> Thread (pooled)[16456]: segfault at 2 ip 00007f94e5b5400c sp 00007f94858692b0 error 4 in libQt5Core.so.5.9.5[7f94e5a2f000+53b000]
[246681.199683] Code: e9 29 fe ff ff 90 0f 1f 84 00 00 00 00 00 55 53 48 89 f5 48 89 fb 48 83 ec 08 48 8b 16 8b 02 83 c0 01 83 f8 01 77 3f 48 8b 03 <8b> 10 85 d2 74 1e 83 fa ff 74 06 f0 83 28 01 74 13 48 8b 45 00 48 </code>

Can you post the full backtrace? The Qt crashes are troublesome to investigate. Maybe a side-effect all the multi-threading code we are using.