Hi, Thanks for the precise report. What the logs say is: * One output was restarted (restart the external encoder lame) * The second one initiated a restart as well, but never completed * After that, there wasn't anymore streaming * But the input.http() input thread still works (and logs metadata)
I can confirm that if the process restarting hangs, it'll hang the whole duppy scheduler, notably making telnet unresponsive. This is because reset_process (in src/encoder/external_encoder.ml) is executed in a duppy task (the one that runs the pull function). But the task doesn't make things perfectly asynchronous, and a mutex is also used when restarting, so that the streaming thread will hang too. I don't know if that can be improved yet. In any case, the problem here is very much related to external encoders. Pascal told me that the problem occurs with the internal mp3 encoder, but he's not 100% sure and will try to double-check. Hope this helps... -- David ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
