InterLinked1
commented
12 months ago This sounds okay to me; there are other things that also don't log every instance but only every now and then to prevent exactly this kind of issue. The alternative would be kill the stream on the first failure, but it sounds like that may not be appropriate if it can recover on its own, if the network comes back.
On occasion, I will have brief internet outages. Sometimes when this occurs, ezstream cannot recover from the problem. When it happens, the logs quickly fill up with the message:
write failed: Resource temporarily unavailable. My log file quickly grew to 394MB.I received an email from Broadcastify that let me know there was a problem. Most times, I get an email that the connection has been reestablished.
This is a unique problem. If there is no internet - we will get an error message. Sometimes when the internet recovers, ezstream will also recover. However, I have experienced cases where it did not recover and the logs were filled with this error message. I simply killed the ezstream process and app_rpt recognized that fact and restarted the outstream process.
I propose that we add a timer to the rpt structure for last outstream error. When the error occurs, we set the timer. Further, if that timer has been set, we stop writing the error message. When this timer exceeds 60 seconds, we kill
myrpt->outstreampid. app_rpt will recognize that the external process has stopped and will restart the process. If the internet is still down, the above would repeat again. This timer would be reset each time we successfully write a packet.This may not be an ideal solution, but it would be an attempt to correct the problem.