Date   

Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

Mike Zingman - N4IRR
 

This is just an informational message.  The message is a result of adding a new event type to several of the modes. Please ignore it. I will fix the message in the next release. 


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

Heiko DL1BZ
 

NXDN unknown tag (13) in TVL
same here since last version of mmdvm_bridge. Don't know if it's important. All works ok.

73 Heiko, DL1BZ


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

David Young
 

Steve,
Ok, I put one server running P25 and NXDN with bridging to hblink3 master hub back to the stock versions of Analog_Bridge V161 and MMDVM_Bridge V163.  So far after turning on the Analog_Bridge logging to #2 I am not getting the redundant messages.  This could have been my mistake when initially setting up the bridge as I forgot that the one instance of Analog_Bridge auto starts and I probably started it a second time, or maybe one of the updates fixed this problem.
The high CPU usage usually takes almost an hour before it starts to jump up from 5%.  So you might let it go over night.
Here is an error message I am getting when starting the MMDVM_Bridge for NXDN which is the second bridge so it doesn't auto start and I start it manually.  See the MMDVM_Bridge log file, the last entry after successful connection to the master.
"E:  NXDN unknown tag (13) in TVL"  if I use MMDVM_Bridge V162, this error does not appear.  Don't know if this is important to the operation, as the bridge works ok.
--
Dave WB6DTB


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

Steve N4IRS
 

Correct

On 3/28/21 9:03 PM, Komkit Listisard via groups.io wrote:
I have the similar error as well.

One question tho,  I am just bridge XLX (DMR)  <-> YSF, I only need to install just MMDVM_Bridge correct?

73, Kit


M: 2021-03-28 02:38:09.323 Removing ▒▒i▒RV (144.121.98.161:32780) unlinked

free(): double free detected in tcache 2
I: 2021-03-28 02:52:28.148 Opening YS


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

Komkit Listisard
 

I have the similar error as well.

One question tho,  I am just bridge XLX (DMR)  <-> YSF, I only need to install just MMDVM_Bridge correct?

73, Kit


M: 2021-03-28 02:38:09.323 Removing ▒▒i▒RV (144.121.98.161:32780) unlinked

free(): double free detected in tcache 2
I: 2021-03-28 02:52:28.148 Opening YS


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

Steve N4IRS
 

General comments:
The gateway code installed is directly from G4LKX github repositories. The only difference beween the "old stretch and the "new buster" repositories is the words stretch and buster. Each of the programs have been brought forward.

I see this in the YSFReflector log:
M: 2021-03-28 01:39:02.130 Removing WB6DTB     (80.191.195.172:4260) disappeared
free(): double free detected in tcache 2
Lots of hits on this. For example <https://stackoverflow.com/questions/57616404/what-does-it-mean-double-free-detected-in-tcache-2-while-using-mpz>

