Crestron Issue- Connection loss- Reboot of iPad doesn't fix it.

[Kafkaesque]

I have a client with 3 iPads and a couple of the iPads regularly stop
working after a few days uptime. A reboot of the iPad / CF app
doesn't fix it but a reboot of the Crestron processor does. I'm
currently using module 4.3 on this site, I'm also using basically the
same implementation on another site with 5 iPads with no such
problems.

Looking in debugger the modules are in the right mode (server_status =
1) but at the moment only one of them connects when you start the CF
app.

I manually pulsed the activity timeout signal into the module of the
working iPad, and then one of the non-working iPad and this is what I
get:

12:59:30 - 01-06-2011: [User Stimulus] : User set ActivityTimeoutTP6
to Pulse High
12:59:31 - 01-06-2011: ActivityTimeoutTP6 -> 1
12:59:31 - 01-06-2011: StartiViewerServerTP6-latched -> 0
12:59:31 - 01-06-2011: (CF-iViewer)CommandServerStatusTP6 -> 5d
12:59:31 - 01-06-2011: ActivityTimeoutTP6 -> 0
12:59:33 - 01-06-2011: RestartServerTP6 -> 1
12:59:33 - 01-06-2011: DoRestartTP6 -> 1
12:59:33 - 01-06-2011: StartiViewerServerTP6-latched -> 1
12:59:33 - 01-06-2011: (CF-iViewer)CommandServerStatusTP6 -> 1d
12:59:33 - 01-06-2011: RestartServerTP6 -> 0
12:59:33 - 01-06-2011: DoRestartTP6 -> 0
12:59:44 - 01-06-2011: [User Stimulus] : User set ActivityTimeoutTP7
to Pulse High
12:59:44 - 01-06-2011: ActivityTimeoutTP7 -> 1
12:59:44 - 01-06-2011: StartiViewerServerTP7-latched -> 0
12:59:44 - 01-06-2011: (CF-iViewer)CommandServerStatusTP7 -> 5d
12:59:44 - 01-06-2011: ActivityTimeoutTP7 -> 0
12:59:46 - 01-06-2011: RestartServerTP7 -> 1
12:59:46 - 01-06-2011: DoRestartTP7 -> 1
12:59:46 - 01-06-2011: StartiViewerServerTP7-latched -> 1
12:59:46 - 01-06-2011: [Console Data] : Error:
CListenSocket::InitializeCommon - NU_Bind Error (-264)
12:59:46 - 01-06-2011: [Console Data] : Notice: SIMPL+ TCP Server
__COMMANDSERVER from module S-11.3.8.6: Port conflict or invalid port
number (8022)
12:59:46 - 01-06-2011: [Console Data] : Error: Unable Initialize
ListenSocket
12:59:46 - 01-06-2011: (CF-iViewer)CommandServerStatusTP7 -> 1d
12:59:46 - 01-06-2011: RestartServerTP7 -> 0
12:59:46 - 01-06-2011: DoRestartTP7 -> 0


As you can see I'm getting an error initializing the socket/port for
TP7. A 'who' command in console shows this:

S+ Server __COMMANDSERVER (S-11.3.8.6): 192.168.1.45 (uptime: 22
days 16:10:19.49)

Which is the non-working module and the IP address of the iPad. Any
idea why this is being held open?



Interestingly, manually pulsing the activity_timeout of the other non-
functioning iPad immediately got it working again.

Would appreciate any help offered as this is becoming fustrating!

Brandon.

[Jarrod Bell]

That is definitely strange, and shows an issue on the Crestron side
rather than our app side.
I really wonder how stable Crestron's TCP stack is at times. Is there
any chance you have any of the modules accidentally on the same port?

The error opening the socket should not ever happen after an activity
timeout, because we forcibly tell the socket to close when the restart
server is called by setting 'enable connections' low then high again.
Any Crestron gurus care to shed any light on this issue?

Jarrod

[Kafkaesque]

Nope, the 3 iPads were on 8021,22,23 respectively. I've decided to
change the ports to a higher number on the off-chance and to try using
module 4.4.3

Will leave it over the weekend and see how it performs.

Brandon.

[Kafkaesque]

Aaaargh!! This site is still having the same problem. I've have
tried absolutely everything I can think of, including running the CF
modules on a separate MC2E connected to the main processor via an
ethernet bridge. The socket still seems to randomly being held open
after the iPad disconnects. Quite a lot of the time it seems to
recover after an unknown amount of time, but the iPad still won't
connect unless you manually pulse 'enable connections' off then on
again. Other times it doesn't respond to anything except a processor
reboot.

