Closed romeojulietthotel closed 6 years ago
I increased the timeout in src/ConnectionSTREAM/ConnectionSTREAM.cpp
unsigned int Timeout = 1500;
But that did not solve this.
I also ran my Gnuradio flowgraph like this:
LIBUSB_DEBUG=4 python top_block.py
This file grew large (over 8GB) and ran overnight but the problem never showed up. I might be chasing my tail now.[1]
I am thinking there is some latency in the USB stack so I will file an issue against libusb.
I notice that the code which is submitting the transfer does not check the 'done' field before submitting
Please see:
https://github.com/libusb/libusb/issues/289#issuecomment-300983339
Edit: Quote from the libusb issue: "I notice that the code which is submitting the transfer does not check the 'done' field before submitting, so perhaps this is the place to start looking."
I am not sure if this issue is still relevant. I took a quick look at the current streaming code and for me it seems that now usb transfers that are not completed should not be re-submitted. Anyway, even if that used to happen, then the actual problem was probably stalled usb communication and LIBUSB_ERROR_BUSY error was popping up just because software gave up waiting after some timeout and tried to resubmit transfer .
Closing, re-open if still relevant.
I have a Gnuradio app running and it has been running fine for a few days. The system is not busy. Out of nowhere I got this error and the app stopped receiving data.
BEGIN DATA READING LIBUSB_ERROR_BUSY
I restarted the app and it began receiving data again. It's not receiving a lot of data and the LimeSDR is connected via USB3.
Maybe this is an issue with libusb. I am using libusb 1.0.21 and never experienced on 1.0.20.