2014-05-02 13:11 GMT-03:00 Dan Dennedy <d...@dennedy.org>:
>
> On Wed, Apr 30, 2014 at 9:38 AM, Dan Dennedy <d...@dennedy.org> wrote:
>
>> On Wed, Apr 30, 2014 at 6:05 AM, Juan Martin Runge <jmru...@gmail.com>wrote:
>>
>>> Dan,
>>> Sorry for delay, but was busy with other problems. I finally got the
>>> stack trace! Melted was running for almost two days and almost without
>>> action (only one casual append or clean, but usta every 50 millis) and then
>>> I send circa 30 append commands one after the other. Here is the result:
>>>
>>> I do not need the full log, but neither is the partial backtrace
>> providing enough information. We will either need to increase the 10s to
>> 100s in melted_local.c:sigsegv_handler(), or run melted in gdb and issue
>> 'thread apply all bt' within gdb when it crashes. I will try to recreate
>> the problem based on some MVCP usage patterns I see from your log above. I
>> encourage you to do the same. In your system, Is the client that is calling
>> USTA on a different thread/process & socket than the client calling CLEAN
>> and APND?
>>
>>
> I am able to reproduce a crash due to a race condition somewhere inside
> the avformat producer. It may be tricky to fix, but I am trying. There is
> probably some workaround you can do with MVCP, but I have not explored
> that. Perhaps stopping the unit before sending all these commands, or
> skipping the clean command and instead doing a wipe after appending, or
> putting a delay between append commands - my test sends as fast as
> possible, not even waiting for server to respond to each one.
>
>
Thats just what we are doing. Sending commands without waiting the server
to respond each one. Now Im reimplementing the software (mbc-mosto) with
java (instead of node.js) to be able to be synchronous without using hacks.
We cant stop the unit, but will try the append + wipe in our current
software and let you know.
Thanks!
> --
> +-DRD-+
>
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
