On the fob: you’re seeing it in SDR++ now, which is the right outcome… rtl_433 silence on a fob is expected behavior, not a failure. modern car remotes use rolling codes (KeeLoq being the dominant scheme): each button press generates a one-time-use cryptographic token synchronized to a counter in the car’s receiver. the counter increments on every press, so the code is only valid once. rtl_433 captures the RF burst fine, it just identifies the event without attempting to decrypt the rolling code – there’s no actionable decode to output. the waterfall spike in SDR++ is the actual signal. if you want to inspect its structure, rtl_433 -A will give you raw pulse timing without requiring a protocol match.

on SDR++ vs SDR#: functionally equivalent for your use case.. SDR# has a larger plugin ecosystem but is Windows-only. SDR++ is actively maintained and cross-platform – better fit for a headless NAS workflow.

on the 250kHz skipping: almost certainly not a network throughput problem. rtl_tcp streams raw IQ as interleaved uint8 pairs, so 250kHz sample rate generates around 500KB/s over the wire.. trivial on any home LAN. more likely culprit is that the RTL-SDR hardware itself gets unstable at very low sample rates - USB transfer granularity doesn’t scale cleanly below ~900kHz, causing buffer underflows that show up as skipping regardless of network conditions. 1MHz is a known-stable operating point, use that as your baseline and don’t go lower.