Error: "not keeping up witl rtl_tcp"

[WB0OCV]

Hello all,

I have been using rtlamr v0.9.5 since April-2026, and recently have started receiving some error messages regarding "not keeping up with rtltcp". I am using the following command to pipe the output from a single r900 water meter into a csv file:
rtlamr -msgtype=r900 -filterid=15503xxxxx -symbollength=8 -format=csv 1>>"water_use.csv"
Most of the time the commands will work, but occasionally I will receive several of the error messages in succession. A segment of the output is captured below. I have set the symbollength to minimize SDR sample rate. My machine is Windows 10 X64 Professional running Intel i7-7700K CPU at 4.20 GHz with 4 cores, and 32 GB of RAM. If I look at machine performance when the errors occur, the total CPU usage is less that 20% and total memory usage less than 40%. Any recommendations on settings to resolve the issue would be appreciated. Thanks for a great program like rtlamr. Ken -- WBØOCV

---

rtlamr -msgtype=r900 -filterid=15503xxxxx -symbollength=8 -format=csv  1>>"water_use.csv"
time=2026-07-12T12:10:25.189-04:00 level=INFO source=rtlamr\protocol\decode.go:45 msg="CenterFreq: 912380000"
time=2026-07-12T12:10:25.191-04:00 level=INFO source=rtlamr\protocol\decode.go:46 msg="SampleRate: 262144"
time=2026-07-12T12:10:25.191-04:00 level=INFO source=rtlamr\protocol\decode.go:47 msg="DataRate: 32768"
time=2026-07-12T12:10:25.191-04:00 level=INFO source=rtlamr\protocol\decode.go:48 msg="ChipLength: 8"
time=2026-07-12T12:10:25.191-04:00 level=INFO source=rtlamr\protocol\decode.go:49 msg="PreambleSymbols: 32"
time=2026-07-12T12:10:25.191-04:00 level=INFO source=rtlamr\protocol\decode.go:50 msg="PreambleLength: 512"
time=2026-07-12T12:10:25.191-04:00 level=INFO source=rtlamr\protocol\decode.go:51 msg="PacketSymbols: 116"
time=2026-07-12T12:10:25.191-04:00 level=INFO source=rtlamr\protocol\decode.go:52 msg="PacketLength: 1856"
time=2026-07-12T12:10:25.191-04:00 level=INFO source=rtlamr\protocol\decode.go:59 msg="Protocols: r900"
time=2026-07-12T12:10:25.192-04:00 level=INFO source=rtlamr\protocol\decode.go:60 msg="Preambles: 00000000000000001110010101100100"
time=2026-07-12T12:10:25.192-04:00 level=INFO source=rtlamr\main.go:129 msg=rtl_tcp GainCount=29
time=2026-07-12T12:10:26.192-04:00 level=ERROR source=rtlamr\main.go:194 msg="not keeping up with rtl_tcp" rate=163328
time=2026-07-12T12:10:27.192-04:00 level=ERROR source=rtlamr\main.go:194 msg="not keeping up with rtl_tcp" rate=260608
time=2026-07-12T12:10:29.192-04:00 level=ERROR source=rtlamr\main.go:194 msg="not keeping up with rtl_tcp" rate=261632
time=2026-07-12T12:10:30.192-04:00 level=ERROR source=rtlamr\main.go:194 msg="not keeping up with rtl_tcp" rate=240640

[bemasher]

Is rtl_tcp running on the same machine? It's possible something occurred in rtl_tcp that dropped samples.

rtlamr keeps track of how fast it is consuming samples. If it is less than 90% of the expected sample rate, that message is printed to let the user know. If you see that message only occasionally it's nothing to worry about, if it's received constantly, there is likely not enough processing power for the configured message types and sample rate.

Your hardware should certainly be more than enough for the message type and sample rate you've selected.

[WB0OCV]

Thank you, Doug. Yes, rtl_tcp is installed on the same drive and even the same folder as rtlamr, as well as the supporting dlls for rlt_tcp. I had downloaded and installed the latest zip file of 64-bit rtl_sdr just this morning. I've tried multiple RTL-SDR dongles, and experienced the same problem. The one thing I haven't tried yet is moving the dongle to a different USB port to see if perhaps there some underlying USB communications issues. Would it be worth trying with 32-bit rtl_tcp? Thanks for your insights. Ken -- WBØOCV

…

