Options
Disturbing NS Issue, looking for illumination
DHawthorne
Posts: 4,584
Lately, I've been updating a lot of systems to replace DVD players with BluRay. Just this week, I had two to do in the same house. We sell a lot of Marantz, and I have found it easier, over the years, to update my own control modules rather than introduce new ones, and my modules are often copied from an older version and updated to accommodate new models. In this particular case, I was swapping out two Marantz DVD players for two Marantz BluRays ... the BluRay module was literally once the same module as the DVD module, with the RS-232 codes swapped out (difference being between standard Marantz protocol and the Denon protocol they use in BluRays).
This house had two systems, and two masters. Since my modules began life the same and used a common interface, all I had to do was change the DEFINE_MODULE line to point to the new module. No problem on the first system; within minutes it was done and working ... just the way you want a modular program to behave on an update.
I expected similar results on the second system. It was smaller, and basically just controlled a bedroom TV and a few devices, where the other system controlled the whole house as well as a theater room. But when I changed the module definition, recompiled and loaded it, the BluRay didn't work. I thought maybe the installed might have goofed up the RS-232 cable, since it needed a different connector than the DVD, so I put the module in debug mode to see where it was going wrong. Much to my surprise, it was still sending the Marantz codes, not the Denon. I recompiled it again, and reloaded it. Still, Marantz codes; even though the DVD module no longer existed in the project and had been replaced, the master was still using it instead of the new module. I was only able to make it work by performing a "clean disk" command on the master and loading it again (with no other changes).
This is a serious issue. I told it to load a new module, but for some reason, it kept the old one. And it did so several times. I am now wondering about all the minor little tweaks I have made in my modules over time, and loaded on to systems without explicitly testing each new tweak. I have no confidence they actually got loaded anymore; I could have systems out there that never got updates I intended them to have, and have only gotten away with it because no one has noticed ... yet. This was a different module, with a different name, and a different size, and different codes (though the overall structure was pretty much the same), and it didn't get replaced.
So what happened here? What triggers the master to actually use a new compiled module instead of the last one referenced, if not the code in the master program?? What happens when it's essentially the same module, the same size, and the same code, with a few bytes different here and there? How do I know for sure my new modules are getting loaded? How do I make sure, without wiping the entire disk every time?
This house had two systems, and two masters. Since my modules began life the same and used a common interface, all I had to do was change the DEFINE_MODULE line to point to the new module. No problem on the first system; within minutes it was done and working ... just the way you want a modular program to behave on an update.
I expected similar results on the second system. It was smaller, and basically just controlled a bedroom TV and a few devices, where the other system controlled the whole house as well as a theater room. But when I changed the module definition, recompiled and loaded it, the BluRay didn't work. I thought maybe the installed might have goofed up the RS-232 cable, since it needed a different connector than the DVD, so I put the module in debug mode to see where it was going wrong. Much to my surprise, it was still sending the Marantz codes, not the Denon. I recompiled it again, and reloaded it. Still, Marantz codes; even though the DVD module no longer existed in the project and had been replaced, the master was still using it instead of the new module. I was only able to make it work by performing a "clean disk" command on the master and loading it again (with no other changes).
This is a serious issue. I told it to load a new module, but for some reason, it kept the old one. And it did so several times. I am now wondering about all the minor little tweaks I have made in my modules over time, and loaded on to systems without explicitly testing each new tweak. I have no confidence they actually got loaded anymore; I could have systems out there that never got updates I intended them to have, and have only gotten away with it because no one has noticed ... yet. This was a different module, with a different name, and a different size, and different codes (though the overall structure was pretty much the same), and it didn't get replaced.
So what happened here? What triggers the master to actually use a new compiled module instead of the last one referenced, if not the code in the master program?? What happens when it's essentially the same module, the same size, and the same code, with a few bytes different here and there? How do I know for sure my new modules are getting loaded? How do I make sure, without wiping the entire disk every time?
0
Comments
Whereas I agree this is a disturbing issue, you might try putting a VERSION? command in your module and having it return the module name/version as a SEND_STRING 0. This would allow you to determine what module code exactly is running.
Perhaps English isn't its first language
Seriously though, this can happen if you change a communication setting and then resend the program without reloading the file. You can end up loading it to the old address and then puzzling over why your changes didn't take. Perhaps you know this already.
Paul
Yup, do that all the time - revision a file then continue to load the project without reloading the files in the transfer dialog and wondering why nothing changed.
Yes, I know that already, and it was certainly not the case. That's one of the first things I check; I also make it a point to recompile everything and load it again, because there have been times when I absent-mindedly (well, maybe more like running on automatic and doing too many things at once) updated a module, but forgot to recompile the main program, causing similar symptoms. I thought of all that. It didn't make a difference.
And I think you missed the part where I said after running "clean disk," it worked. Nothing else changed. I wasn't sending it to the wrong address (this time, I sure have in the past, so I know to look for that), and I wasn't sending the wrong file.
I might also point out that AMX is aware of this, and keeping it somewhat quiet. Just before the turn of the year I had a similar issue, and was advised by tech support to run the "clean disk" command. I was also advised that "clean doc" may not be sufficient. The circumstances were different, but it stuck in my head that the master can, under some circumstances, retain a file that was out of date. What I am looking for now is how to determine when this happens so I can look out for it.
Version numbers are not a bad idea, but I am often in the field tweaking operating systems, and I am not about to start creating a new version for every two lines of code I modify on-the-fly. Nor should I have to. If I modify the code, I want my modifications to take. Those are the cases I'm worried about though; in one like the job my original post mentioned, it is blatant and obvious. I'm not worried about those cases, I'm worried about the subtle and hidden ones where I have made minor little changes and moved on, assuming all went as expected.
What version of NS are you using? Might it be a bug in the new 3.x versions?
If AMX knows about this, where is the fix?
I'm using 3.1.0.374. I suspect it is related to the workspace issue I have alluded to many times here. I have only seen it twice, and both times in systems that were initially created with a prior version of NS, then opened later in the new version (which is what triggers the workspace bug as well). I fear, however, that the fix also wipes out any evidence. I am willing to bet if you ran a "program info" command if you saw the problem you would also see some bad file paths in there.
AMX never officially admitted to knowing of it, I just talked to a tech who seemed to be aware it was possible and knew how to clear it. The implication is they know about it. Typically, AMX operates on a "need-to-know" about bugs like this and you won't hear about it unless (1) you ask about it specifically yourself, or (2) its fixed and announced as a fait accompli.
Can you replicate this bug? It might be something that can only happen in obscure circumstances. The only thing similar to it that I have found is when I was using a CVS server in a different time zone. The module file I would download would end up with a modification date before the creation date of the tkn. I think this caused a similar issue where the axs and tkn were not in sync so changes to the module wouldn't always show up. If you can reproduce it, post how, and we can all try to reproduce it.
Paul
Unfortunately, no. If I run across it again, I'll try to get more information, but this time around, it was a live system and I essentially wiped the master to get it working again. I won't have the opportunity to experiment with this client's system, and wouldn't if I did; not with this particular customer.
But I don't think it is a time stamp issue. The modules had different names. Surely, name should trump time stamp.
That's not a bad idea, and I wish I had thought even to do that manually when I had the problem. It only occurred to me after the fact.