Thanks for your responses Eric and Brian
I havent been using guiding Eric so it does not appear to be related to that but good thought.
Looks pretty similar to your issue Brian but I am not using USB3 ! I can go through a whole imaging session with hundreds of downloads and it behaves properly . However something can trigger it into the pattern of not downloading and the only way I have discovered to reset it is to close Kstars/Ekos down and start again ! Its almost like Ekos does not trigger the download and carries on through the sequence straight away. When in this mode it does not count a valid image though so it does not actually progress through the imaging sequence and eventually aborts.
I will check next time to see if there is any evidence in the log files..........

YEP - me too. using a PI as a server. (so USB2). I'm using 1600MMpro (3.0) camera. I typically plug guide cam and EFW into the 1600's hub.

YES, it can work perfect then just (I call it goes to lunch). It says downloading but doesn't. A time out happens and the exposure starts again and it's stuck in a loop.
YES - I have to do the same, kill processes and restart Kstars to get my camera back. I have not mentioned it because I assumed it was a hiccup in my WIFI.
My shots are taken in the dome. 100 yards from the house. They are sent to the PI. I then have them wifi to my desktop in the house. I assumed this image
transfer was messing up. (Wifi isn't that stable when referring to hundreds of files). I suppose a test for me would be to switch to storing subs to a local HD
on the PI's USB port. (local) rather than shooting them into the house? I've had other issues (guiding) that are taking priority so I haven't gotten into tracking
that issue down yet. I assumed it was a network transfer issue. Are you doing the same?

KStars in the house on windows. (talking wifi) to the PI in the dome on a mesh router. So the camera has to dump to PI while PI and mesh router has to send the sub to the primary router and desktop from the primary router. And yes - it never seems to recover by itself without restarting the applications.

I've fixed my problem, fingers still crossed though. I've been Googling for answers and came across this thread on CN:
www.cloudynights.com/topic/546906-asi160...lots-of-hangs/page-2
Post #43 talks about not being a good idea to have too many usb devices sharing busses, especially those usb keyboard/mouse keys which cause a lot of traffic. I use one of those occasionally and when I'm inside off loading images I always use it which is why all the inside testing I've done the last few days have been failures, I was getting 30-35 images at best before the dreaded looping began. After pulling the key and using my Galaxy Tab2 tablet to control the sbc, not one hiccup. I just finished 2x100 image test runs and no problem.
Other people in this thread sound like their looping is more infrequent and irregular than I was getting so probably not a solution but maybe this will help someone.

Hi Ron
Thanks for your response.
I have used a Pi connected over WiFi and powerline terminal kit but have always downloaded the images to a local USB stick. I found transferring it over the network to be to unreliable. I now use a Laptop running Ubuntu and KStars as my remote device instead of the Pi as I found the Pi to be a little but underpowered for reliable imaging runs ! I found that KStars would close unexpectedly for no obvious reason. The laptop is a lot better but I still download the images locally. I have experienced the missing download state with the two systems and as I download locally it cant be due to network transfer issues. The two systems use different drivers as well. I often wonder about the reliability of the ZWO 's hub as I also plug the guide camera and filter wheel into the hub and have found the guide camera has difficulty connecting to Ekos sometimes which was fixed by a direct connection to the latptop. I have an earlier version of the 1600 and there were some initial issues with downloading due to the use of too high a USB speed. I experienced this with APT and needed to lower the USB speed to the minimum setting to make it reliable. However the pro version implemented buffering to overcome this. I guess its always difficult to establish where the issue is when it involves the interface between two devices - is it hardware or software and which bit of software ! I guess it may be worth raising the problem on the ZWO forum to see if they are aware of it .

Just read your response Brian - thanks. Im beginning to think that the ZWO hub struggles with the filter wheel, guide camera and trying to download a large image file. I guess the guide camera consumes the most bandwidth under normal operation so it might be that the bus hangs sometimes when a download is initiated at a specific part of the cycle and causes the download issue. I am now connecting my guide camera directly to my laptop so the camera will have practically all the bandwidth for download as the filter wheel only consumes bandwidth when changing the filter. As this happens when using the PI and also with a laptop it is more likely to be at the ZWO end . I think the Pi bus may be a bit flaky but the laptop internal USB bus should be fairly reliable.

I will keep it under monitor now I have made this change - hopefully the problem will go away !

My 1600MMPro and 071MCPro both have this issue and there is no fix for me yet. I have tried plugging directly into two different computers and I get the same response. I tried removing any USB2 peripherals from the camera hubs, I tried different USB hubs, different USB cables, restarting kstars, restarting the computers, disconnecting and reconnecting cameras and different versions of kstars. No luck with any of them. When I connect either camera into ZWO's ASICAP or NINA on windows everything works fine as usual. Something in the communication between EKOS and the ASI cameras is stuck in some loop. I have not tried reinstalling kstars yet.

The downloading loop hasn't been a major problem yet since I'm still in testing and setup stages and I've yet to actually try to do a acquisition of a target other than 3-4 test subs. I might see it every other nightly test. But when I try to setup and go to bed - that will be a serious issue.

I have discovered the 1600 hub to be less than ideal. (but it's so dang convenient). my other option would be a bit longer cables up to the mount where I have a powered 3.0 hub. (but it's fully loaded 7 ports presently.).

Important to add. I HAVE HAD HIS WITH SGP. (rare) but it was there. So is it a Ekos issue as suggested above? (probably not).

While the downloading loop hasn't bothered me enough during testing stages - the CRASHES have. And I never considered the two issues to be related. Though I did have one test night 4 hours or so without a single crash. But thinking back - I think that was the night I recorded and I was primarily working on guiding problems and it could be I didn't do primary camera download during guiding that night.

Again I'm not to that point yet as I'm still learning the software and trying to get the last piece of the puzzle (guiding) working to my desired specs. I did just swap out the 6" APO with a RASA which will be a bit more forgiving to guiding error levels. I know I should circumvent the ASI hub that's down the road. And I know I'm pushing the limit with subs going through the network. (ESPECIALLY with my IP camera that's quite a bandwidth hog).

It's nice to know people are trying to track down the problems!

I forgot to add that I am not guiding at all with this setup. The issue is such that I can not use the program at all. It will not download even one sub. It never did it with the 1600 until the continuous loop started happening with the 071, now it is stuck this way for both cameras. Very disappointing. I had to downgrade to 2.9.8 to get the sesto senso to operate, I can't use the QHY filter wheel at all and now the cameras don't download at all. Even for platesolves or focusing.

As soon as I plug the cameras into the NUC via NINA or ASICAP or directly connect them to my Macs with ASICAP they work fine. They work fine via hubs and with filter wheel and guiders plugged into the camera USB hubs.

Hmmmm since you seem to have it repeating like clockwork. I wonder what would happen if you put a delay between sub captures. It would be interesting to see a 5 - 10 second delay between subs... and then keep track if how many 30-35? subs before it happens.
Or would the delay allow more subs to be acquired before it happens? 50-60? And easy test (though a lot of wasted time

I think with this issue you should be looking at your rpi power supply, it needs at least a 3 amp supply of you are plugging kit direct into the pi, infact I would say min 3 amp anyway....

Unfortunately it also happens when using a laptop directly connected !

Did anyone find a solution to this? I’m having the same problem on the MacOS build for version 3.5 when using a ZWO183MC.

This seems to be the list of possible causes that I’ve gathered from this thread:
1. Possible USB power issue - I’m using a powered USB hub, but it persists.
2. Possible bandwidth issue when autoguiding and imaging at the same time - This issue happens to me whether or not I am autoguiding, and whether or not I am using remote INDI server or local (direct connection).
3. Possible issue where the host computer has insufficient CPU resources - This issue happens whether I’m running Kstars on my RPI or running it from a Core-i7 laptop.

This still doesn’t seem to be solved. It also appears to be cross-platform and pervasive across multiple versions of Kstars from 2.9 all the way to 3.5. Any other suggestions on a possible fix?