I would like to see a sample of this:
Also needed to turn off Analog_Bridge logging as I was getting continuous messages in the Analog_Bridge log file stating successful running of something (can't remember), but was filling up the allotted memory if I did not stop the logging.

I'll have to test this:
Also have noticed by looking at the server stats that when using Analog_Bridge version 1.6.1 that if I use it as the second Analog_Bridge needed for P25 to DMR (creating a separate executable and .ini file that my CPU stats go way up over 50%, so switching the second Analog_Bridge executable with version 1.4.2 does not cause the high CPU usage.

Steve N4IRS

On 3/28/21 7:50 PM, David Young wrote:
Steve,
Ok, let me start with the YSF Reflector error.  Attached is the reflector log file from 3/27/21 which shows the error message occurring approximately 4 full screens from the top of the file.  I have 3 servers running XLX and YSF and bridges from them to our hblink3 hub.  All 3 YSF Reflectors at sometime from startup will fail with that double clear error.  Each reflector may run for 1 plus hours or more or may run for 1 to 3 days, but at some point this error occurs and they shutdown.  Using the latest YSFReflector code from github.
The P25 and NXDN reflector errors are somewhat similar in that they will startup and run and bridge to the master hub.  Again we are using the latest versions of reflector code from github (G4KLX).  I don't have any log files which show they stop working, but what seems to occur is at the same frequency as above for YSF reflector, they will stop responding.  I know that the Gateways are still working as restarting the gateway does not restart the connection to the master.  The MMDVM_Bridge is still running as well.  To get the reflector to start bridging again, I need to execute the P25Reflector.sh and do a 'reload' which stops the reflector and then do a start.  Sometimes on the NXDN reflector when it stops if I just do the script command "NXDNReflector.sh start /etc/NXDNReflector.ini &" I get a message that the reflector is already running.  But no connection can be made to the reflector, so I just do the reload and then start command and all is well again, so the gateway and MMDVM_Bridge do not appear to be the problem, only the reflectors.  Again we are running three sets of P25 and NXDN reflectors with bridging on three individual servers.  The reflector logs do not show any problem or error message.  I have tried both the DVSwitch installed gateway code and also the gateway code from github wihich is a later version by date, but neither makes any difference.  Also I have tried different versions of Analog_Bridge for the P25 and different versions of MMDVM_Bridge for both P25 and NXDN, but as above I don't think these affect the problem.  I can send my .ini files if you want to see them.  Sometimes either the P25 or NXDN bridge will instead of stopping will have a extremely long latency, which listening on the DMR side of the bridge will sound like a 78 speed record running at 33.3 speed.  Again, just by issuing a P25 or NXDN script reload and then restart this problem disappears until sometime later.  All this has happened since we decided to move all our reflectors and bridges to new cloud servers (cheaper cost).  Did not have these problems with the original servers which were using the older DVSwitch modules.  Now we are using the DVSwitch-Server modules (not saying that DVSwitch is the problem, just trying to figure out what has changed).  Using the same server provider, just downsizing from 4 core to 2 core with less hard drive space needed.
Also have noticed by looking at the server stats that when using Analog_Bridge version 1.6.1 that if I use it as the second Analog_Bridge needed for P25 to DMR (creating a separate executable and .ini file that my CPU stats go way up over 50%, so switching the second Analog_Bridge executable with version 1.4.2 does not cause the high CPU usage.  Also needed to turn off Analog_Bridge logging as I was getting continuous messages in the Analog_Bridge log file stating successful running of something (can't remember), but was filling up the allotted memory if I did not stop the logging.  
Sorry for the long book.
--
Dave WB6DTB


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

David Young
 

Steve,
Ok, let me start with the YSF Reflector error.  Attached is the reflector log file from 3/27/21 which shows the error message occurring approximately 4 full screens from the top of the file.  I have 3 servers running XLX and YSF and bridges from them to our hblink3 hub.  All 3 YSF Reflectors at sometime from startup will fail with that double clear error.  Each reflector may run for 1 plus hours or more or may run for 1 to 3 days, but at some point this error occurs and they shutdown.  Using the latest YSFReflector code from github.
The P25 and NXDN reflector errors are somewhat similar in that they will startup and run and bridge to the master hub.  Again we are using the latest versions of reflector code from github (G4KLX).  I don't have any log files which show they stop working, but what seems to occur is at the same frequency as above for YSF reflector, they will stop responding.  I know that the Gateways are still working as restarting the gateway does not restart the connection to the master.  The MMDVM_Bridge is still running as well.  To get the reflector to start bridging again, I need to execute the P25Reflector.sh and do a 'reload' which stops the reflector and then do a start.  Sometimes on the NXDN reflector when it stops if I just do the script command "NXDNReflector.sh start /etc/NXDNReflector.ini &" I get a message that the reflector is already running.  But no connection can be made to the reflector, so I just do the reload and then start command and all is well again, so the gateway and MMDVM_Bridge do not appear to be the problem, only the reflectors.  Again we are running three sets of P25 and NXDN reflectors with bridging on three individual servers.  The reflector logs do not show any problem or error message.  I have tried both the DVSwitch installed gateway code and also the gateway code from github wihich is a later version by date, but neither makes any difference.  Also I have tried different versions of Analog_Bridge for the P25 and different versions of MMDVM_Bridge for both P25 and NXDN, but as above I don't think these affect the problem.  I can send my .ini files if you want to see them.  Sometimes either the P25 or NXDN bridge will instead of stopping will have a extremely long latency, which listening on the DMR side of the bridge will sound like a 78 speed record running at 33.3 speed.  Again, just by issuing a P25 or NXDN script reload and then restart this problem disappears until sometime later.  All this has happened since we decided to move all our reflectors and bridges to new cloud servers (cheaper cost).  Did not have these problems with the original servers which were using the older DVSwitch modules.  Now we are using the DVSwitch-Server modules (not saying that DVSwitch is the problem, just trying to figure out what has changed).  Using the same server provider, just downsizing from 4 core to 2 core with less hard drive space needed.
Also have noticed by looking at the server stats that when using Analog_Bridge version 1.6.1 that if I use it as the second Analog_Bridge needed for P25 to DMR (creating a separate executable and .ini file that my CPU stats go way up over 50%, so switching the second Analog_Bridge executable with version 1.4.2 does not cause the high CPU usage.  Also needed to turn off Analog_Bridge logging as I was getting continuous messages in the Analog_Bridge log file stating successful running of something (can't remember), but was filling up the allotted memory if I did not stop the logging.  
Sorry for the long book.
--
Dave WB6DTB


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

Steve N4IRS
 

Dave,
If there is interaction it with XLX it's between XLX and ircDDBGateway. XLX and IRCDDBGateway will not run on the same host. I have multiple P25Reflectors (3) multiple NXDNReflectors (2) and multiple YSFReflectors (2) running with NXDNGateway, P25Gateway and YSFGateway. MMDVM_Bridge Analog_Bridge, Analog_Reflector. DVSwitch is a name of the overall project built out of the components. Most of the problems people have are in the port numbers. There is no significant difference between the "Stretch Version" and the "Buster Version" If You are having problems I would like to see the logs where the issues shows up.

Steve N4IRS    

On 3/28/21 5:44 PM, David Young wrote:
Hi Kit,
My guess, it is related to the new DVSwitch.  I also am running both YSF Reflector and XLX reflector on the same server.  XLX would not run as DVSwitch was opening some of the ports for itself that XLX needed.  I uninstalled DVSwitch which still allows the use of MMDVM_Bridge to bridge both YSFReflector and XLXReflector to a master hub, in my case hblink3.  The buster repository though is still installed on the server.  I have been running 3 different YSFReflectors in the past without that error ever occurring, all coexisting with the older stretch version of DVSwitch.  I think it is related to DVSwitch as I have also been having problems with P25 and NXDN Reflectors coexisting with the new DVSwitch buster version.  One time I did see that same double free detected error when my P25 Reflector shutdown.
I would like to go back to the stretch version of DVSwitch but that link is no longer available.  I was hoping Steve would bring back that link so we could test to see if the error message occurs now with the older DVSwitch stretch version.  If so, then we would feel better about posting to G4KLX concerning this problem.

--
Dave WB6DTB


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

David Young
 

Hi Kit,
My guess, it is related to the new DVSwitch.  I also am running both YSF Reflector and XLX reflector on the same server.  XLX would not run as DVSwitch was opening some of the ports for itself that XLX needed.  I uninstalled DVSwitch which still allows the use of MMDVM_Bridge to bridge both YSFReflector and XLXReflector to a master hub, in my case hblink3.  The buster repository though is still installed on the server.  I have been running 3 different YSFReflectors in the past without that error ever occurring, all coexisting with the older stretch version of DVSwitch.  I think it is related to DVSwitch as I have also been having problems with P25 and NXDN Reflectors coexisting with the new DVSwitch buster version.  One time I did see that same double free detected error when my P25 Reflector shutdown.
I would like to go back to the stretch version of DVSwitch but that link is no longer available.  I was hoping Steve would bring back that link so we could test to see if the error message occurs now with the older DVSwitch stretch version.  If so, then we would feel better about posting to G4KLX concerning this problem.

--
Dave WB6DTB


Re: Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

Komkit Listisard
 

Dave,  I am following this.  I run into the same YSFReflector throwing " free(): double free detected in tcache 2." very often.  I have no idea  what was the problem.

I opened the issue on G4KLX under YSFClients github as I have no idea where to ask about what this error is all about. If you would add your issue on the list, the issue might have a chance to get some attention.  At least I hope to know what the error mean.

I do not know if it was DVSwitch related or not,  I have 2 YSF reflectors running.  One with XLX and the other stand alone just YSFReflector only no DVSWitch and I do recall I have seen the same error on both reflectors.

For the XLX server I am using MMDVM_Bridge service only just to bridge DMR <-> YSF, I disabled everything else.  If I did not disable what I do not use on DVSWitch, they will be fighting over the ports.  

73, Kit


Re: DV switch to ASL 2.0 beta 6

Pete Fierro <overthetop52@...>
 

Thanks alot Steve...That did it

Be well
Pete
KD2ARB 



On Fri, Mar 26, 2021 at 13:42, Steve N4IRS
<szingman@...> wrote:
The buster script is a good source of info.

Thanks, Steve

On 3/26/2021 1:40 PM, me@... wrote:
I'll make sure the DVSwitch repo is added in our next release so our beta users can start testing DVSwitch on the new beta. Steve, send me an e-mail if you have recommendations otherwise I'll use the data from that script.

Cheers!
Rob
KK9ROB


locked Re: Shaming for using an app

IK7VXC Mike
 

Alright then, Steve, thanks for letting me know this (I was already poking around :) ).


Problem running new DVSwitch on same server as XLX, YSF, P25 or NXDN reflectors

David Young
 

Having problems running the new DVSwitch modules on same server as these reflectors.
XLX problem:  using buster repository and DVSwitch, XLX cannot open the key UDP ports as DVSwitch seems to be using them.  Un-installed DVSwitch and XLX then can open it's required ports.
YSF Reflector problem:  Again using buster repository and DVSwitch modules, randomly, reflector shuts down.  Sometimes runs for hours, sometimes for a day or two between failures.  YSFReflector log shows error message:  free(): double free detected in tcache 2.
P25 and NXDN Reflectors:  same as YSFReflector but do not see the same error message but the reflectors will shutdown and require to manually perform a reload then restart of the Reflector run scripts provided by G4KLX from his github link.
On P25 and NXDN reflectors have tried using DVSwitch-Server and then backed off that and am currently using just DVSwitch without the dashboard.
Ideas???
--
Dave WB6DTB


Re: MMDVM_Bridge Crashes as part of P25 <-> DMR link #mmdvm_bridge

Andrew Lynch
 

MMDVM_Bridge version 20210309_V1.6.4 git #5142ba0
P25Reflector version 20210213

It's the 707 Rural MN reflector, 707p25.kd0ioe.com:41000

Thanks!
-Andy

On Sat, Mar 27, 2021 at 8:37 PM Steve N4IRS <szingman@...> wrote:
Send me the info on the reflector (IP and Port) I can setup a system to capture the data before the crash.

On 3/27/21 8:33 PM, Andrew Lynch wrote:
Good evening,

I had a chance to start gathering more info this evening from a couple sources and watched logs to see when it was occuring. I currently have a working P25 <-> MMDVM_Bridge/Analog_Bridge <-> DMR setup with all the ports and transcoding working fine. Hotspot P25 users connect to the reflector just fine and are able to communicate with DMR users. There is one repeater system that is linked via P25Link into that reflector, and traffic from that source causes MMDVM to restart midway through the conversation. There is no error entry (I turned on all the debugging), MMDVM_Bridge simply restarts, reconnects, and picks up roughly where it left off. The P25Reflector doesn't restart or indicate any issues. 

Are there known issues with MMDVM_Bridge restarting or any further debugging that would be helpful to identify the source of the restart? I have the captured logs to share if someone would find them useful. One is all raw P25Reflector debug data, the other is MMDVM_Bridge's logs at reset.

Thanks!
-Andy, KDØIOE



--
Andrew Lynch (KDØIOE)
lurch89@... | https://kd0ioe.com/


Re: MMDVM_Bridge Crashes as part of P25 <-> DMR link #mmdvm_bridge

Steve N4IRS
 

Send me the info on the reflector (IP and Port) I can setup a system to capture the data before the crash.

On 3/27/21 8:33 PM, Andrew Lynch wrote:
Good evening,

I had a chance to start gathering more info this evening from a couple sources and watched logs to see when it was occuring. I currently have a working P25 <-> MMDVM_Bridge/Analog_Bridge <-> DMR setup with all the ports and transcoding working fine. Hotspot P25 users connect to the reflector just fine and are able to communicate with DMR users. There is one repeater system that is linked via P25Link into that reflector, and traffic from that source causes MMDVM to restart midway through the conversation. There is no error entry (I turned on all the debugging), MMDVM_Bridge simply restarts, reconnects, and picks up roughly where it left off. The P25Reflector doesn't restart or indicate any issues. 

Are there known issues with MMDVM_Bridge restarting or any further debugging that would be helpful to identify the source of the restart? I have the captured logs to share if someone would find them useful. One is all raw P25Reflector debug data, the other is MMDVM_Bridge's logs at reset.

Thanks!
-Andy, KDØIOE


Re: MMDVM_Bridge Crashes as part of P25 <-> DMR link #mmdvm_bridge

Steve N4IRS
 

This is the first I've head of it. Not that I think it matters, what is the version of MMDVM_Bridge. If it's something P25Link is sending, it's going to be hard to troubleshoot.

Steve N4IRS

On 3/27/21 8:33 PM, Andrew Lynch wrote:
Good evening,

I had a chance to start gathering more info this evening from a couple sources and watched logs to see when it was occuring. I currently have a working P25 <-> MMDVM_Bridge/Analog_Bridge <-> DMR setup with all the ports and transcoding working fine. Hotspot P25 users connect to the reflector just fine and are able to communicate with DMR users. There is one repeater system that is linked via P25Link into that reflector, and traffic from that source causes MMDVM to restart midway through the conversation. There is no error entry (I turned on all the debugging), MMDVM_Bridge simply restarts, reconnects, and picks up roughly where it left off. The P25Reflector doesn't restart or indicate any issues. 

Are there known issues with MMDVM_Bridge restarting or any further debugging that would be helpful to identify the source of the restart? I have the captured logs to share if someone would find them useful. One is all raw P25Reflector debug data, the other is MMDVM_Bridge's logs at reset.

Thanks!
-Andy, KDØIOE


MMDVM_Bridge Crashes as part of P25 <-> DMR link #mmdvm_bridge

Andrew Lynch
 

Good evening,

I had a chance to start gathering more info this evening from a couple sources and watched logs to see when it was occuring. I currently have a working P25 <-> MMDVM_Bridge/Analog_Bridge <-> DMR setup with all the ports and transcoding working fine. Hotspot P25 users connect to the reflector just fine and are able to communicate with DMR users. There is one repeater system that is linked via P25Link into that reflector, and traffic from that source causes MMDVM to restart midway through the conversation. There is no error entry (I turned on all the debugging), MMDVM_Bridge simply restarts, reconnects, and picks up roughly where it left off. The P25Reflector doesn't restart or indicate any issues. 

Are there known issues with MMDVM_Bridge restarting or any further debugging that would be helpful to identify the source of the restart? I have the captured logs to share if someone would find them useful. One is all raw P25Reflector debug data, the other is MMDVM_Bridge's logs at reset.

Thanks!
-Andy, KDØIOE


Re: DVS install on Hytera PNC380 ?

Mike Zingman - N4IRR
 


Re: DVS install on Hytera PNC380 ?

Allister
 

Hi Mike, 

yes I did that .
I have the android DVS app installed on a Tokie TK-100 and Samsung mobile phone, both working very well and have tried to replicate the settings with the PNC380 but having no luck so far ......

Any pointers most welcome ! 

Regards Allister GM7RYR  


locked Re: Shaming for using an app

Steve N4IRS
 

Mike,
No, you can't change it yourself. Yes, bugs are usually a higher priority then enhancements.

Steve N4IRS

On 3/27/21 12:50 PM, IK7VXC Mike wrote:
Thanks for all the replies, I appreciate it (sorry Steve). I can understand there are more inportant issues to solve (I know, mine is a minor one, I get it). However if some of you could give me some pointers on where to look, I would gladly try and see if I can "fix" the thing myself.

Mike IK7VXC

781 - 800 of 9797