I occasionally get the error "cb transfer status: 1, canceling...". This usually is because something bumped my pi causing the RTLSDR dongle to move.
rtl_fm nicely emits to ERROUT but remains running. I think this is likely an error. I would expect the process to die in this state. Is this reasoning correct?
I made a change with claude.ai , it removed invoking `rtlsdr_cancel_async(dev);`
=== Why this fixes the halt:
The callback was calling rtlsdr_cancel_async() while already executing inside the libusb_handle_events_timeout_completed() loop (line 1924), which would modify the dev->async_cancel flag that the event handler was actively monitoring. This created a deadlock/race condition.
Now the callback simply sets the dev->dev_lost flag, and the main event loop at line 1961 properly detects this condition and breaks out cleanly, allowing normal termination to occur.
The process should now terminate correctly when USB transfer errors occur. ===
The change is available at https://github.com/osmocom/rtl-sdr/compare/master...ramonsmits:rtl-sdr:rtlsd...
Does this change make any sense?
I have not fully tested this as I'm new to this project and somehow need to build this and deploy on my pi4 which I need to figure out.
Any help appreciated!
-- Ramon
Branch is now improved and tested.
Wiggling the RTLSDR dongle in the USB socket now emits the following and the process exits:
cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling... cb transfer status: 5, canceling...
Device error detected, async read returned: -1
-- Ramon
On Thu, Dec 25, 2025 at 1:42 PM Ramon Smits ramon.smits@gmail.com wrote:
I occasionally get the error "cb transfer status: 1, canceling...". This usually is because something bumped my pi causing the RTLSDR dongle to move.
rtl_fm nicely emits to ERROUT but remains running. I think this is likely an error. I would expect the process to die in this state. Is this reasoning correct?
I made a change with claude.ai , it removed invoking `rtlsdr_cancel_async(dev);`
=== Why this fixes the halt:
The callback was calling rtlsdr_cancel_async() while already executing inside the libusb_handle_events_timeout_completed() loop (line 1924), which would modify the dev->async_cancel flag that the event handler was actively monitoring. This created a deadlock/race condition.
Now the callback simply sets the dev->dev_lost flag, and the main event loop at line 1961 properly detects this condition and breaks out cleanly, allowing normal termination to occur.
The process should now terminate correctly when USB transfer errors occur.
The change is available at https://github.com/osmocom/rtl-sdr/compare/master...ramonsmits:rtl-sdr:rtlsd...
Does this change make any sense?
I have not fully tested this as I'm new to this project and somehow need to build this and deploy on my pi4 which I need to figure out.
Any help appreciated!
-- Ramon
-
Ramon Smits