Rtl_433: Program terminates with WARNING: async read failed (-5). Library error -5, exiting...

[pdo-smith]

If I leave the program running after invoking it with the following line:

./rtl_433 -a -s 1024k -F syslog:127.0.0.1:1514

it terminates anything between half an hour and three hours later with the message
WARNING: async read failed (-5).

Library error -5, exiting...

The version I was running was
18.05-133-ge43ec5d branch master at 201810302016

However if I run an earlier version, with the same command line:
18.05-129-ga6c4b10 branch master at 201810241213

it is rock solid and does not fall over with that error message.
Both versions were recompiled in the same way but this error persisted only in the more recent version.

Note:
If I make the sampling bandwidth smaller, it seems to take longer to fail. But the time to failure is quite variable so this might not be the case. All of this was on Ubuntu 18.10

[zuckschwerdt]

Can you post the startup output?
Also with -a you won't get syslog output, it will just analyze and not run the demodulators.

[pdo-smith]

Here it is:

trying device 0: Realtek, RTL2832UHIDIR, SN: 00000001
Detached kernel driver
Found Rafael Micro R820T tuner
Using device 0: Generic RTL2832U OEM
[R82XX] PLL not locked!
Sample rate set to 1024000.
Bit detection level set to 0 (Auto).
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers

[zuckschwerdt]

The only thing that comes to mind is the SoapySDR support from #842. Can you test the preceeding version (2ceb535) and that one (d596f6a)?

[pdo-smith]

I am running 2ceb535 and so far it looks good. I will leave it running overnight let you know tomorrow what the outcome is.

[pdo-smith]

I have been running 2ceb535 for 8 hours and there have been no problems. The program no longer aborts as it did before.

I hope this helps you.

[zuckschwerdt]

Thanks! Now can you run the immediate next commit (d596f6a) to see if that introduces the bug for you?

[pdo-smith]

I am busy running d596f6a. I will let you know at the end of the day what happens.

Oops, it has just failed. That did not take long.

cb transfer status: 1, canceling...
WARNING: async read failed (-5).

Library error -5, exiting...
Reattaching kernel driver failed!

[zuckschwerdt]

Thanks! I'm going to look where the culprit could be.

[pdo-smith]

Just as an aside. I am using rtl_433 to integrate my sensors into a more capable alarm system(I live in a very dangerous place). For that I need rock solid reliability. I like your suggestion of using supervisord and will test that out.

I would love to know how other people use rtl_433 and I am sure I could learn a lot from them.

[zuckschwerdt]

Yes, some kind of gallery where people post their devices, setup, and toolchain would be great. Any ideas how we can get there? Some kind of hosted wiki perhaps? Maybe a wiki repo on Github and give everyone interested commit access?

[zuckschwerdt]

Ok, there error is from https://github.com/osmocom/rtl-sdr/blob/master/src/librtlsdr.c#L1717
and seems to be a LIBUSB_TRANSFER_ERROR. Are you running both rtl_433 versions with exactly the same libusb? Or is one maybe a system lib and the other in /usr/local? (something like ldd rtl_433/build/src/rtl_433 to see what is linked)

[pdo-smith]

Good that you have narrowed down the problem. This is what I have:

locate librtlsdr.so

/home/peter/Development/rtl_fm_streamer/build/src/librtlsdr.so
/home/peter/Development/rtl_fm_streamer/build/src/librtlsdr.so.0
/home/peter/Development/rtl_fm_streamer/build/src/librtlsdr.so.0.5git
/usr/lib/x86_64-linux-gnu/librtlsdr.so
/usr/lib/x86_64-linux-gnu/librtlsdr.so.0
/usr/lib/x86_64-linux-gnu/librtlsdr.so.0.5.4

I have compiled/linked my rtl_433 programs under identical conditions from an empty build folder. (cmake ../ followed by make). I then executed the program from within build/src

Do you need more information?

