Search results

Thanks, not sure why I didn't think about this.

Greetings, I have a problem user that continuously reports my feed for every little thing, and most of the issues are on his end. Is there a way to block a user from reporting a feed? It's becoming borderline incessant. I don't get paid to babysit the feed and getting 10-12 e-mails a day about...

DNS is working fine. It’s an internal server issue. PING audio9.broadcastify.com (174.127.114.13): 56 data bytes 64 bytes from 174.127.114.13: icmp_seq=0 ttl=46 time=35.100 ms 64 bytes from 174.127.114.13: icmp_seq=1 ttl=46 time=35.313 ms 64 bytes from 174.127.114.13: icmp_seq=2 ttl=46...

Yeah, add me to the list - only frustrating thing is the people who use my feed continuously report the feed as not working, which is pretty obvious … lol

It’s streaming to broadcastify via a gigabit link (symmetrical) and running on a Jetson nano. Doesn’t seem to be the system that matters at all, as it also did it on an i5 7600. I’ll check and see if any added delay is in the json, I am pretty sure I removed it when I configured it.

Greetings, I am running OP25 Boatbod Master fork w/ Liquidsoap. I’ve had this issue before, and never did quite resolve it, it seemed to have fixed itself. Well, the issue is back. The alpha tags are working just fine, but they are way out of sync, and I can’t even figure out how out of sync...

Awesome, I have no idea why I didn’t think to just double up the .liq configuration … lol. Thanks, I’ll get working on that tomorrow and report back if I’ve got any issues.

Greetings, I’d like to provide two feeds off of the same instance of multi_rx. I already have two dongles, and a single feed already running. What’s required to get the second feed going? In theory I can of course use multi_rx to provide both feeds, but how do I run the output through liquid...

yes, one rtlsdr. I switched from rx to multi-rx due to stability issues, not because I needed to monitor more than one cch

(My old op25.sh, that I no longer use) ./rx.py --args "rtl" --gains 'lna:46' -S 960000 -T lake_trunk.tsv -v 2 -2 -V -w -M my_meta.json -l http:10.0.0.45:12345 2> stderr.2 meta.json { "icecastPass": "XXXXXXXXX", "icecastMountpoint": "XXXXXXXXXXX", "icecastServerAddress"...

Greetings, While in the course of diagnosing why the alpha tags were so out of sync (which I did figure out) — I noticed that there is a 1 1/2 minute delay on my feed. I do not have any artificial delays added anywhere that I know of, is this just some kind of buffering that LiquidSoap/Icecast...

Please disregard, the issue is with 5-0 scanner software, not my setup. The tags work great everywhere else.

Greetings, At one point the alpha tags were working just fine, but at some point they’ve gone AWOL. They work fine, but they are so badly delayed/out of sync that I can’t even begin to fathom what amount of delay to put into the “delay” section. Does anyone have any suggestions on how to figure...

We appreciate it, for sure.

Greetings, Looking through the logs I see a lot of 06/21/22 22:28:52.752365 [OH MARCS LAKE CTY] has no idle receivers for control channel monitoring — I know with rx.py there really isn’t much of an option to use a secondary receiver to track the control channel (nor is it needed) — but what...

Have you ever thought about writing a configuration script that could walk someone through most of the setup?

I wonder how many people are still using rx.py though? I was only using it due to legacy issues — I started using op25 back in roughly 2016 or so, back when it required a GUI and ran terrible lol

Yep, and now it’s a moot point, been rock solid for 2 days now, not to mention it motivated me to migrate to multi_rx which opens up more options in the future if I ever decide to monitor a DMR network, or someday you decide to add NXDN :)

I’d have to mess with it later, it’s running a broadcastify feed and people get cranky when I turn it off on Friday/Saturday nights lol. The LNA settings are the same on both, 39. I experimented with gain quite a bit w/ rx.py and never saw much of a difference aside from raising the noise floor...

Just an update — switched to multi_rx and it seems to have solved the issue.