I've checked the programming and it is exactly the same as 3 other
sites that have no issues, I've tried running it on a different
processor with no improvement. The only other thing I can think of is
the network, but I can't imagine what could cause these symptoms.
Unfortunately the client is an IT developer so has an enterprise grade
network that I haven't personally configured Everything is integrated
with it which makes testing the Crestron system on a separate network
difficult...

I'm really at the point where the client is getting annoyed, and my
only option is looking at the Crestron Ipad app, it would be a huge
amount of work to redo the GUI, plus of course I'll lose the licencing
fees paid for the 3 iPads...

A little help?

Brandon.

[Simon Cope]

Are you using the logic for driving "enable connections" as per Jarrod's example Simpl Win program?  You can't just have "enable connections" held high permanently, as I'm afraid Crestron's socket stuff just doesn't play nicely.  You MUST make use of the activity timeout from Jarrod's module to drop "enable connections" before re-establishing it.

I have also taken to watching the socket status analog, and if stays on 1 for more than 10 secs, I use that to drop and then re-enable "enable connections".

Let me know if you want to send you a snippet of that code - it is working great for me at the minute, and seems to catch all the foibles of both Crestron and Apple's IP behaviour.

Simon

--
You received this message because you are subscribed to the Google Groups "CommandFusion" group.
To post to this group, send email to comman...@googlegroups.com.
To unsubscribe from this group, send email to commandfusio...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commandfusion?hl=en.

[Scott Shanafelt]

Hi Simon,

I am just starting to tinker with this, and I would love to take a look at how you do it.

Scott

[Kafkaesque]

Thanks for the reply Simon. I am using the standard logic to re-
initialise the 'enable connections' input on the module (I have also
tried extending the delay from 2 to 4 seconds). I have also added a
bit of logic which sounds similar to yours than uses an analog equate
and a debounce to use the socket status to re-trigger the 'enable
connections'. However because this runs as backup to the standard
logic I have it set to trigger if the analog FB is not equal to '2'
for 10 minutes.

Unfortunately it still keeps falling over :(

I would however really appreciate it if you could email me the code
you have, this one's really doing my head in!

Cheers,

Brandon.

[Simon Cope]

I'll post something next week - last night in the Caribbean tonight, and I've had one too many Mount Gay rum and gingers to be thinking about CF and Crestron.  Remind me if I forget!!!!!

SiCo

Brandon.

[Kafkaesque]

It seems to have been better this week. I can still see in the error
log that the port is being held open every now and then (a couple of
times a day...), but the additional logic I have evaluating the socket
status is at least bringing it back online.

Simon I'd still like to have a look at your logic if your generous
offer is still open.

Cheers,

Brandon.

[Simon Cope]

Brandon,

Take a look at the attached smw file.

Regards,

Simon

Cheers,

Brandon.

[Kafkaesque]

Thanks for that! Similar effect to my logic, except that I keep
retriggering 'enable connections' every 10 minutes as long as the
socket status doesn't equal '2'. Though I only do this because of the
idiosyncratic problem that I'm having at this particular site.

Jarrod, do you think this code should be added to the SIMPL demo?
(With Simon's permission of course...)

Cheers,

Brandon.

On Jan 31, 10:09 am, Simon Cope <sjc...@gmail.com> wrote:
> Brandon,
>
> Take a look at the attached smw file.
>
> Regards,
>
> Simon
>

> On 28 January 2011 16:21, Kafkaesque <brann...@gmail.com> wrote:
>
> > It seems to have been better this week.  I can still see in the error
> > log that the port is being held open every now and then (a couple of
> > times a day...), but the additional logic I have evaluating the socket
> > status is at least bringing it back online.
>
> > Simon I'd still like to have a look at your logic if your generous
> > offer is still open.
>
> > Cheers,
>
> > Brandon.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "CommandFusion" group.
> > To post to this group, send email to comman...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > commandfusio...@googlegroups.com<commandfusion%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/commandfusion?hl=en.
>
>
>

>  CF_compiled.zip
> 72KViewDownload

[Jarrod Bell]

Yeah definitely. Anything that helps with Crestron socket issues is always appreciated!

Jarrod

> To unsubscribe from this group, send email to commandfusio...@googlegroups.com.