Home AMX User Forum NetLinx Studio

Mcintosh MS300/Esicent E2 problem

Hello all,
i am using a Mcintosh MS300 music server which is actually an Esicent E2 in a different box and i have downloaded the control module from the Escient website and i'm using ethernet connection, it works fine, until, the network connection is lost for some reason (like the computer guy took out the Switch power or something like that...). the module will try to reconnect with the 'open_client_ip' command but in the Netlinx diagnostics i will see an answer that says 'SocketMan::ProcessPLPacket - ClientOpen handle already in use'. When you try to disconnect with the 'close_client_ip' command it will answer 'connection is already closed'. if you reboot the Netlinx it won't help.
only if you reboot the MS300 itself it will reconnect again. i think that the problem is that the MS300 still thinks that the session is open and won't let a new session be open. could this be?

Thanks for the help.


  • Options
    Reese JacobsReese Jacobs Posts: 347
    Mcintosh MS300/Esicent E2 problem

    I don't have any direct experience with the McIntosh MS300 but if it based on the Escient Fireball E2 series, early/initial releases of the software for the E2 line (as well as the Fireball E-120/E-40 upgrades to provide E2 capabilities) had a problem/feature/annoyance wherein a TCP client connection (from Netlinx or any other client) would be dropped after being connected for 60 minutes. I just last week finished doing Fireball software updates for all of my E2 units, first generation E-units, and also the 1st generation DVDM units and I believe that this 60-minute disconnect problem has been corrected (need to do more testing to verify). So, the problem is known and documented and the good news is that it might be fixed so check to see if a software update for your MS300 is now available. On standard Fireball units, there is a SETUP menu option under Utilities for doing Software Updates. Note sure if the MS300 provides the same menu setup or not but this would be the place to start to look for an update option.

    Prior to having a fix, I had modified my Netlinx module for the Fireball series (handles 1st generation and 2nd generation units) to reconnect to the Escient device once an OFFLINE event was received from an Escient unit. I do not use the AMX module so I am not sure how it handles reconnects. The symptoms you are seeing are consistent with trying to reconnect to the Escient device too quickly. In my experience, when the Escient disconnects, Netlinx will receive notification that the socket connection has been closed and an OFFLINE event will occur. Once the OFFLINE event occurs, the socket is closed and issuing an IP_CLIENT_CLOSE at that point will generate the error you are seeing (connection already closed). If you try to re-open the client connection to the Escient prior to the completion of the OFFLINE event for the TCP device, you will get the error message indicating that the handle (socket) is in use since the connection has not been completely destroyed at that time.

    I have had excellent results reconnecting by handling the OFFLINE event for the socket/TCP device (indicating the connection is closed) and then waiting a brief interval (2-3 seconds) before issuing a client connect request back to the Escient. Doing it in this manner has always allowed me to connect back to the device quickly and reliably.

    As I said, check for a software update to see if this will make the problem go away otherwise you may need to make some reconnect logic modifications (harder to do if you do not have the source code to the module for Escient). Hope the information is helpful.

  • Options
    Chip MoodyChip Moody Posts: 727
    If I'm reading correctly, it sounds like there are really two things going on. On one side, it sounds like the AMX is trying to re-open a socket that didn't get closed. If the code is trying to re-open the connection based on a lack of traffic coming in, it should be changed. It should try to close the connection first, wait a few seconds then attempt to re-open it in the event that regularly expected traffic ceases. In addition, if an OFFLINE event occurs for that socket, it should also wait a few seconds, then try to open the connection again. In that latter case, calling IP_CLIENT_CLOSE can't hurt. You >shouldn't< get an error, since the closing of the socket created the OFFLINE event, but at the same time I've seen the "socket already open" errors when trying to call IP_CLIENT_OPEN after an OFFLINE event. In the case that it was closed okay, calling IP_CLIENT_CLOSE won't cause any problems, even if you do get the "already closed" error.

    At the same time, it sounds like the music server isn't detecting the dropped connection at all, so the AMX may be attempting reconnection, and simply timing out when the server doesn't respond. Fixing that does depend on the manufacturer, and failing that fix, rebooting the server would be the only solution...

    - Chip
  • Options
    RonenRonen Posts: 55
    Problem Solved

    thanks for the help, i've just addded a 30 sec wait before the reconnect attampet and it solved the problem.
    the strage thing is that it still gives me the same erorrs... but it works...

    Thank you all again!
Sign In or Register to comment.