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

[Patrick Perdue]

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