Yes, absolutely. I completely understand and sooooo appreciate your patience and good will. I am certainly not trying to minimize the experience, only point our both sides of the story. It’s never a good idea IMHO to get pointed too far in any one direction either good or bad.
That said I might comment on the “lemon” aspect of the product. There are of course cases where products are lemons. It happens. But this is not one of them (as a category). We see some people having agonizing issues while others it seems to work fine. This is a clear indicator of the bad software it was sent out with and the reason you see such great improvement across the board for the new 3.06 and what is yet to follow.
The original programmer relied upon the poor practice of using time out loops to fix problems. So, for example, the DMP system has to communicate with the Oppo system to work. Our OS says “hey, send me this info or do this thing”. Then we have to wait for a return from Oppo’s OS. The timing of that return data varies and we have no control over it. So, the right way to program this is to build a state machine where the state of our OS depends on the replies from their OS. If we don’t get the right info or in the right amount of time, we can try again etc. That’s not what the original programmer did.
He instead added a separate timer. If he didn’t get a return he added a timer to extend the wait in the hopes of getting his answer. He finged with that stupid loop long enough to where it worked most of the time and called it good. The code is riddled with these sloppy timers, which is why Barry wiped them all out and started over building a proper state machine.
The reason I bring this to your attention is the lemon comment. Think of how this system now works and it’s easy to understand how some machines are worse than others. In some machines the Oppo system works quicker than others and thus, they would be seen to work “flawlessly” like the reviewers. Luck of the draw. Maybe your machines was the opposite and it doesn’t match the timing loop. Dud. Lemon.
When Barry’s code is applied there are no timing loops. Barry’s code patiently waits for Oppo’s reply then executes its commands. Yours will then operate as flawlessly as the next person’s because the minor differences in timing don’t matter (we’re talking milliseconds here).
Had I understood enough of programming when we launched DMP I would never have let it out the door. The unit’s we had to test were all within the parameters that most of the units were. They worked fine. A little quirky, yes, but I had been assured this was an easy fix. Little did I know his “easy fix” was simply extending or reducing his timing loops to get closer. Just bad, bad programming. Something that will NEVER happen at PS Audio again. EVER. We now have instituted code review, systems are in place to ensure this can not happen. Mistakes in coding? Sure. But never again simply bad code.
Shit, I am just an analog engineer but now I’ve had to come up to speed enough to understand what’s going on. Now I do and that’s the reason I agreed to fire the programmer and the reason I hired an expert software programmer to manage our engineering team.