Failed to stop RX streaming (-1000)

[scd31]

Hello,

Awesome project! I'm using trunk-recorder with a hackrf to decode local traffic in my area. It works for a while (generally a few hours) and then it throws a Failed to stop RX streaming (-1000) error. After this point, it's no longer able to decode any traffic, and it repeatedly throws the following error:

(error)   [sys_1] Retuning to Control Channel: 773.281250 MHz
(info)            - System Source 0 - Min Freq: 766.050000 MHz Max Freq: 777.950000 MHz
(error)   [sys_1]         Control Channel Message Decode Rate: 0/sec, count:  0
(error)   [sys_1] Retuning to Control Channel: 772.056250 MHz
(info)            - System Source 0 - Min Freq: 766.050000 MHz Max Freq: 777.950000 MHz
(error)   [sys_1]         Control Channel Message Decode Rate: 0/sec, count:  0

The only way to fix it is to restart the service. Unfortunately, this means I'm losing traffic until I notice the problem and restart!

I found this thread on the issue, but I didn't find it super helpful: greatscottgadgets/hackrf#883 . In any case, it would be nice if it could gracefully recover from the error (assuming there's not a way to fix the error itself).

Thanks!

[taclane]

While it doesn't address issues with the device or driver, trunk recorder has a failsafe option that should help:controlRetuneLimit.

Adding something like:

"controlRetuneLimit": 4,

to the config would terminate trunk recorder if it can't find a control channel after 4 (or however many) retune attempts. If you're using a restart script or systemd service, it can reset trunk recorder for you. While it's certainly worth investigating why your device is dropping off, the above option should remove the need to manually intervene when it gets caught in a retune loop.

[scd31]

Thanks! That helps a lot. I may just dump the hackrf and go with a couple of RTL-SDRs, but at least with the failsafe it's not a huge issue now.