Sorry, Is there a tutorial for getting that?
I do understand that compiled code mostly gives you a mess of hex when things go wrong like that. It's likely the version regression not being done correctly or some other incompatibility on my part unless you get other reports.

TL;DR --- grr.
[rant] My frustration level is pretty high right now watching bortle 3 - 5,3,5 skies go by on my vacation and this ASI junk wont go. It's got to be something tied to autoguiding or some widget I'm doing wrong that has to be done a certain way for the asi cameras to work in tandem. This isn't a new problem.
I'm running out of clues. changed cables today with no change. Either one runs fine, but only the first one running. My next try is to change computers but that involves taking the entire power center apart and there isn't time tonight. If I get lucky and get stars again this week I'll give that a try. It's too late to even reconfigure for the K5. I'll just try to get a bunch of shorter exposures with the one camera tonight so maybe I'll have "something" to show for my efforts.
My skills are primarily in decades of industrial electronics, plc's and robotics, multiple computer systems, networking, dc drives ,temperature controllers used in extrusion, counters timers, hydraulic pneumatic and electronic instrumentation, HIM, touch screens, DC drives from the smallest bodine to 400hp 3 phase regenerative models..and somehow manage to keep a small business from eating itself, where I can anyway.
So I'm not much of a programmer, but I can usually read reasonably documented or named code and make changes. It's one reason I keep pestering you guys for help. My love for the opensource community is the other. I do outreach for indi all the time.
Ask me how to retrieve a lost password in an Allen Bradley SCL500, build you a film winder tensioner with an adjustable open loop max speed safety, or wrangle parts for a dozen blown AC drives and I'm your guy.
I can't even offer you a remote desktop connection since my country favors profit above all else and refuses to fix my phone lines enough to get any sort of bandwidth. [/rant]

Ray, that's an impressive CV, thank for sharing. So let me just say this. If INDI/Ekos are not working out for you and you're missing out on great dark skies, then just use any other solution for the time being. You can always check INDI/Ekos later, but you'd at least get all the data you need _now_. All your efforts in INDI are of course highly appreciated! I was going to suggest remote connection but now you mentioned bandwidth issues, well .. try to figure something out.

Thank you so much for the kind response, I was just like... but I can do so many things! Just not the one you want! Why are my problems always so hard!?
That's a very good point about having a plan B. I love this system though and nothing else I've tried works as well but some kind of back up plan is needed. Maybe I can do a VM with a known working version once I get things up so I can compare when I somehow find the ONE way to foul it up. Or maybe even set aside an rpi3 I can swap in. The Odroid uses the same supply voltage so it wouldn't bee too hard. I should have had that ready last night. using the one I have for the currently idle diy cg4/onstep rig. Sounds like a plan. You won't be rid of me that easily mwahaha
If I don't get things working by the next forecast clear night I'll put the k5 in place of the asi178 and test that. It was working I've been using my 150/f4 newt but I might try the k5 on the SCT for Galaxy hunting, which I've not done yet.

Thanks Jasem for lending the shoulder.

I've often told my coworkers I sometimes don't solve a really tough problem until I've lost it at least twice and declared it unrepairable at least once.
I Did some more testing, in daylight this time. Camera temps 29c in the shade tells the story. I'm hiding from my spring cleaning chores. Just not ready for summer heat.
I tried swapping camera jobs and found that the asi178mm consistently fails exposure status check and restart regardless of which job it's doing, but only if the other one is also running. ...wow.
I got a pretty good look at it in the log this time too - no extra telemetry mucking things up.
I wonder if this could be caused by a shared usb irq in the odroid. They are both plugged into the internal usb3 ports. [edit: No. I tried multiple port combinations.]
more research needed.

I just tested this setup _again_ on SM and it's working fine. The ONLY issue is that when the 178MM image is getting download, the guide frames are delayed by a bit, but then they resume normally.

I think I probably asked this before, but have you tried this on RPI3? or another hardware?

My rpi3 is going to need some config work before I can use it but I just got my big hp15 notebook to run everything and got the same issue. I also put the cameras on different ports and on a powered usb hub to rule out port conflicts. It's running stable release code but versions haven't made a difference, which would seem to indicate a hardware problem. On top of that the camera isn't given a reason code. It just counts normal, status updates count down okay with no fails, then camera reports exposure fail. "bzzt....try again." restarts count.
This is really weird. I would suspect the asi178 hardware or firmware but it runs fine as soon as I stop the other camera.
[edit: forgot to mention I defaulted the xml files]

I tried something interesting but even that didn't work. The indigo asi drivers have some interesting options we might want to peruse sometime. They also perform pretty snappy, but I still have the issue. This is a good one.
Cable noise? a ground loop? (Blueshawk faints)

Using a powered hub may not always be the answer. I was having a lot of problems running the Moonlite focuser and Celestron GPS drivers through a powered hub. When I switched to runing them connected directly to the Pi they were fine.
The only benefit of a powered hub is more power and a device that has an external power supply, so is not powered through the USB port, should take very little from the USB.

You can of course buy a USB splitter cable which enables direct powering of a USB device while still providing data signals - AND doesn't lower the USB bandwidth which an external USB hub does - ok maybe on USB3 depending on how speed hungry the device(s) are.

The only problem is there arn't many outlets that sell such cables but you can build your own

www.msdist.co.uk/mikrotik/power-supplies/5v-usb-injector

@Stash: Thanks for the input but this is unrelated to the current camera frame drop problem.
All input is appreciated though!

I only moved cameras to the powered hub temporarily to rule out a possible power issue at the onboard ports. The hub(powered usb3) is normally plugged into the Odroid's one usb2 port and services all the low priority devices, leaving the 2 usb3 ports for the two (normally) high speed cameras. Also, I don't encounter this problem when using a dslr and the 120 for guiding, despite even having had the k5 plugged into the powered hub in the past. The pentax k5 is usb2 anyway.
I also replaced the odroid with an HP notebook with a similar port setup and still have the problem.

Future testing hypotheses:

• Does it do it with a dslr and asi178? Not an arrangement I'd normally use but that might isolate the issue to that one camera at least.
• Does replacing the Odroid with an Rpi3 and plugging cams direct to the two internal ports make a difference? DINGDINGDING!

I set up a pi over the last couple days as I got time. My previous OS sdcard got repurposed somewhere along the way so I had to start from scratch. I think I'll make a full backup image this time. yeesh!
Great success! --but why?
For some reason the cameras ran both ran looped for at least an hour without a hiccup on a bone stock rpi3b running raspian lite and indi nightly downloaded from the url for raspian(no repos).

Considering this is its ONE job. I guess I could just put the pi in the box and use the odroid for a completely separate high speed system for planetary. This does not however explain what the heck is causing this problem, which I find sporadic reports of in forums indi, and git. Both are arm type processors, pi3b is arm7 and odroid arm8(I think). Tthe only big difference in the system is the usb3 ports on the Odroid-xu4, which does not have 2 usb2 ports internal, making any usb2 tests rn through the external hub, an arrangement which has its own set of problems.

@knro if you can think of something we can do to isolate this better I'm game to try. This could help lots more people who have had to work around this problem over the last few years. I noticed one in issue in git from last year that fizzled. I hate leaving stuff hang like that, and those who do get ugly looks from me...though I do understand life happens.