Nothing that hasn't always been there. There's no firewalls on any of the machines, only in the Netgear router. There is McAfee anti virus running on this machine, but I would know if that had blocked anything as the icon lights up until you read the message to see what happened, and I'm sorry to have to say it but I didn't have this problem with the last version. Once you had written that Lua script for me, it was fairly trustworthy. I did get the occasional glitch when I lost Passthrough but re starting the software always cured it and I never had a situation of the designer never showing anything in the Lua console. How can designer load the CCF and not load and run the Lua script associated with it? because surely the only way there can be nothing on the console is if the script didn't run. I am probably wrong but I think the reason for loss of Passthrough is because sometimes when Netremote is started it is not running the script, if it was running your script we would have Passthrough to Network-Master, because when it decides to work we have proved your script works. Must be a timing problem or something. Does your script need a delay in it to allow something time to happen? I'm probably talking ****icks I'm good at that :-)
One thing you could try is to use DebugView from www.sysinternals.com - anything that appears in the NRD console should also appear there. I think I'm right in saying that NRD communicates with NR via a TCP socket, so if there's a problem with networking then that could block any text appearing in the console. DebugView hooks into OutputDebugString so should bypass any comms problems. You may also get to see any error messages from either NR or NRD that might give a hint as to what's happening.
Another handy thing about DebugView is that it supports copying text and saving of log files.
You keep saying about networking but I don't see what that has to do with it, Netremote, Girder and the UIRT are all on the same machine, the blasted software keeps trying to link to things on other network machines that are in fact on the same machine. That's the problem, I thought that was clear and I am getting fed up with having to spend all my time off trying to diagnose and get software working that I didn't design and that I don't profit from. I don't mind trying fixes from the vendors but I'm not about to start getting other software to try and diagnose problems with their software. i am stressed enough with the failings of this software as it is.
Any software that uses TCP/IP sockets is subject to the vagaries of Windows networking whether the sockets are communicating with other machines or the same machine. I've just checked, and NRD and NR do indeed communicate using a TCP/IP socket, using the same core classes as Girder and Mediabridge.
I don't recall anyone else having this problem with NRD not communicating with NR which suggests that there's something unusual going on with your PC.
I should have asked earlier, what OS are you running NR and NRD on?
Oh I see. Windows XP, SP2 all updates to this month.
Network is working perfectly, as I said in another post, all girder tcip control of zoom player (Which is on another machine) is flawless, all I/R control done by girder via UIRT is flawless, all I/R control which is done by girder but called for by Net remote is flawless, and last but not least it all worked with the last version. It's just this blasted passthrough.
The only thing I can think of is would there be anything prevented by McAfee during installation of netremote or the editor, do any of them try to modify any system files or run any installation files from the user temp folders or any behavior that would or could look ike a trojan or virus and so which got blocked during the install
May be worth checking the event viewer I guess. Something may have logged something there. Clutching at straws really without some evidence from DebugView.
I've noticed some issues if NetRemote or Designer fail to exit cleanly, where the socket doesn't properly reinitialize for subsequent sessions. A reboot should clear that up, if indeed that's what you're encountering. Making this more robust is on my to-do list.
Wedge, sorry you've had a frustrating experience so far. NR2 is just a beta at this point, so we've got some more work to do before it's polished. We sincerely appreciate all the input you've provided!
Okay, a couple of things there - it looks like the script that looks for Network-Master is running before the connection to Girder is established.
Also, from the position of the "Well hello" in that log the connection to NRD is also coming quite late which would explain the lack of messages in NRD's console.
According to http://www.monitorware.com/en/events...etails_id=2657 the MrxSmb entry could well cause a problem with anything that uses the loopback address 127.0.0.1 which is certainly the case for NRD and possibly also for Girder.
The solution to this is probably to put the contents of that script into a function and call it from a timer. Either that, or trigger it from Girder.
Reply With Quote
