Re: TOut - what that means?
Posted: Sat Oct 24, 2020 2:30 pm
Thanks for the additional information. I have done some further investigations here, and so far I am seeing continuous problems with my connections to the FCS004 reflector rooms, and no problems with other connections, both C4FM and DMR. Because of that, I suspect there might be something going on with that reflector, and I see it on multiple rooms, and on all stations. That means that ALL entries except my own are marked TOut, leaving me missing the actual duration numbers.
I am wondering if a slight modification of the method to indicate an error might be possible? Rather than obliterate the sometimes useful duration data with TOut, could we just change the background color for that report, much like happens when the BER rate if out of line? By implementing it that way we keep the actual data, but still are getting an indication of an error, which I think was the original intent of the change. Another option might be to allow the user to somehow decide if they want the check done or not. I suspect that adding another parameter to the config data is a major issue, but maybe something simpler like testing for the presence of a file to disable it (/etc/no_timeout_checks is present) might also be an option. Because in my case (and others I have checked with as well) EVERY report is showing an error, and it is probably beyond my control to fix it, I find the loss of that data to be a minor problem, and would personally choose to not do that check.
I am wondering if a slight modification of the method to indicate an error might be possible? Rather than obliterate the sometimes useful duration data with TOut, could we just change the background color for that report, much like happens when the BER rate if out of line? By implementing it that way we keep the actual data, but still are getting an indication of an error, which I think was the original intent of the change. Another option might be to allow the user to somehow decide if they want the check done or not. I suspect that adding another parameter to the config data is a major issue, but maybe something simpler like testing for the presence of a file to disable it (/etc/no_timeout_checks is present) might also be an option. Because in my case (and others I have checked with as well) EVERY report is showing an error, and it is probably beyond my control to fix it, I find the loss of that data to be a minor problem, and would personally choose to not do that check.
