A bit more now the I’m on a real computer. The way those streams get processed on the TX side, I’ve not found a really efficient way to terminate them with the call end. The efficient place would be right before the stream metadata is used for forwarding, necessitating another check fo the same condition again after forwarding… I’m trying to find a better way, but letting them timeout isn’t a problem. It just keeps entries in a list a few seconds longer.
On Jan 14, 2019, at 4:26 PM, Cort N0MJS via Groups.Io <n0mjs@...
Not an error. TX streams have to time out for not. There’s no explicit end for OBP TX streams yet
Cort - great stuff I just switched over so the stack now looks like this (for those that care)
DMRLink <-> IPSC_Bridge <-> HB_Bridge <-> hblink3(bridge) <-> Analog_Bridge <-> ASL
On a separate note, I noted a an error in the log specifically related to openbridge (outbound only connections) looks like it's not registering that the END event has occurred when it happens and thusly it times out?. Posting here but hopefully I can post a pull request if ever I get time to debug at all.
INFO 2019-01-14 14:16:30,526 (ANALOG_BRIDGE) *CALL END* STREAM ID: 2752969323 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.02
INFO 2019-01-14 14:16:35,780 (OBP-3103) *TIME OUT* STREAM ID: 2752969323 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.02
INFO 2019-01-14 14:19:21,827 (ANALOG_BRIDGE) *CALL START* STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1
INFO 2019-01-14 14:19:21,878 (ANALOG_BRIDGE) Conference Bridge: 310815, Call Bridged to OBP System: OBP-3103 TS: 1, TGID: 310815
INFO 2019-01-14 14:19:24,859 (ANALOG_BRIDGE) *CALL END* STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.03
INFO 2019-01-14 14:19:30,780 (OBP-3103) *TIME OUT* STREAM ID: 205043449 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.03
On Fri, Jan 11, 2019 at 11:04 AM Cort N0MJS via Groups.Io <email@example.com
PYTHON2 BASED VERSIONS OF HBLINK AND DMR_UTILS ARE NOW SUNSET – ONLY BUG FIXES WILL BE OFFERED.
If you go looking at my repos on GitHub, you’ll see a couple of new things:
HBlink3 and dmr_utils3
These are Python3 versions of HBlink and dmr_utils. Currently, dmr_utils3 does not include ambe_bridge.py and HBlink3 does not include parrot or bridge_all – effectively leaving it as the base stack and the conference bridge application… there have also been some things renamed. I removed “hb_” from the beginning of all of the files, and I also renamed hb_confbridge.py to bridge.py. Likewise I renamed hb_confbridge_rules.py to rules.py. The main goal with the name changes is to make the first character or few unique. I’m a shitty typist to begin with, so being able to type b(tab) and get bridge.py is a lot easier than having to type out hb_confbridge.py all of the time… and I have to type those things a lot when I’m in full-on coding mode :)
As for the future of the other HBlink programs – some of that is going to be dependent on community support. I would love to see someone step up and port all_bridge.py and parrot.py to Python3. I will eventually get to them, but not soon because….
The master branch of HBlink3 is stable and has been running on the K0USY Group’s “KS-DMR” network all week. On our particular system, with the things we have configured, just moving to Python3 (ok, a few bits of refactoring as well) has given us a 15-20% performance boost (measured in time between packet ingress and processing completion). You will also notice another branch of HBlink3 called uvloop. With this branch I’m swapping out the venerable Twisted module for Python3’s built-in Asyncio module, and a “drop in replacement” for portions of it called uvLoop, an ultra-fast drop-in replacement for parts of Asyncio… just moving to Python3 gave us a nice bump. My hope is that the move to uvloop makes HBlink work much faster – potentially rivaling statically compiled to machine-code software.
I’ve already moved off of the master branch to work on the uvloop branch. This development will be rapid – because the goal is to have hblink.py and bridge.py working on uvloop ASAP. Once that is completed, I will go back and start filling in the gaps as well as adding features. I do not intend to back-port new features to the Python2 versions.
0x49 DE N0MJS