Home AMX User Forum NetLinx Modules & Duet Modules

iPort NetLinx Module Problem

At the moment we have an NI-4100 which controls an iPort FS-22 and we are getting some complaints from the customer that sometimes when his iPod is docked and playing, the system “crashes” and nothing works unless he reboots the devices. The AMX NetLinx module that we are using in our code says:

“//Current iPod Firmware Tested: 1.2.3 Video 5th Generation

//Current iPort Firmware Tested: 1.32 on IW - 1.06 on FS”

Therefore, I believe that the iPort firmware is on version 1.06.

When we tested the system, everything was working fine. We used our own iPod and we had no problems. After the complaints, we went on-site to investigate the problem and we noticed that some of the music tracks on the customer’s iPod were named using greek characters. We also noticed that the system crashed when we were scrolling up/down the list of songs/artists/albums which also contained a lot of greek characters that were showing up as gibberish.. (incomprehensible text)

Do you think that these greek characters could have caused these system crashes? Are aware of any characters that are not supported by this iPort and can cause this sort of problems?

Do you think that maybe the iPort device is faulty?

I have noticed that there is a newer firmware for the iPort (version 1.07) as well as a newer AMX module that complies with this new iPort firmware on http://www.iportmusic.com. Should we upgrade our iPort firmware and our AMX module? Would that help?

Any other suggestions are more than welcome..


  • ColzieColzie Posts: 470
    Make sure your version of Netlinx.axi matches what is included with the iPort module. This can help with the foreign characters.

    I have also discovered a problem with newer versions of Apple firmware, where the device name isn't reported properly (or more accurately the iPort COM module isn't processing it properly.) What happens is the COM module returns a blank "iPod Name", and the UI immediately requestes the iPod name again...endless loop.

    What I did was put in a 10 second delay before asking for the iPod name again. In the UI module, in the PROCESS_RESPONSE() function, look for
    and put a
    wait 100
    right in front of it.

    Hopefully there will be a new COM module soon to handle this issue, but this band-aid seems to prevent the lockup for now.
  • TurnipTruckTurnipTruck Posts: 1,485
    There was a new module version posted a few days ago that had something to do with newer iOS firmwares.
  • John NagyJohn Nagy Posts: 1,702
    I believe the AMX module asks for progress and full reports every half second (or used to). This caused an eventual backup of tasks when the system got busy, resulting in increasing wait times for response, after a half hour of play it would seem to be locked up... it would actually be minutes behind.

    We reduced the polling to every five seconds (certainly adequate progress bar information) plus any time an action was taken from the UI. The problem went away entirely.... not that there weren't others. We too had to work around the foreign characters (and punctuation!).
  • Problem solved by using the iPort FS-22 latest firmware (v1.07) on the device and the AMX latest module "iPort AMX Netlinx Module v3_24 02-11-2011" in my code !!

    According to "www.iportmusic.com", the latest firmware for the FS-22 (1.07) was developed specifically to deal with the issue we were having with foreign characters.

    Guys thank you very much for your help!
  • jjamesjjames Posts: 2,906
    John Nagy wrote: »
    I believe the AMX module asks for progress and full reports every half second (or used to).
    I *HIGHLY* doubt it queried every half second; instead, iPods / iPhones / iCrap actually send out play information every half second. (Just FYI)
  • TurnipTruckTurnipTruck Posts: 1,485
    The previous version of the iPort module had a bug where it would send out level updates whether or not the UI was on the page. There was a loop to update feedback and the array of devices in the conditional was not indexed properly. It was an easy fix, but I haven't looked to see if it was corrected in this version. Not a big deal unless R4s are in the mix.
Sign In or Register to comment.