On Sun, Jul 12, 2026, 14:23 Douglas Hall ***@***.***> wrote: *bemasher* left a comment (bemasher/rtlamr#339) <#339 (comment)> Is rtl_tcp running on the same machine? It's possible something occurred in rtl_tcp that dropped samples. rtlamr keeps track of how fast it is consuming samples. If it is less than 90% of the expected sample rate, that message is printed to let the user know. If you see that message only occasionally it's nothing to worry about, if it's received constantly, there is likely not enough processing power for the configured message types and sample rate. Your hardware should certainly be more than enough for the message type and sample rate you've selected. — Reply to this email directly, view it on GitHub <#339?email_source=notifications&email_token=ANMPGSOJRUQVVVSCZVKNZXL5EPJS3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVGIZDMNRRGM22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4952266135>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANMPGSK6G2MDVCLFAQ3GPTT5EPJS3AVCNFSNUABEKJSXA33TNF2G64TZHMYTMNRSGMYTKNR3JFZXG5LFHM2DQNRXHAZTINBVGSQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ANMPGSIY7XMT2SGNSROHCLL5EPJS3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVGIZDMNRRGM22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/ANMPGSPTTJG3KO7QIKM7CZT5EPJS3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVGIZDMNRRGM22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[bemasher]

Windows does have some regressions relating to USB devices, I have found it is necessary to enable Show hidden devices in the Device Manager and remove "inactive" USB devices periodically, but that is probably only necessary if you are regularly plugging/unplugging USB devices in this system.

[WB0OCV]

Hello Doug, I wanted to report back. I tried rebooting the machine, moving the RTL-SDR dongle to a different USB port on a different USB controller, and using both the 32-bit and 64-bit versions of the latest revision of rtl_tcp. Regardless of what I tried, I was still experiencing significant amounts of the same error of "not keeping up with rtl_tcp" with the newest v0.9.5. I reverted back to the previous version of rtlamr, v0.9.1 dated 20-Sep-2018, and have experienced flawless data recovery over the past 36 hours without any dropouts. Based on this experience with the older version, it would suggest there is something in the latest version of rtlamr causing the dropout issues. At least for the time being, I'll continue to use the old v0.9.1 for logging my water meter readings. Thanks again for this great program. Ken -- WBØOCV

…

________________________________ From: Douglas Hall ***@***.***> Sent: Sunday, July 12, 2026 3:48 PM To: bemasher/rtlamr ***@***.***> Cc: WB0OCV ***@***.***>; Author ***@***.***> Subject: Re: [bemasher/rtlamr] Error: "not keeping up witl rtl_tcp" (Issue #339) [https://avatars.githubusercontent.com/u/79724?s=20&v=4]bemasher left a comment (bemasher/rtlamr#339)<#339 (comment)> Windows does have some regressions relating to USB devices, I have found it is necessary to enable Show hidden devices in the Device Manager and remove "inactive" USB devices periodically, but that is probably only necessary if you are regularly plugging/unplugging USB devices in this system. — Reply to this email directly, view it on GitHub<#339?email_source=notifications&email_token=ANMPGSK2AGNWBQQ4GP2Y4CT5EPTQTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVGI2TENZTGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4952527312>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANMPGSOGJYYKFA2DJLOJZ635EPTQTAVCNFSNUABEKJSXA33TNF2G64TZHMYTMNRSGMYTKNR3JFZXG5LFHM2DQNRXHAZTINBVGSQXMAQ>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/ANMPGSPVS2EKS2WPWDN2DVL5EPTQTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVGI2TENZTGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/ANMPGSNWUJ6LDGJ7LG7756L5EPTQTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVGI2TENZTGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[cproo12]

Also having this issue, fine cpu usage, usb 3, etc.

Using the Nooelec Nano 2+
https://www.nooelec.com/store/nesdr-nano2-plus.html

And getting this output

rtl_tcp
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Detached kernel driver
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Tuned to 100000000 Hz.
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
client accepted! localhost 59216
set freq 912380000
set sample rate 2359296
set gain mode 0

rtlamr -msgtype all
github.com/bemasher/
time=2026-07-19T21:18:09.210-04:00 level=INFO source=rtlamr/protocol/decode.go:45 msg="CenterFreq: 912380000"
time=2026-07-19T21:18:09.210-04:00 level=INFO source=rtlamr/protocol/decode.go:46 msg="SampleRate: 2359296"
time=2026-07-19T21:18:09.210-04:00 level=INFO source=rtlamr/protocol/decode.go:47 msg="DataRate: 32768"
time=2026-07-19T21:18:09.210-04:00 level=INFO source=rtlamr/protocol/decode.go:48 msg="ChipLength: 72"
time=2026-07-19T21:18:09.210-04:00 level=INFO source=rtlamr/protocol/decode.go:49 msg="PreambleSymbols: 32"
time=2026-07-19T21:18:09.210-04:00 level=INFO source=rtlamr/protocol/decode.go:50 msg="PreambleLength: 4608"
time=2026-07-19T21:18:09.211-04:00 level=INFO source=rtlamr/protocol/decode.go:51 msg="PacketSymbols: 736"
time=2026-07-19T21:18:09.211-04:00 level=INFO source=rtlamr/protocol/decode.go:52 msg="PacketLength: 105984"
time=2026-07-19T21:18:09.211-04:00 level=INFO source=rtlamr/protocol/decode.go:59 msg="Protocols: scm,scm+,idm,r900"
time=2026-07-19T21:18:09.211-04:00 level=INFO source=rtlamr/protocol/decode.go:60 msg="Preambles: 0001011010100011,01010101010101010001011010100011,00000000000000001110010101100100,111110010101001100000"
time=2026-07-19T21:18:09.211-04:00 level=INFO source=rtlamr/main.go:129 msg=rtl_tcp GainCount=29
time=2026-07-19T21:18:10.228-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2236416
time=2026-07-19T21:18:21.212-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2351104
time=2026-07-19T21:18:48.212-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2351104
time=2026-07-19T21:19:01.212-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2351104
time=2026-07-19T21:19:07.212-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2351104
time=2026-07-19T21:19:21.213-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2342912
time=2026-07-19T21:19:25.213-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2334720
time=2026-07-19T21:19:32.211-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2351104
time=2026-07-19T21:19:39.212-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2334720
time=2026-07-19T21:19:41.212-04:00 level=ERROR source=rtlamr/main.go:194 msg="not keeping up with rtl_tcp" rate=2342912

Arch Linux, using the version from the AUR, which is rtlamr 0.9.5-1

[bemasher]

@cproo12: The issue for the values shown in your logs was corrected in 0adbc1b, where rtlamr reports only when less than 90% of the expected samples are consumed. That commit is not part of a tagged release yet, so won't be picked up by AUR unless you are using rtlamr-git.

[cproo12]

Ah, derp. I made an assumption! I have since updated and the issue has went away for me, I'm still not getting any other console output, so I don't think my meter supports it, but I might just not be sure what I'm doing.

Thats a separate issue though. Thanks for the timely reply and great software! :)

[WB0OCV]

Hi Doug. I am currently using the latest go version 1.26.5, and downloaded and compiled the latest version of rtlamr unsing the command:
go install github.com/bemasher/rtlamr@latest
If I follow tht guidance, will the compiled rtlamr.exe include the 07-Jun-2026 corrections described in commit 0adbc1b above? When I compiled and ran the latest version, I am still getting the errors as I described earlier, and as cproo12 also described. I have since reverted back to using rtlamr version 0.9.1, and have not experienced any errors or drop outs.
I just wanted to pass this information on. Thanks again for this great piece of software. Ken -- WBØOCV

[bemasher]

I'd like to clarify that the message is purely informational. It lets you know when either rtlamr is not processing fast enough, or rtl_tcp is not producing samples at the expected sample rate. It has no effect on decoding, and does not change what messages are received.

The message was added because a substantial number of issues asked about ll+ and ll- messages produced by rtl_tcp, when attempting to run all the decoders at full-bore on a system that can't keep up.

One additional thing I've considered is only enabling the message when either r900 or all messages are selected for decoding, since those are the problematic decoder selections.

[nwe514]

I got this message also, starting rtl_tcp and rtlamr on the same Debian 13 Trixie box at low load conditions, for the first time (I just discovered rtlamr). I noticed the message indicates level=ERROR and thought, something didn't work. So my suggestion is, if this message is purely informational, could it be reworded to something like level=INFO or otherwise something other than ERROR?

time=2026-07-25T10:43:41.940-05:00 level=ERROR source=rtlamr@v0.9.5/main.go:194 msg="not keeping up with rtl_tcp" rate=2232320

Just my two cents. Thanks for the good work.

[bemasher]

Yeah, just made that change last night:

rtlamr/main.go

Lines 191 to 193 in 3bc87c3

	if bytesRead>>1 < (rcvr.d.Cfg.SampleRate * 9 / 10) {
	slog.Warn("not keeping up with rtl_tcp", "rate", bytesRead>>1)
	}

[seahorse41]

I am also getting this message. I understand you said it is informational, but if it's missing the packets I'm never getting, then I need to understand where the bottleneck is.

If I run rtlamr without parameters, the error line shows rate=2330624 and htop shows it using 103% of one core, of the 4 cores this pi4 has. The overall cpu usage is topping out at 1.73 with a background program, motion watching 4 cameras.

Adding -msgtype all , the rate drops to 1425408 and cpu usage may go up to 2.3. Correct me where I'm wrong, that seems like the cpu is not the bottleneck.

Using rtl_power, capturing and converting to graphic png, I can see the data from my power meter I aim to convert to text. But I never get any data lines.
Thank you

[bemasher]

@seahorse41 that almost certainly means your CPU is the bottleneck. A Pi4 can handle SCM/SCM+/IDM, but will struggle with R900 added to those.

[seahorse41]

@bemasher I started a discussion like you recommended elsewhere for possibly unsupported meters, and set up a different pi4b only 10 ft from the meter, to rule out distance and reception as possible reason to be not getting results. Now with no other programs running, the "not keeping up" message does not appear until after 25 minutes elapse. then 97 errors in 7 minutes, then quiet and working fine again, this time for 8 minutes, and somewhat repeats.
Load is 0.32 and top thread up to 34%. Still CPU? Seems like there is something to explore here.

I included -samplefile=amr-out.bin but that file is 0 bytes.

Should I set up a full size AMD desktop/tower for more power, or does it look like something else is failing to decode?

[Jarosze]

Hello All,,

Same issue for me. I reverted back to the previous version of rtlamr, v0.9.1 dated 20-Sep-2018. Working fine now. Also noticed the 0.9.1 version is 2.4 meg,, where as th 0.9.5 version is 4.4 meg..

Thanks Ken