D-Star traffic fails if transcoder fails

[yo2loj]

I have seen this issue twice.
I have 2x DVsick33 setup as a transcoder in my home, while the actual reflector sits in a data center.
Sometimes the transcode to accept the transcoding, entering some kind of fail state. On the transcoder side, the streams show up, but there is an error on the XLX side.

Under these conditions, only the D-Star headers are sent by the XLX, while the actual DV stream is missing (at least in Dextra and Dplus). This manifests itself as nothing to be heard, with a short appearance of the callsign data at the end of transmission.
After transcoder software restart, everything returns to normal.

I haven't had the time to pursue this issue deeper, but shouldn't the reflector function normally and just ignore transcoding failures, while keeping up regular client to client D-star reflector traffic?

Log of the moment the failure appears:
Jun 24 01:18:18 vps62907 xlxd: Opening stream on module C for client DONGLE B with sid 58321
Jun 24 01:18:27 vps62907 xlxd: Closing stream of module C
Jun 24 01:18:27 vps62907 xlxd: ambed stats (ms) : 0.0/45.3/58.8
Jun 24 01:18:32 vps62907 xlxd: ambed openstream ok
Jun 24 01:18:32 vps62907 xlxd: Opening stream on module C for client DONGLE B with sid 57167
Jun 24 01:19:01 vps62907 xlxd: Closing stream of module C
Jun 24 01:19:01 vps62907 xlxd: ambed stats (ms) : 0.1/46.1/58.3
Jun 24 01:19:01 vps62907 xlxd: ambed 10 of 1452 packets timed out
Jun 24 01:19:13 vps62907 xlxd: ambed openstream ok
Jun 24 01:19:13 vps62907 xlxd: Opening stream on module C for client DONGLE B with sid 22251
Jun 24 01:20:10 vps62907 xlxd: Closing stream of module C
Jun 24 01:20:10 vps62907 xlxd: ambed stats (ms) : 0.1/45.5/62.4
Jun 24 01:20:10 vps62907 xlxd: ambed 5713 of 2808 packets timed out
Jun 24 01:20:17 vps62907 xlxd: ambed openstream ok
Jun 24 01:20:17 vps62907 xlxd: Opening stream on module C for client DONGLE B with sid 50100
Jun 24 01:21:31 vps62907 xlxd: Closing stream of module C
Jun 24 01:21:31 vps62907 xlxd: ambed 14271 of 3648 packets timed out
Jun 24 01:21:36 vps62907 xlxd: ambed openstream ok
Jun 24 01:21:36 vps62907 xlxd: Opening stream on module C for client DONGLE B with sid 36732
Jun 24 01:22:09 vps62907 xlxd: Closing stream of module C
Jun 24 01:22:09 vps62907 xlxd: ambed 6294 of 1626 packets timed out

[sm0tsc]

I experience the same.. I have not logged it yet.. Setup is the same with XLX server in Datacenter and ambeD on another site...
//SM0TSC

[ik5xmk]

Hi,

when you have this:
Jun 24 01:20:10 vps62907 xlxd: ambed 5713 of 2808 packets timed out

so (X packets) > (Y packets) timed out you need to restart AMBE server side (not xlxd). No other way i know. Is it possible to implement something in the code that does this automatically? Otherwise, transcoding is blocked, creating inconvenience between the various connected protocols.

Thank you, 73
David IK5XMK

[vk4tux]

Just setup a watchdog script for it monitoring the ambed log. This would never happen on a localhost system with DVSI.

…

On 8/12/19 3:45 am, ik5xmk wrote: Hi, when you have this: Jun 24 01:20:10 vps62907 xlxd: ambed 5713 of 2808 packets timed out so *(X packets) > (Y packets) timed out* you need to restart AMBE server side (not xlxd). No other way i know. Is it possible to implement something in the code that does this automatically? Otherwise, transcoding is blocked, creating inconvenience between the various connected protocols. Thank you, 73 David IK5XMK — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#128?email_source=notifications&email_token=ACCUMYEN6VU4ORH4OKX4MHTQXPONPA5CNFSM4H4AO552YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGL2YY#issuecomment-562871651>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCUMYEOLC7FBOJYRQ2RPNTQXPONPANCNFSM4H4AO55Q>.

[ik5xmk]

I'm not sure that with a totally local system the problem can be definitively managed. I have tried with various ThumbDV and DV3x USB dongles also on the same server and now with two Baofarm cards.
This loss of synchronization can also occur with meetings of different protocols, overmodulation, bad client data connections, etc.
Log control is certainly a viable method, but perhaps a control protocol between xlx and its ambe server could also be used, regardless of whether it can be installed.
Thanks, I try this suggestion. Many 73.

[vk4tux]

I use 2 x 3006 and 2 x dvstick33, all genuine DVSI 3003 1MBaud rate chips,on a local host system here with PC server for XLX389 with usb transcoders attached. I never had your issue with ambed. root@XLX389:/var/www/db/pgs# cat /ambed/run #!/bin/bash # start ambed server sudo rmmod ftdi_sio sudo rmmod usbserial sudo /ambed/ambed 127.0.0.1 >/var/log/ambed.log & so with ambed.log you can monitor ; You can setup /usr/bin/ambechk.sh and run every minute from root crontab ; .................................................................................................................. #!/bin/bash sleep 5 PATTERN=timed FILE=/var/log/ambed.log if grep -q $PATTERN $FILE;  then      echo "ambed timeout error"      > /var/log/ambed.log      /usr/sbin/service ambe restart <<<<<<<<<<<< replace with your ambe start script/service etc..  else      echo "all ok"      echo "Exiting..."      exit 0 fi ................................................................................................................ Adrian ... vk4tux

…

On 8/12/19 5:27 am, ik5xmk wrote: I'm not sure that with a totally local system the problem can be definitively managed. I have tried with various ThumbDV and DV3x USB dongles also on the same server and now with two Baofarm cards. This loss of synchronization can also occur with meetings of different protocols, overmodulation, bad client data connections, etc. Log control is certainly a viable method, but perhaps a control protocol between xlx and its ambe server could also be used, regardless of whether it can be installed. Thanks, I try this suggestion. Many 73. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#128?email_source=notifications&email_token=ACCUMYAFKFOHWBGEZ2N6IUTQXP2LJA5CNFSM4H4AO552YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGNW5Y#issuecomment-562879351>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCUMYB36J5M2SH2GYGCD6DQXP2LJANCNFSM4H4AO55Q>.

[vk4tux]

Yes, well you can't beat a localhost connection, but I know this is not always possible, but every effort should be made to use a physical hardware server.

…

On Fri, 28 Jun. 2019, 7:50 am Marius Petrescu, YO2LOJ, < ***@***.***> wrote: I have seen this issue twice. I have 2x DVsick33 setup as a transcoder in my home, while the actual reflector sits in a data center. Sometimes the transcode to accept the transcoding, entering some kind of fail state. On the transcoder side, the streams show up, but there is an error on the XLX side. Under these conditions, only the D-Star headers are sent by the XLX, while the actual DV stream is missing (at least in Dextra and Dplus). This manifests itself as nothing to be heard, with a short appearance of the callsign data at the end of transmission. I haven't had the time to pursue this issue deeper, but shouldn't the reflector function normally and just ignore transcoding failures, while keeping up regular D-star traffic? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#128?email_source=notifications&email_token=ACCUMYAZHWA4KLGFP4BA2ITP4UY4FA5CNFSM4H4AO552YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G4F7JPQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCUMYED5ZDMZBTKBKXVOULP4UY4FANCNFSM4H4AO55Q> .