[pdo-smith]

Oops, I see I didn't answer your question.

Here is the output from the version that does not fall over:

~/Development/rtl_433-0/build/src$ ldd rtl_433
linux-vdso.so.1 (0x00007ffd9b5b2000)
librtlsdr.so.0 => /usr/lib/x86_64-linux-gnu/librtlsdr.so.0 (0x00007f66d5a74000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f66d58e7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f66d56fd000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f66d54e4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f66d5d13000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f66d54c4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f66d54a3000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f66d5497000)

and this is the output from the version that does fall over:

~/Development/rtl_433-3/build/src$ ldd rtl_433
linux-vdso.so.1 (0x00007ffc38bb1000)
librtlsdr.so.0 => /usr/lib/x86_64-linux-gnu/librtlsdr.so.0 (0x00007fc68d287000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc68d0fa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc68cf10000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007fc68ccf7000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc68d527000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fc68ccd7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc68ccb6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc68ccaa000)

[pdo-smith]

Your finding is very interesting:

    if (dev->xfer_errors >= dev->xfer_buf_num ||
        LIBUSB_TRANSFER_NO_DEVICE == xfer->status) {
        dev->dev_lost = 1;
        rtlsdr_cancel_async(dev);
        fprintf(stderr, "cb transfer status: %d, "
            "canceling...\n", xfer->status);

This raises the possibility of a momentary failure in my usb system, connectors, hub, etc.
To check out this possibility I am running my "good" version of rtl_433 continuously. So far so good. I will leave it running the whole day and report back.

[zuckschwerdt]

The strange thing is, that d596f6a doesn't add or change anything with the RTL-SDR interface, it is mainly refactoring. There is the addition of SoapySDR but that shouldn't matter.
Do you see SoapySDR as compiled in? Try rtl_433 -d to get a help text.

[pdo-smith]

_Do you see SoapySDR as compiled in? Try rtl_433 -d to get a help text_

Yes, I saw it.
I agree the whole matter is puzzling. My intuition suggests the problem is on my side, possibly in the hardware. But so far my "good" version of rtl_433 has not fallen over. I have a motion detector set above my desk, reporting my every move, so that rtl_433 is continuously exercised.

[zuckschwerdt]

I've been running the current version on stock Debian 9.5 (libusb-1.0.so.0.1.0 and librtlsdr.so.0.5.3) without trouble. I need to test rtl-sdr 0.5.4 which you have.

[zuckschwerdt]

So far neither rtlsdr 0.5.3 (stock Debian 9.5) nor v0.5.4 from source cause any trouble on the latest master. My best guess is that there is really some USB trouble specific to your system.
Maybe you can try librtlsdr 0.5.3 and the 0.6.0git?

[pdo-smith]

I owe you guys a big apology.

I went over my machine carefully, re-seating everything. Since then I have been able to run the later version of rtl_433 for several hours without any problem whatsoever.

The problem is definitely on my side and I am so sorry I put you to so much trouble. Thanks for being attentive and doing your best to help out.

[zuckschwerdt]

All is well that ends well ;) Glad you solved it. Projects with diverse hardware depend on bug reports and people willing to investigate, we'll always try to help as best as possible.

[white-moustache]

I also have this "async read failed (-5)..." message on Ubuntu 18.04. with with rtl_433 version 18.12-67-gd09827a branch master at 201901110925. Dear pdo-smith would you please tell me how could you solve this problem?

[white-moustache]

My "async read failed (-5)" error was the result of an usb error. With dmesg I've seen the following:
[ 117.930240] usb usb1-port3: disabled by hub (EMI?), re-enabling... and this was in coincidence with rtl_433 warning async read failed message. So I pulled out the bluetooth adapter from the neighbour usb port and everithing is OK now.
Excuse me for disturbing you with that.

[zuckschwerdt]

Always interesting to see what can go wrong. But as it's libusb, USB or even hardware we can't really help.