I have an unstable astroberry system running on a raspberry pi 4 and currently seeing if this is due to the mix of usb ports and hubs I have. I see many entries in the /var/log/syslog when imaging like:  astroberry kernel;[2191.088776] usb 2-1.4 reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd. I get 3 failed attempts when imaging with my ZWO ASI 2600MM Pro.  No image file is created and the FITS viewer does not display.  Another message in the log is: astroberry kernel:[3162.902448] usb 2-1.4 usbfs: process 3240 (indi_asi_ccd) did not claim interface 0 before use.

When I get failed attempts at imaging I have no solution except to stop and restart Kstars (re-starting the camera driver doesn't help). Other times the system crashes without warning.

This could be due to the mix of USB 2.0 and 3.0 devices/cabling and the powered usb3.0 hub on the skywatcher EQ8-R Pro mount.  I have checked power supplies and cabling, all seem good. The imaging camera is used in alignment, focusing and imaging.  My suspicion is it may not be left in a suitable state in one module when starting another or not reset properly, say going from focusing to imaging.

I had good results with my previous and more simpler system when I used Astroberry to control a LX200 mount slaved with a Pulsar dome and PHD2 guiding with a ZWO ASI120MM mini. Since changing to a skywatcher EQ8-R Pro mount and adding new devices, ZWO ASI 2600MM Camera for imaging, filter wheel and focuser, the system has been unstable.

I would appreciate if someone could respond to this as I am unable to continue with Astroberry.

Literally the internet is full with similar error messages (X did not claim interface 0 …) from other devices with other software. According to this 10 year old message on stackoverflow stackoverflow.com/questions/11088691/err...-claimed-from-libusb, it‘s got to do with invoking libusb methods in the right order. This may be due to diverging libusb versions (compiled vs. installed).

Please turn on logging on the Ekos front tab and activate it both for camera module and cam driver in indi. Then please check that

Thanks for responding Grimaldi. Just read your response and I will turn on the logging and re-test at the next observing session.
Today I did some testing in the observatory and disconnected all devices gradually connecting each one by stopping the PI 4, power off, connect next device then power back on to identify them. using lsusb. Here's the full identified list:
Bus 002 Device 004: ID 03c3:260e <ZWO ASI 2600MM PRO>
Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Hub <EQ8-R PRO INTEGRATED USB 3.0 HUB>
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub <PI 4>
Bus 001 Device 004: ID 067b:23d3 Prolific Technology, Inc. <EQ8-R PRO MOTORS>
Bus 001 Device 003: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) <PULSAR DOME>
Bus 001 Device 010: ID 04b4:6572 Cypress Semiconductor Corp. <ZWO ASI 2600MM PRO USB 2.0 HUB>
Bus 001 Device 008: ID 03c3:1f01 <ZWO EFW>
Bus 001 Device 007: ID 03c3:120c <ZWO ASI 120MM MINI>
Bus 001 Device 006: ID 03c3:1f10 <ZWO EAF>
Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub <EQ8-R PRO INTEGRATED USB 3.0 HUB>
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub <PI 4>
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub <PI 4>

I have discovered a puzzling hardware issue where under certain conditions the PI doesn't power up and hangs with it's red LED on continuously. I think the skywatcher hub can lock up possibly when too much power is drawn through it by the imaging camera. Disconnecting and reconnecting power to the hub seems to reset it.
All 5 power supplies for the various devices including the PI are on the same multi gang extension lead. If I turn on everything together the PI never hangs on boot.
Need to investigate further.

I think the problem is how I am using PHD2 for guiding. I had had set my profile to use internal guider but was running PHD2 independently and connecting direct to guide camera probably. Guiding works but EKOS imaging fails to capture image.
Now set guiding to PHD2 in profile. Run PHD2 then hit the connect button in the EKOS guiding TAB.

Clear skies tonight having spent the last few days re-configuring usb connections and hubs. <strong> Unfortunately no better, Kstars crashed</strong> on taking the second image!  I had logging to file on as requested in verbose and attached is the kstars log file and the sys log   . 
The kstars log file last entries has warnings regarding threads and timers.
The syslog has many entries like 'reset  high-speed USB' which is for the ASI120mm mini (USB2) and 'reset SuperSpeed Gen 1 USB' for the ASI 2600MM Pro' (USB3).  Is this expected?

Rebooted Pi and tried again. Different last entry in kstars log this time. See log files:  .  This may be an irrelevant observation but this time I didnt have guiding running (PHD2) and took 2 images with no crash. Started PHD2 and took 2 more  images and kstars crashed on finishing second exposure.

I am running Astoberry v 2.0.4.  Indi_lib is 1.9.4.  indi-asi is 2.0.3.   

Some other less important issues to report:

1. Raspberry Pi 4 not powering up. This is due to the powered usb hub connected to the Pi 4.  Chaining an un-powered hub between the pi and the powered hub solves this issue (USB power feed design fault in Pi 4) This only happens if hub is powered on before the Pi.
2. Kstars permits running an image sequence when the dome is still moving to syncronise with the mount direction.  User should be warned and sequence not started until dome has reached position.
3. With telescope in home position pointing at the celestial pole and mount not tracking dome gets continuous command 'Dome is moving to position' then 'Dome reached requested position.  The position is not changing when mount is not tracking! 
4. When aligning using slew to target there is no mention of what the target actually is in the align TAB. Could this be added please.