1. main@DVSwitch.groups.io

Re: Reliable Transcoding with Brandmeister DMR - Who and How?

Patrick Perdue
 

Hi:

Sounds like you're connecting DVSwitch to both Brandmeister and your XLX reflector. Is that correct?

On my system, using an XLX Interlink from Brandmeister 3101, and a remote transcoder that isn't too far from the datacenter where the reflector lives, I can leave things untouched for months. DVSwitch is only used to connect between my HBlink and Allstar. HBlink is bridging between both Prime and legacy TGIF, and XLX reflector 679, which is also hosting YSF, Peanut and Brandmeister on module A, as well as a couple of links from other systems. In other words, DVSwitch doesn't directly care about my XLX reflector, and Brandmeister is getting into the system through XLX Interlink on 3101 rather than connecting via DVSwitch or HBlink. If I take DVSwitch and HBlink out of the loop, I still have Brandmeister, YSF, Peanut and DStar interconnected.

My YSF reflector is hosted directly by XLXD, not an external process, with autolink compiled to connect YSF clients to module A.

All this is running extremely stable, but, yes, things do fall over when/if the ambed transcoder breaks, for example, if my home internet goes down, but I don't need to restart the reflector or the transcoder when it comes back online. Things just start working again.
I am eventually going to take the transcoders away from the XLX reflector, and assign one vocoder dongle to a second instance of DVSwitch so I can avoid a layer of transcoding between Allstar and DStar. Currently, stations that are communicating between these two modes have AMBE transcoding between the two endpoints. I've avoided doing this before due to losing metadata, which the DStar users, especially, would complain about, but analog reflector should fix that. Plus, there are far fewer DStar users on my system than DMR.

I don't know if any of this helps, but that's what I'm doing here.

On 3/2/2021 6:45 PM, J M wrote:
I'm back again and still looking for someone who can share some best practices for reliable transcoding with BrandMeister DMR. I realize this is not an XLX/Ambed support forum, but I think this description of the problem will help explain my struggle so please indulge me. I"ve searched in the messages, Wiki, and the Google machine in vain for a solution to my problem.

I run XLX330/YSF #83603 which is also transcoded to BM TG 311070. I have a consistent repeatable problem with BrandMeister DMR completely locking up xlxd/ambed when there is any sort of not-trivial communication stream (e.g. a net with a number of DMR users). A set of D-STAR and YSF users can talk forever without a hiccup. During a multi-mode net without fail, right in the middle of a DMR transmission coming into xlxd from BrandMeister, xlxd will start throwing errors like:

 

Feb 22 20:18:23 localhost xlxd: Opening stream on module A for client BM3103   with sid 34594
Feb 22 20:18:31 localhost xlxd: Closing stream of module A
Feb 22 20:18:31 localhost xlxd: ambed 1452 of 306 packets timed out
Feb 22 20:18:31 localhost ambed[5539]: Vocodec channel DVstick-33:1 -> DVstick-33:0 closed
Feb 22 20:18:31 localhost ambed[5539]: 0 of 306 packets lost
Feb 22 20:18:31 localhost ambed[5539]: Stream 18 closed
It is ALWAYS on a DMR connection this begins. After that, every subsequent transmission regardless of mode is broken. Every repeater that didn't have the originating RF traffic shows only a 0.1s transmission with no audio and the logging is always the "X of Y packets timed out" error. The only resolution is to restart both ambed and xlxd. The problem has never started with a YSF or D-STAR transmission, always and only DMR. I've tried putting MMDVM_Bridge/DVSwitch in the middle a few time, trying first to "unload" processing of YSF to a YSFReflector joined through MMDVM_Bridge. Then I tried using MMDVM_Bridge to interface with a DMRGateway process. Whatever the issue is, the root cause appears to be BM DMR traffic being processed with xlxd/ambed. So I'm trying to find another, reliable way.

When I was using xlx + MMDVM_Bridge + DMRGateway the lockup didn't occur but that was because there was a different problem. At the tail end of any RF transmission into a DMR repeater, the DMR repeater would then "hear" an echo from DMR network of the same transmission and then lock open with a "Net" transmission (Pi-Star) which would hang the repeater open until some 60-second timer seemed to trip. I tried fiddling with the hangTimerInFrames inside of DVSwitch.ini but that did not seem to make any difference.

So, if you read this far, I REALLY appreciate your reading to the end and would appreciate info from anyone who's linking with BrandMeister. I'm open to making any needed change to the environment to get it all working and stable. Only need is continue to use xlxd for D-STAR.

Thanks!
Jason N8EI

Join main@DVSwitch.groups.io to automatically receive all group messages.