Re: IP Connect - Best Practices
|
Thanks for all of your replies and insight. A bit of followup from my end... The Philips display issue was on a 4-series box, and although it's not ideal, it's nice to hear that I'm not the only one seeing stuff like this. I'll keep using my overkill-oscillator for now.
g
On Wednesday, August 31, 2022 at 11:32:15 AM EDT, ckangis <chris@...> wrote:
I experienced one event with a 4-series having a TCP client loose connection and halt retrying, at the beginning of this year (I started a thread about it then). A reboot 'Fixed' it and I have not seen any other issues, though I've heard a few others indicate very infrequent similar issues with both TCP clients and EISC comms.? On my project with the issue, I did update the firmware (again probably around february) and haven't seen this issue again...
I agree with most that you shouldn't have to manage this, as I've had '1' on the TCP connects for 20+ years with no notable issues except the one mentioned (2,3 and now 4-series)
I did have one IP-controlled relay board that would stop communicating after ~7-10 days, but I'm very sure it was the device not Crestron. This was a very specific application so I changed this to connect only when I needed to control the relays and then disconnected again - Seems to be stable after 4-5 weeks...
I have personally changed from using a '1', to a signal driven by some start-up logic as it allows debugger testing and facilitates adding re-connect logic when needed...
Guzzup:
Though it would seem that your issue is different, I did have an issue with a Sony AVR module (back in 2018/2019) where when you disconnected the network connection to the AVR for only about 20 sec., the module would not reconnect. you had to reboot the program slot. It ended up being an issue with the S# comms that was not retrying. one of my inside Crestron Peeps fixed it and I've been using it consistently without issue since then...
|
