Communications time-out if scan takes longer than 5 minutes about els HOT 5 CLOSED

To gain better control of time-outs am doing a large refactor to allow adjustment on every read and write call.

from els.

Discovered part of the issue is a time-out enforced by an ISP that cannot be controlled by the software. This has required the addition of an internal "heartbeat" beyond basic TCP/IP time-out settings. In the process of adding and testing a new arrangement to better handle time-outs, heartbeats, and exceptions. This should cure hang problems but requires significant testing.

from els.

Background on communications changes:

Previously ELS used time-outs enforced by the sftp protocol to manage behavior. That approach was problematic because the stty protocol could hang in a read() operation if something failed in an odd way.

To address time-out and process hang issues the approach was changed to use stty to manage behavior and an infinite time-out for sftp. This allows the use of read() time-outs with stty that can control sftp better than the previous technique.

Along the way discovered an issue with time-outs enforced by an ISP. That necessitated an internal "heartbeat" that is automatically sent once per minute to keep a connection alive during long-running operations - such as backing-up a large movie file or performing a subscriber scan of all content on a slower computer.

The result makes ELS more predictable and reliable with various Internet connection oddities.

These are significant changes impacting a lot of code. It is being used daily for my media collection. After it has run successfully for several days this issue will be closed.

from els.

This build of ELS 4.0 has been running flawlessly for 10 days with the oddities mentioned in the other comments. The new approach is working well. Don't forget to add the "timeout" element to your JSON files, in minutes. Example: "timeout" : "15",

from els.

These changes have now been running for over 30 days without error.

from els.