Enhance README to address messy librtlsdr situation

[gdt]

It seems (e.g. #2701) that versions of librtlsdr even in up-to-date packaging systems don't work with some dongles (e..g Blog v4).

The overall situation is complicated and I think it's unclear. The version of librtlsdr that many packaging systems consider authoritative is at 0.6.0, tagged in 2018 -- even as Blog v4 supported was commited in August 2023. There are others:

• https://github.com/osmocom/rtl-sdr (mirror)
• https://github.com/steve-m/librtlsdr (also 2018)
• https://github.com/librtlsdr/librtlsdr (has a 0.8.0 tag from 2020)

While it's not really rtl_433's responsibility to sort this all out, it would be good when saying to use librtlsdr to say what we think the upstream is.

(Calling this todo more than enhancement as the real issue is figuring out what to recommend, not how to write the text.)

[rtlsdrblog]

Hi Greg, replying here and to your email as requested.

I found your text at
https://www.rtl-sdr.com/V4/ but I find it hard to follow, because it usees the word "driver" when I
think that means "librtlsdr library".

The RTL-SDR community refers to the library as the drivers, so we keep with that convention. I'd say they are drivers in the sense that they contain the lower level code to drive the hardware, it's just that it's built on top of libusb, so they are not kernel-mode drivers.

The Osmocom rtl-sdr repo is considered to be 'upstream'. The Osmocom GitHub mirror always seems to be up to date, so that's probably the easiest source. Unfortunately Osmocom rtl-sdr doesn't seem to be maintained very actively anymore. They did accept my patch to support the V4, but all the subsequent smallest patches I've submitted appear to have been ignored. They also seem to be ignoring requests to tag a new release, which would trigger package updates.

librtlsdr/librtlsdr is a more experimental repo that favors features over stability. Not that I've ever found it to be unstable. I believe the lead maintainer said he was working on a tag, but no idea on the priority of that.

I think the best thing you can do is encourage users to install from the official Osmocom GitHub source or the librtlsdr source, and never via the package manager. You might want to show how to purge previously installed package manager drivers though, as if you install via the package manager and via source it will conflict.

And ideally the docker images would be updated too.

[gdt]

Thanks very much for chiming in. That's useful perspective.

I can see your point about being consistent with community usage of driver, but it's odd usage for someone coming from a normal unix background where it ~always means part of the OS kernel, so it would be good to add a "by driver we mean the librtlsdr library" so that people who know they haven't yet found something that would be called a drive can get unconfused.

What about https://github.com/steve-m/librtlsdr ?

Separately from the "understand" point, it's irregular to recommend running non-released versions of prerequisites (even if rtl_433 is also delinquent in releasing, but by under a year), so that necessarily goes along with "upstream is seriously unhealthy" but you said they aren't taking your patches so we agree ;-). Do you see a path to a healthy upstream, one that addresses quality patches, and that has releases?

I also wonder if I should be moving the pkgsrc package from osmocom tag to librtlsdr master.

[rtlsdrblog]

The steve-m fork I believe is just the lead maintainer of Osmocom/rtl-sdr's personal fork. But these days I think it's pretty much identical to the Osmocom repo.

I don't think Osmo will become any more active then they are now on the RTL-SDR project. I am hoping at some point they will still release a new tag though.

[zuckschwerdt]

There might be problems with the rtlsdrblog version, see this thread:
https://www.reddit.com/r/RTLSDR/comments/17o2zg0/rtl_433_not_working_with_sdr_directly_but_does/

[gdt]

It's hard to tell what code that person is running, but I can see that squinting one think that the blog fork of rtl-sdr has an issue, perhaps.

[gdt]

FWIW I moved pkgsrc to https://github.com/osmocom/rtl-sdr 2.0.1

[acsawdey]

I'm not sure if this is part of the "messy librtlsdr situation" or another issue, but what I've encountered is this:

I have two SDR devices, a RTL-SDR Blog V4, and an older one I got from Adafruit (https://www.adafruit.com/product/1497).

What I am seeing is that rtl_433 will only work with the V4 if it is built using the new librtlsdr from their git, and it will only work with the old device if I build it with the "0.6" librtlsdr that raspbian or ubuntu 22.04 have. The other combinations, it builds and runs but I never receive any signals. rtl_adsp on the other hand works with either device and either library.

Is this expected?

[zuckschwerdt]

Thanks for the report. That is not expected. Strange that newer librtlsdr breaks support for an older receiver.

[acsawdey]

I'll copy that description into a new issue. I may be able to find time to poke into what's going on there.

[rtlsdrblog]

The new osmocom version of librtlsdr remains compatible with all RTL-SDRs. No changes have been made that could break compatibility with older SDRs. What could be happening is something to do with the SOVER mess that has been caused by osmocom arguably incorrectly bumping their SOVER to 2.0. If rtl_433 now targets 2.0, will drivers with SOVER 0 still work? Regards, Carl

…

On Thu, Apr 4, 2024 at 9:51 AM Aaron Sawdey ***@***.***> wrote: I'll copy that description into a new issue. I may be able to find time to poke into what's going on there. — Reply to this email directly, view it on GitHub <#2703 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHEAQRRL7IXXWF74PST34LY3RTWZAVCNFSM6AAAAAA6WGZGXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZVGU3DKNZTG4> . You are receiving this because you commented.Message ID: ***@***.***>

[gdt]

AIUI, rtl_433 uses cmake and looks for the lib. I don't see that it has a viewpoint about the shlib number, or that it matters.

Your point that people may have systems that are a mess because of how they are upgrading and/or building/installing things outside of package managemetn, etc. is a good one and there is likely some validity to it.

[zuckschwerdt]

I tested building and running rtl_433 with "incompatible" SO versions (e.g. build with 2.0, run with 0.6): It works fine, I didn't see any API or ABI change we care about.

I even recommend to do that for our MacOS builds as Brew has "2.0" but MacPorts "0.6" still.
https://triq.org/rtl_433/BINARY_BUILDS.html#macos