Contact the ZWO people and ask them to fix their USB code for the Linux/Mac SDK

[jgottula]

• [ ] Figure out who to contact at ZWO and how to do so
• [ ] Explain exactly what the problematic symptoms were (at a surface level)
• [ ] Show some of the diagnostic work we did (Wireshark USB captures, watching libusb calls, etc) and go into detail on what was going on at the USB bus level and then the libusb API level
• [ ] Explain how ignoring the return value of libusb_cancel_transfer leads to the downstream effects that cause the problem that's at issue here
• [ ] Recommend how they should remediate the main libusb_cancel_transfer related problem
• [ ] Also recommend that they stop ignoring the return values of basically all libusb calls they make, and that they instead put in return value checks where appropriate
  • [ ] Get a list of all the libusb functions they call where it would be advisable to be checking return values rather than ignoring them
• [ ] I can't actually remember if there was a more "core" issue going on that was underlying the libusb_cancel_transfer problem... but if that was indeed a thing and if we can also remember what it was, then also recommend to them that they fix whatever that deeper issue was

If completely successful (bug reported, bug fixed, new SDK released with fully-working USB code), this potentially means we will no longer have a strong need to use zwo_fixer, and so we can remove that from the build process.

(Though it would still be good to keep the zwo_fixer code around, because it's ready-to-go stuff, and you never know when we might decide that we need to tweak some other aspect of the SDK code to work more to our liking or fix some other bug that comes up.)

[ckuethe]

I've been in contact with sam.wen , software , and support at zwoptical.com, in case you are still interested...

[bgottula]

@ckuethe excellent, thanks for commenting. What have you shared with ZWO so far? We've known about some issues with their driver on Linux for some time now but have been too lazy to follow through with contacting them about it (yet somehow instead found the time to create a very elaborate work-around...). I can potentially help with testing or providing info / evidence for the problems we know about.

[ckuethe]

I've been grumbling about their firmware updates and library debug.

Did you know that you can enable some SDK debug messages setting DebugPrint to 01 in ~/.ZWO/ASIconfig.xml? I wanted them to add an environment variable so that any application running when that variable was set could emit debug messages, rather than editing the config file. Alas, after disassembling the library the only call to getenv I see is to get $HOME.

My motivation for this is to 1) troubleshoot a camera of mine that has suddenly stopped producing images, and 2) to improve troubleshooting for users of allsky

Unfortunately their firmware updater also doesn't work well on non-windows; It segfaults on my ubuntu machine, doesn't exist for raspberry pi, can't update usb2 devices on mac, and requires a bunch of extra software drivers on windows. Ugh.