[arm-allstar] Update V1.6-06 released

Fri Nov 22 10:14:25 EST 2019

After further experimentation, it seems that the streams hosted by nptee 
only break when traffic from DVSwitch (Analog_Bridge) hits the USRP 
driver. Native Allstar traffic is fine. So, I'm going to try isolating 
the A_B on it's own node. I bet that will fix it.
On 11/22/2019 8:45 AM, Patrick Perdue wrote:
> FWIW: I'm still getting some occasionally wonky audio with nptee 0.3 
> on VPS running stock ASL. I need to really run it through it's paces 
> on HamVoIP.
>
> Last night, one of my two ezstream instances proclaimed no (more) data 
> from standard input, while the other one was still going. This 
> happened after streaming for about 10 hours, with lots of traffic on 
> the Allstar node. Restarting ezstream fixed it. I left the other 
> instance running.
>
> I bring this up, because it seems to happen more frequently when 
> traffic is heavier, I.E. not as much time between transmissions. This 
> is probably not relevant, but something worth pointing out anyway.
>
>
> On 11/22/2019 7:49 AM, "David McGough via ARM-allstar" wrote:
>> Brad,
>>
>> Make sure to use nptee version 0.3 (or later). Earlier versions have 
>> a bug
>> that causes the audio stream to sound wonky every once in a while.
>>
>> You can see the version by just typing "nptee" at the bash prompt 
>> with no
>> other options...This prints the copyright/license info, too, of course.
>>
>> 73, David KB4FXC
>>
>>
>> On Thu, 21 Nov 2019, "Brad Trogdon via ARM-allstar" wrote:
>>
>>>> Question,
>>>>
>>> I recompiled and replaced nptee on two nodes.  one is working just 
>>> fine..
>>> The other will not restart its feed.
>>>
>>> I reverted back to the original nptee (same results) When I manually 
>>> run
>>> the command line it scrolls constantly the below message:
>>>
>>> *ezstream: Streaming from standard input*
>>>
>>> Also /tmp/status file contains:  Could not find "/tmp/outsound/pipe1".
>>>
>>> Initial install I had to manually create outsound directory. Now even
>>> when i create it gets deleted.
>>>
>>> Any pointers?
>>>
>>> -Brad
>>> W4INT
>>>
>>>> ------------------------------
>>>>
>>>> Message: 7
>>>> Date: Wed, 20 Nov 2019 21:15:23 -0500 (EST)
>>>> From: David McGough <kb4fxc at inttek.net>
>>>> To: "\"Patrick Perdue via ARM-allstar\"" <arm-allstar at hamvoip.org>
>>>> Subject: Re: [arm-allstar] Update V1.6-06 released
>>>> Message-ID:
>>>> <Pine.LNX.4.44.1911202053460.27393-100000 at goliath.inttek.net>
>>>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>>>>
>>>>
>>>> Interesting. While I went ahead and released that code, it hasn't been
>>>> exhaustively tested. Is this problem showing up on RPi (HamVoIP) or a
>>>> VPS?
>>>>
>>>> BTW, I did find one bug after the initial release, which has been
>>>> corrected. The code is here:
>>>>
>>>> https://hamvoip.org/downloads/nptee-v-0.3.tgz
>>>>
>>>> I'll test nptee here carefully in the next few days.
>>>>
>>>> 73, David KB4FXC
>>>>
>>>>
>>>> On Wed, 20 Nov 2019, "Patrick Perdue via ARM-allstar" wrote:
>>>>
>>>>> I've been streaming to two servers using ntpee since last night, and
>>>>> I've discovered an interesting thing.
>>>>>
>>>>> It seems that, every few minutes, now that the stream has been 
>>>>> running
>>>>> for a while, there is some kind of buffer under-rungoing on.
>>>>>
>>>>> Using my own icecast server at 64 kbps 8000 hz mp3, I noticed that 
>>>>> the
>>>>> stream gets closer and closer to real time as time goes on. 
>>>>> Eventually,
>>>>> it hits a certain point, and breaks down, like a really bad time
>>>>> compression algorithm, then recycles again, and all is well for a 
>>>>> while.
>>>>> Sometimes, it seems like the buffer is flushed at the next 
>>>>> transmission,
>>>>> but maybe that's coincidence.
>>>>>
>>>>> This happens at the same point in the stream from rpt.app for my
>>>>> broadcastify feed and my icecast mountpoint, taking into account the
>>>>> buffer time of Broadcastify. Thus, I can rule out buffering 
>>>>> between my
>>>>> client and the stream itself.
>>>>>
>>>>> Later, when I have time, I'm going to try running something through
>>>>> ntpee with time code to see if it is actually dropping samples.
>>>>>
>>>>>
>>>>> On 11/20/2019 1:11 PM, "Doug Crompton via ARM-allstar" wrote:
>>>>>
>>>>>> An update version 1.6-06 was released today.  It includes the binary
>>>> nptee
>>>>>> (Named Pipe Tee) and a howto at hamvoip.org on its use. This SW 
>>>>>> allows
>>>>>> multiple streams from Allstar (outstream command in rpt.conf) to
>>>> external
>>>>>> code such as lame and ezstream. It also decouples the external 
>>>>>> program
>>>> from
>>>>>> Allstar so that no interaction exists when restarting or rebooting.
>>>>>>
>>>>>> Also included is a new script called - echolink_permit_deny
>>>>>>
>>>>>> This script allows you to change the permit or deny calls for 
>>>>>> Echolink
>>>>>> without directly editing the config file. This still requires an
>>>> Allstar
>>>>>> restart to take effect but makes it easier and less error prone to
>>>> make the
>>>>>> changes. This is one step towards a change In the near future 
>>>>>> where the
>>>>>> Echolink permits and denies will be defined through the Asterisk
>>>> database
>>>>>> in a similar way as the ban/allows are now for Allstar. Once it 
>>>>>> is done
>>>>>> this way the changes will be immediate with no restart required.
>>>>>>
>>>>>> And finally the sleep was updated in astdb.php for up to 1800 random
>>>>>> seconds, rather than minutes. This should further ease the 
>>>>>> loading on
>>>> the
>>>>>> hosting servers.
>>>>>> _______________________________________________
>>>>>>
>>>>>> ARM-allstar mailing list
>>>>>> ARM-allstar at hamvoip.org
>>>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>>>>
>>>>>> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
>>>>> _______________________________________________
>>>>>
>>>>> ARM-allstar mailing list
>>>>> ARM-allstar at hamvoip.org
>>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>>>
>>>>> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>>
>>> ARM-allstar mailing list
>>> ARM-allstar at hamvoip.org
>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>
>>> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
>>>
>> _______________________________________________
>>
>> ARM-allstar mailing list
>> ARM-allstar at hamvoip.org
>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>
>> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org