[Pianod] Testing on v234

[Chris Greenman via Pianod]

More unscientific test data:

this past weekend I had several races on my boat and had the computer up
and running the whole time.

The start and finish area of the race course was in a fringe cell coverage
area so it wreaked havoc on pianod.  several times it quit in mid song but
then just switched to the next song and continued.  However, there was a
number of times where pianod just hung and I believe it was while changing
tracks.  When that happened I did verify I had internet connection and
tried to fast forward to another track as well as changing stations.  When
that happened I just ended up restarting the computer.  During our races,
however, pianod seems to run just fine.

I apologize for not having more concrete test data but then I was out there
to race not troubleshoot,  i'm still running v234.


On Mon, Aug 22, 2016 at 12:28 PM, Bruce M. Sheplan via Pianod <
pianod at lists.deviousfish.com> wrote:

> To add to Chris's report of success, I have tried to cause the same
> problem I was having with libav (pause for > 5mins then resume) and have
> not had any lockups.  After the buffer is used up music stops for 5-10secs
> and the resumes where it left off, I presume it is re-connecting and
> rebuffering.
>
> I had another crash yesterday after about 6hrs of continous play, same
> place in the library, I am trying to see if I can get a core-dump of the
> crash so I have something to send you.
>
> This is still on v234, havent had a chance to try v236 yet.
>
> - B
>
> On Mon, Aug 22, 2016 at 11:22 AM, Chris Greenman via Pianod <
> pianod at lists.deviousfish.com> wrote:
>
>> I can provide non-scientifically tested results.   Last time I used the
>> pi on my boat with spotty cell coverage I did have 1 instance where I had
>> to reboot the pi but I can't say for sure what caused that.   I was in a
>> rush and couldn't investigate so easiest thing was to just reboot.   it
>> might have also been caused by something external to the PI.  What I CAN
>> say is that for the next 3 or so hours it worked flawlessly.  there were
>> some hiccups in the audio as if it had lost internet but it picked up where
>> it left off fairly quickly.   About the time you noticed the music had
>> stopped it starts up again.
>>
>> That's about as much real world testing I've done with it.   I'll be
>> racing this week so I'll try it again, this time with a simpler hookup to
>> the internet.  Second wifi interface connecting directly to my cellphone
>> hotspot on 5ghz.  It eliminates at least one source of interference on the
>> 2.4ghz band.  Before, I used a small travel router that connected on a
>> different channel to my phone.
>>
>> On Sun, Aug 21, 2016 at 11:27 PM, Perette Barella via Pianod <
>> pianod at lists.deviousfish.com> wrote:
>>
>>> Chris Greenman said of his Raspberry Pi with libav wiped and ffmpeg
>>> installed:
>>>
>>> Seems to be working fine.  I haven't tried any network stalls yet but it
>>> runs and i can control it.  I followed the instructions below to wipe out
>>> libav and install ffmpeg.
>>>
>>> https://www.assetbank.co.uk/support/documentation/install/ff
>>> mpeg-debian-squeeze/ffmpeg-debian-jessie/
>>>
>>>
>>> Awesome.  Glad to hear that’s doable and working… can you confirm that
>>> this fixes the hangs on network loss you were seeing?  I’d like to confirm
>>> my diagnosis of libav.
>>>
>>>
>>> On 2016年08月21日, at 14:09, Bruce M. Sheplan via Pianod <
>>> pianod at lists.deviousfish.com> wrote:
>>> On v234, After playing for a couple of hours ( ~2hrs? ) pianod crashed
>>> with the following in the log:
>>>
>>> pianod[15739]: segfault at 2c ip b56199cd sp bfa005a0 error 4 in
>>> libgstplayback.so[b560b000+68000]
>>>
>>>
>>> Seems like thats a gstreamer library though so maybe unrelated to pianod
>>>
>>>
>>> It does sound like it’s in the library.  I checked my IDE settings and
>>> turned on Guard Malloc, which catches lots of good stuff that causes
>>> intermittent problems.  It didn’t turn up anything, nor did a brief leak
>>> analysis.  I guess keep an eye on it, see if it recurs and if there’s a
>>> pattern to it.  Rare of frequent?  Predictable or intermittent?  Let us
>>> know what you see over time.
>>>
>>> I still need to look into why my Pi hangs up when using hw:1… whether
>>> it’s something peculiar to using the tone generator, or if it’s specific to
>>> my USB dongle.
>>>
>>>
>>> … and in other news…
>>> r236 has a fix to the ffmpeg code to calculate playpoint *before*
>>> freeing the packet the data comes out of, resulting in correct answers.
>>> There’s also new #ifdefs for some of the new 3.1 API, with support for
>>> older stuff still present.  If I broke anything, let me know.
>>>
>>> There are other API changes in 3.1 too.  There is still a deprecation
>>> warning with 3.1 about using the ‘codec’ field in AVStream, but I’m waiting
>>> to hear what the Right Way is to replace this, since (among other issues)
>>> the documentation indicates I need to call a method that requires it.  So
>>> far, I’ve had two more-or-less same answers to a different question than
>>> what I asked.  On the positive side, though, they were coherent and three
>>> times more plentiful than libav’s help list, in just hours.
>>>
>>> Perette
>>>
>>>
>>> _______________________________________________
>>> Pianod mailing list
>>> Pianod at lists.deviousfish.com
>>> http://lists.deviousfish.com/listinfo.cgi/pianod-deviousfish.com
>>>
>>>
>>
>> _______________________________________________
>> Pianod mailing list
>> Pianod at lists.deviousfish.com
>> http://lists.deviousfish.com/listinfo.cgi/pianod-deviousfish.com
>>
>>
>
> _______________________________________________
> Pianod mailing list
> Pianod at lists.deviousfish.com
> http://lists.deviousfish.com/listinfo.cgi/pianod-deviousfish.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deviousfish.com/pipermail/pianod-deviousfish.com/attachments/20160920/cb72f59d/attachment.htm>