I¡¯ve seen an issue on my home system (PRO4) a couple times but not with enough frequency to get enough info for a proper bug report
where if the Ethernet link is lost under some circumstances the connection will not retry until the program is reset. The status in the IPT is ¡°LINK LOST¡± ¨C but this doesn¡¯t happen on every link loss event. (Most recently I saw it because I was upgrading one
of the edge switches in my AV equipment room)
?
The other thing to remember is that the TCP client retry time rises exponentially the longer it can¡¯t connect to the other device, e.g. the longer a device is
off line the longer it will be between retrying the connection (I want to say the upper end is 65000 seconds but I¡¯ve never personally tried it) so if the device had been offline for ¡°a long time¡± that could explain why it didn¡¯t seem to be retrying.
?
Beyond those two cases though I can¡¯t say I¡¯ve seen any systematic issues with the TCP/IP client on the 3- or 4- series¡. And I have a few applications where
I know I¡¯d know if there were issues because the failure would be critically obvious.
Hi All,
Wondering if others have seen this odd, intermittent behavior...and also a heads-up for others to watch out for it
CP4 (v2.7000.00040) has a TCP client communicating with a Vantage System (though I don't think the remote device matters).
It was working two weeks ago, and we checked yesterday (client is out of town) and found that it was 'Not Connected' and specifically not trying to Re-Connect.
The Status analog just stayed at '1d' instead of the typical toggling between 1d and 3d (Waiting for connect vs Connect Failed)
As I have a '1' on the Connect input, I could not test if toggling this would fix the issue, Rebooting the Vantage processor did not restore.
Only restarting the program slot restored the connection.
I spoke with Crestron TS to trouble-shoot this, as I've never seen this behavior before, and they have confirmed that they have seen this a few times, offering:
1. They said it was 4-series issue, spanning fw updates
2. Use an S+ emulation module of the TCP client until they fix the issue...:(
Clearly this is a specifically intermittent issue, as I have not seen anyone else talking about this lately, but they have confirmed that there is a problem....
In a related note, another friend of mine who I trust with his technical knowledge and experience, says that he has seen this issue? for years on both 3 and 4-series systems.
He feels that it is a long-standing issue that has not been dealt with and thus probably will not be fixed...
Given my experiences over the last 5+ years with TB, I would tend to agree.
To have to use a custom S+ module to handle this is absolutely ridiculous - the TCP Client is a native hardware device symbol...
What experiences have other had about this??