TWO bad AMX devices... in a row.

fogled@mizzou

Sorry, I'm just uselessly whining, nothing to see here, move along.

Last 2 projects I've worked on:
1. AMX NX-3200, took 10+ minutes to boot.
2. DVX 3255HD, it will only make IP connections on a fresh reset AND code upload; just a reboot, and it stops making IP connections with an error=8 (local port not open). If I just do a reset, or just do a code upload, it won't start working again, it has to be both things to restore IP connections out of the controller.

I still have yet to replace the DVX, if anyone has any ideas, but I'm almost certain it's got a memory card problem. If y'all think I should bother calling AMX first, I will, but fairly certain it will just cost me more time to try to explain the problem to them, have them scratch their heads, and waste my time trying various things, before coming to the conclusion that I need to replace the hardware. Luckily, I've got another box, and when I have another box, the single quickest way for me to confirm the problem is always to just throw another box at it.

...and Harman reps were just in here a couple days ago, trying to get me to fight people, to place their products? Nope. Nope. Nope.

I'm kinda pissed right now.

ericmedley

I did have a DVX once that (unbeknownst to me) had a firmware update. I at first didn't come up alive. When I called about it, they told me they'd just done a firmware update and to wait like 15 minutes. Sure enough, after 15 mintues, i started blinking and flashing and at last came alive.

fogled@mizzou

I double-checked the firmware version, especially after some recent "old firmware" issues in product shipments. it's the latest and greatest currently available:
1.5.78 Master
1.1.42 Device
1.7.68 Switcher

It came that way from the factory, I didn't have to run any updates on it.

fogled@mizzou

Turns out it wasn't the box, per se, it's a boot-race condition between code execution, and the IP connections coming up through DXLink to DX-RX units. When a new code upload is done, it takes a bit longer for the code to start executing, so the DXLink IP connection is established by the time it tries to connect to the device downstream of the DX-RX. On a non-upload reboot, the code starts executing before the DX-RX IP link is fully established, so the initial connection was failing. AND, I had a bug in my re-connect attempt code, so that wouldn't work, either. A call to AMX tech support helped me pin down my programming bug, then once that was fixed, the actual problem became obvious.

Correcting the programming bug in the reconnect code makes the system work properly, even if it takes 2-3 connection attempts before the IP link is established. However, to keep the errors from occurring in the first place, I changed my programming to wait until the DX-RX units come fully online, then execute the connection attempt to the downstream device when it does. That's a solid fix.

This is one why I try to convince everyone that we shouldn't use the IP tunneling through the DX-RX's, but just pull another ethernet cable and use a direct connection instead, but... the guys who do the actual install don't want to pull that extra cable, and I don't have the authority to make them do it. So, instead of spending 15-30 extra minutes adding and pulling another standard network cable along with a shielded network cable, we wasted about 10 hours of tech time chasing around the boot race problem, before I figured it out and fixed it. Brilliant! Of course we would have never noticed the problem, if my re-connect code didn't have a bug in it in the first place, so it's my fault anyway, of course.

ericmedley

fogled@mizzou wrote: »

Turns out it wasn't the box, per se, it's a boot-race condition between code execution, and the IP connections coming up through DXLink to DX-RX units. When a new code upload is done, it takes a bit longer for the code to start executing, so the DXLink IP connection is established by the time it tries to connect to the device downstream of the DX-RX. On a non-upload reboot, the code starts executing before the DX-RX IP link is fully established, so the initial connection was failing. AND, I had a bug in my re-connect attempt code, so that wouldn't work, either. A call to AMX tech support helped me pin down my programming bug, then once that was fixed, the actual problem became obvious.

Correcting the programming bug in the reconnect code makes the system work properly, even if it takes 2-3 connection attempts before the IP link is established. However, to keep the errors from occurring in the first place, I changed my programming to wait until the DX-RX units come fully online, then execute the connection attempt to the downstream device when it does. That's a solid fix.

This is one why I try to convince everyone that we shouldn't use the IP tunneling through the DX-RX's, but just pull another ethernet cable and use a direct connection instead, but... the guys who do the actual install don't want to pull that extra cable, and I don't have the authority to make them do it. So, instead of spending 15-30 extra minutes adding and pulling another standard network cable along with a shielded network cable, we wasted about 10 hours of tech time chasing around the boot race problem, before I figured it out and fixed it. Brilliant! Of course we would have never noticed the problem, if my re-connect code didn't have a bug in it in the first place, so it's my fault anyway, of course.

This is good info for me. I'm in the middle of sussing out a couple DX-xx boxes that keep falling offline. I've instructed the integrator to do essentially the same thing: run a 2nd cat5 for just the IP control of the unit and leave the video for just video. This bolsters my argument. Thanks.

fogled@mizzou

In my experience, the DX-RX units have a huge range of time it takes for them to connect to a master. I think I've complained about it on this forum before; anywhere from 2 seconds to 2 minutes for a DX-RX (both 1080p and 4K versions) to connect to a master, through an SDX-514, after the SDX itself has come online in the master. Sometimes, the DX-RX units never do come back online, and I have a timeout in my code that waits 2 minutes for a connection, then telnets directly into the unit and issues a reboot to the DX-RX that way, and starts waiting for an incoming connection again. That almost always works, but can take 2-4 minutes for a room to come fully back online after any kind of network disruption. I think this has gotten better with recent firmware updates, but honestly don't really know, I haven't been paying much attention to that installation.

HOwever... I'm not seeing hardly any variability in this latest job where the DX-RX (1080p) units are hanging off a DVX; I'm only seeing a few seconds variability in time for connection to master in the DVX box after a reboot or network disruption. That indicates a lot of the variability in those DX-RX units coming online is actually due to going through an SDX, but... this has not been verified or confirmed, it's just the leading theory based on available evidence.

That doesn't change the fact there's still a boot-race condition with the DX-RX network link vs. code execution; My first suggestion remains a separate network run directly to the device, or barring that, move your downstream IP device connection attempts inside the DX-RX online event.

fogled@mizzou

Another installation, another bad DVX box. This time, a 3255; DXLink in Port 9 would not work.

I swear AMX ships literally half of all their defective products to me, one person. I'm just lucky like that.