Deadlock in airspy_close if device is unplugged while streaming about airspyone_host HOT 11 CLOSED

I suspect this "issue" mainly comes from libusb which does not manage correctly hotplug by default

• It will be interesting to use a newer/latest stable libusb which probably cancel transfer properly and return error codes (which are all checked in libairspy)...
  See https://sourceforge.net/p/libusb/mailman/libusb-devel/thread/4A9BB29B.1030602%40edigma.com/#msg23442207
  • If issue is not fixed maybe, it will be interesting to implement https://libusb.sourceforge.io/api-1.0/libusb_hotplug.html to see if that fix the issue, anyway an investigation shall be done to understand what happen exactly ...

from airspyone_host.

Full hotpluging looks nice, but I think than this issue is actually in the current libairspy implementation (I might be wrong ofcourse).

When the device is removed, all libusb_* functions that are blocking, like here:

The "cleanup release" of the conditional that is called during a "normal" stop here:

I think the fix is as simple as making sure that the conditional is signaled from the transfer_threadproc when libusb_handle_events_timeout_completed returns an error and sets device->streaming = false.

I will create a pull request for you to look at.

from airspyone_host.

Yes very interesting thanks for the analyze
Such use case was not tested as it is not "normal process" to remove the USB cable when streaming anyway it is a good improvement if that can be correctly managed in libairspy.
To be checked with your code which reproduce the issue more "easily" with a PR to test the fix.
Note: About libusb hotplug support it seems still not supported for Windows see libusb/libusb#86

from airspyone_host.

You can easily run your own "hotplug" with the current libairspy (if we disregard the current deadlock) by simply checking airspy_is_streaming. If that function returns error, it means that the device disappeared somehow and you can close the device and try opening it again. And just repeat until the device is inserted.

My use case is using an Airspy from a program in deamon mode so I like to have a robust implementation that can handle if the device is pulled for some reason.

BTW, there are memory leaks in libairspy as well when pulling a device that are streaming (if not valgrind is messing up something here...). I think I have some leads, but some way of dealing with the deadlock seem like priority one.

from airspyone_host.

Thanks for your contribution it is fixed with #76

from airspyone_host.

Thank you for the quick response!

from airspyone_host.

There is still one problem. If one transfer fails, the entire streaming will be stopped. This could happen more often than you think depending on the USB host hardware and the quality of the transmission line. That's why the buffer sizes are aligned to specific values so the streaming can resume without corrupting the upcoming data. Losing one transfer is less dramatic than stopping the entire streaming session. In some scenarios, stopping the stream cannot be tolerated.
A better solution would be to detect if the device is still alive using a time stamp which is updated on successful receive, and only stop the streaming if no data is reaching the host after some timeout.

from airspyone_host.

There is still one problem. If one transfer fails, the entire streaming will be stopped.

Point taken. But as far as I can se, this was already the case before #76. Right?

from airspyone_host.

Correct. The line in question is commented in other implementations (like airspy_adsb.)

from airspyone_host.

This issue shall be fixed with #78

from airspyone_host.

This issue is now fixed with merge of #78

• It will be nice to have feedback from users to confirm all work fine in normal cases (on different OS/Computer) and also when USB is disconnected during streaming which shall be work fine now

from airspyone_host.