rtl_fm scanning

[Colin Stagner]

I am also having the rtl_fm scanning bug which was first reported in
http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-February/000485.html

The scanning mode in rtl_fm hangs during the re-tuning process. This
makes it impossible to use rtl_fm in scanning mode. I am using Ubuntu
12.10 with libusb 2:1.0.12-2, the latest git master version of rtl-sdr,
and an Elonics E4000 (Realtek, RTL2838UHIDIR).

Here are the steps to reproduce:

1. Find some frequency FREQ_NOISE that is not in use, and some frequency
FREQ_SIGNAL which is in use constantly (i.e., like a commercial FM
station). Find an appropriate squelch value SQUELCH which will stop
FREQ_NOISE but pass FREQ_SIGNAL.
2. rtl_fm -f ${FREQ_NOISE} -l ${SQUELCH}. The program should not pass
any audio, but it will exit cleanly with ^C.
3. rtl_fm -f ${FREQ_SIGNAL} -l ${SQUELCH}. The program should pass audio
and exit cleanly with ^C
4. rtl_fm -f ${FREQ_SIGNAL} -f ${FREQ_NOISE} -l 0. The scan will pause
on the first channel and pass audio.
5. rtl_fm  -f ${FREQ_NOISE} -f ${FREQ_SIGNAL} -l ${SQUELCH}. The program
will not output any audio, even though the first frequency is squelched
out and the scanning function should skip immediately to the second
frequency. Additionally, it will not exit if sent a SIGINT with ^C, and
it must be killed with a SIGKILL.

I've made a stack trace of this behavior. The program hangs very
consistently at the same location each time:
http://pastebin.com/wzE09MCi

Thread 1 (the USB buffer reading thread) hangs while waiting for the
data_write mutex lock in rtl_fm.c:642. I presume the thread has
exhausted its supply of data and isn't getting any more.
Thread 2 is slightly more interesting, because it hangs during the
libusb system calls within the tuning function rtlsdr_set_center_freq()
in librtlsdr.c:796. My guess is that it's making a blocking call that
never returns.

Can anyone else reproduce this bug?