And it was working perfectly as I had it open on the bench. Then, as it's been closed up and bolted in the rack, it starts acting up again.
Reminds me of the first CD players at Deutschandfunk, made by Studer. They had their fair share of toothing troubles and after yet another firmware (EPROM) update during the day, they apparently hadn't been used again until the night shift. Suddenly there was excited shouting from the control room of the main studio during the ARD Klassiknacht. I rushed out of the NCR to see if I could assist and found an open-mouthed studio technician next to one of said CD players. What happened?
The CD players ran on fader start and as soon as he opened one of the corresponding faders, the CD tray would come out. Fader closed, CD tray back in. But no start. He spent the rest of the night with deactivated fader start, running forth and back between the CD players and the mixing desk, starting them manually.
The error correction also had its surprises. One night, it got so bad that I had to stop what should have been a Schumann symphony but rather sounded like a balalaika orchestra.
And those Studer players still were, like the PR99 reel-to-reel recorders, among the best you could get. I know the guy who sold us the Studer desks we have in most of our control rooms. He now sells another brand, this time a German one. They're good, but not without their problems.
War story: The control surface TFTP boots from the main matrix computer. So, if the control surface is located network-topologically far from the matrix, the boot is going to take
ages. (TFTP does not have a data-in-flight concept, beyond one 512 byte disk block. So speed is equal to 1000/rtt
ms * 512 bytes per second. Or wire speed of network, whichever is lower.) And to me, this was perfectly obvious, but not to the manufacturer. To their credit, once I'd been able to braindump this, the manufacturer's customer engineer said, "I understand now, this makes sense" and they stopped asking for more bandwidth..