Netremote displays info only after few minutes

[VSDomotics]

When I connect my Netremotr client, th eclient does not show anything send by Girder. When I check the NR variable watcher, there is nothing received. The Girder log says ''Communcation Server - existing client" then Connection authenticared; connection from.....;adding client....; registering NR client; New client connection;starting feedback thread voor laptop-geert;conncted and synchonising client laptop-geert.
But again, nothing shows up on the NR Client. Also resnding info does not help. Girder receives the NR command fine. After a few minutes, I haven't done anything, suddenly the info is displayed. Ther is no extra entry in the log.
When I disconnect and reconnect, this info is showed immediately. The info shown in the log is exactly the same like when the info does not show up.
Rob something for you?

[danward79]

Does this relate to your issue...

http://www.promixis.com/phpBB2/viewtopic.php?t=14226&start=0&postdays=0&postorder=asc&highlight=

[Rob H]

Sounds strange - is this using version 0.24 of NetRemote.lua?

[VSDomotics]

Dan, thats looks very much like your problem. I would say exactly the same.
Rob,Yes I am using 0.24.

If I can take part in debugging the problem I''l be glad to.
Now its time to go to sleep; tomorrow I'll be back.

[Rob H]

How is your NR client connecting to Girder - over WiFi? Is it PPC or Win32?

[VSDomotics]

It is a connection over Wifi. It's a Windows XP Pro machine it's running on.
One very interesting thing I noticed. When NR connects the ustilization of Girder raises to about 100%. This probably caused the slowness the info is displayed on theNR client. The thread is very busy doing thing I am not aware off so there is little time left to do its normal connection job.
After disconnecting the NR client, in a few seconds the utilization falls back to normal. This happens all the time I connect and reconnect.

[Rob H]

Right - so that eliminates it being a problem that just affects PPCs.

I think this is almost certainly one for Ron to look at.

[VSDomotics]

When I wait until the screen on my client is drawn (few minutes) and I disconnect and then start NR again, the info is shown immediately.
The strange thing however, when I restart Girder, the NR clients also displays immediately after a new connection. I'll try to pinpoint the problem further.

[VSDomotics]

Is anybody working on this?

I noticed when Girder has run for a while (now it has run for about 12 hours) and I want to connect my NR client, this happens again.

[Ron]

I am looking into this.

[VSDomotics]

Any success yet?
Some additional info.
Today I could not get the NR clients receive any information at all. Girder had run for about 30 hours. Also connections from different PC's could not be established. I noticed the connected-client-list stayed empty too. (table.print(NetRemote.GetConnectedClientList()) was nil). After restarting Girder, the clients connected immediately again and the table was filled.

[Ron]

Did Girder exited normally? Next time can you try a script reset?

[VSDomotics]

Yes, exited normal. I did not try a script reset. I did however uncheck the communcationsserver, applied and checked it again. I think a (kind of) script reset was then done. This did not solve the problem.

Also I activate the low level debugging option because I thought the program would possibly be in a kind of loop (als because of the high utilization) but nothing special showed up.

Next time I will do a script reset. If there are other things you like me to check; please let me know.

[Ron]

Attached you'll find a replacement comserverlib.dll, please this in the girder directory. Next time the comserver appear to hang please start debugview (google it). This will log some output from the plugin so I can start tracing this bug.

[VSDomotics]

Hmm, Yesterday I made a posting with the attached log; now I can't find it back. Nevermind, I'll tell the story again.

Yesterday, after about 5 hours of not using a NR Client, I started debugview and connected the NR client. It took more then a minute to connect. Attached you find the log. I think at about line 580, the information showed on my NetRemote screen.

This morning, now the 4.0.4 is installed, and I forgot the install the prepared comserver, NR took long again. After 30 seconds I stopped NR (nothing displayed yet). Then I did a script reset and started NR again. Now the info displayed immedeately.

I noticed now its not allowed to attached a file with the extension 'log'. Thats probably what went wrong yesterday. I'll strip the extension and try again. Now I get 'The Extension array is not allowed'. Try again with 'txt'.

[Promixis]

Can now upload .log files

Ron is out of town until Sat/Sun :x

[Ron]

Thanks that gives me some clue as to what is going on. Tomorrow when I am awake I'll do some hunting.

[Ron]

Alright, this one does not fix the problem but should help me exactly locate the bug. Please do the same as last time. Post the debugview again when the hang occurs. Thanks.

[VSDomotics]

Saddly my bugreport of yesterday got lost again.Probably still nog *.log as attachement allowed. I will try again.

After 15 hours running Girder I started debugview and then Netremote. This is the log. It took again quite long before something was displayed.

(I renamed the file again to*.txt because *.log is still not allowed.)

[VSDomotics]

Did you find some time to look into this? Is there anything I can do?

[Ron]

I missed this post yesterday. When you captured this one did Girder hang like before? From the log it seems like everything was running just fine. Looks like NetRemote.lua was syncing NetRemote up.

[VSDomotics]

I think you can see in the log it took more then a minute before Netremote displayed anything. In the start you see with a few seconds interval, something happening. After some time you see within a seconds very much info being transferred. This is the moment Netrmote starts displaying. Girder does not really hang but has a very high utilization. I think this high utilization is the key to the problem. This is why it takes so long before NR is displaying. Girder has not enough time left to send the info quick. It is doing somethin else (sadly I don't know what) what keeps it very busy.
I am off to bed now. Tomorrow I'll look if you need more info.

[Ron]

Not sure what to do, that time is spent outside of the comserver plugin. Let me know when you get another one of those lockups where girder simply doesn't respond at all.

[Rob H]

If you have any plugins left that aren't actually in use then can you try disabling them.

If at all possible try disabling all plugins other than ComServer and see how it goes. If the problem doesn't recur then add in plugins one at a time.

[VSDomotics]

The problem is when I disable a PlugIn, the script gets reset and the problem is then gone for a while.

Is there a way to find out what Girder is doing when it is that busy?

Can I increase the logline beyond 1000? I like to see low level messages when I start NR. The problem is however, these lines don't dislay when Girder is busy. Only when Girder is quiet it displays again but most of the line by then are already gone.

Is there a way to find out if Girder sticks in the Netremote LUA?


Let me know when you get another one of those lockups where girder simply doesn't respond at all.
I don't get total lockups. Only a very busy Girder and the NR client slowly showing info.

[VSDomotics]

I noticed when Girder has run for a longer time (more then 8 hours or so), all my Netremote actions (sending data to NR) gives a hughe utilization on Girder. After a script reset, this problem is gone. Sure it is the same thing as showinginfo in NR delayed.
When this utilizationthing is occuring however, Netremote displays immedeately when I disconect and connect. Only when Netremote is disconnected for a longer period (hours) then slow displaying thing starts again (once).

Can't i be a kind of loop/deadlock in the Netremote.lua?

[Rob H]

It's possible - can you also keep an eye on Girder's memory usage on startup, after an hour or so and when you get this problem.

As far as I know though, this only occurs with WiFi connections. I've just got myself a USB WiFi adaptor for one of my machines, so I'll keep an eye on it.

[VSDomotics]

I have a WiFi connection most of the time. This utilization issue however, also happens when I start NR on the same server Girder is running on.

Ever tried to switch 'Low Level Scripting messages' on and then start Netremote. It takes ages before something happens. There is problably a great,great lot of code to run through. On my Xeon 3GHZ processor it takes at least 15 minutes (and now still it does not display)!

Is this an indication?

Memory starts normally at 25M. After a day i increased to 50 M. Then it stays tis high. The strange thing is it sometimes decreases again when I am working on Girder.
According to Mike this is normal behaviour and nothing to worry about.

[Rob H]

Ah, okay, we can ignore the WiFi issue for the moment - that is probably a separate issue.

Turn on low level scripting messages and run any moderately large Lua script and I think you'll see the same thing.

I'm just wondering how the way that you're using NetRemote feedback differs from that of other people who don't have this problem.

That sort of memory usage sounds quite reasonable.

[VSDomotics]

Rob,
Yesterday I installed Netremote.lua 0.17 again. Besides some minor issues, the Netremote client displays the information immediately. Even when I activate the low level logger, It takes just 30 seconds before Girder 'awakes' again and shows the logged lines. Yesterday the logger stuck for 20 minutes and then a killed Girder when I started NR.
This looks very much a Netremote.lua issue. Is there a way to find out what Girder is doing in the Netremote.lua when it starts? Something like the special comserver Ron made to find out what happens there (in combination with debugview.

[Rob H]

Okay, I'll take a look at the differences and see if I can add some more logging

[Rob H]

In the first message in this thread you said that you saw the log entry


Synchronising client ...


Here's a version with a tiny bit more debugging info in the SyncState method.
Can you try this one and see how it goes.

Thanks.

[VSDomotics]

Thsi morning when I started Netremote (after Girder had run for 18 hours) everything showed immediately again. So it has something to do with the differences between Netremote.lua 0.17 and 0.24.
Rob can you look into this. Otherwise I am stuck to 0.17 forever :(

[Rob H]

Did you try the version I posted? - it has a bit more logging

I need to know which messages you get in the log from Synchronising client onwards.

[VSDomotics]

You mean the 0.25 (19-Mar-06)?

[Rob H]

Yes

[VSDomotics]

I'll try that one. But it takes another day before I know more.

[VSDomotics]

Rob, the problems stay the same using 0.25. The whole sequence of logentries appear when I start Netremote.
-Existing client
-Connection authenticated...
-Connection from...
-New client conection
-Adding cient 192.168.10.111
-Registering NR client
-Starting feedback thread for laptop-geert
-Connected
-Synchronising client laptop-geert

Then still noting shows on Netremote. After about 1 minute the info displayed suddenly but no new entries appeared in the log.

Perhaps has my new thread http://www.promixis.com/phpBB2/viewtopic.php?p=143498#143498 has something to do with it?
Not every Netremote user probably uses this csevent so frequent as I do (I have to use because event.exe does not work anymore as in Girder 3.3). This could make the difference between having these problems as I do and experiencing no problems at all.

[Rob H]

Okay, that helps - 0.25 should added a couple of messages to the log that are clearly not being displayed there.

Having said that, I'd have expected you to see two more messages :-

Done local cache laptop-geert

and

Synchronised client laptop-geert

If those aren't displayed then it looks as though there's a problem with the cache.

I take it that you use NetRemote.ClientSetVariable or client:SetVariable rather than the global NetRemote.SetVariable ?

Do you ever send images or tables to NetRemote?

[VSDomotics]

Tomorrow I will look for the missing logentries. The problem is I receive a lot loglines in the time Netremote starts. And I can't copy thes lines :cry:

I take it that you use NetRemote.ClientSetVariable or client:SetVariable rather than the global NetRemote.SetVariable ?
No, I don't use it; only the global.

Do you ever send images or tables to NetRemote?
I do sometimes but in the evening I stop Netremote and restart Girder. Next morning I start Netremote. In the initial startupevents updating Netremote, there are no image- or tablesending commands it stil get the slow displaying.I have until then only used Netremote. Setvariable.

[Rob H]

What do you do with these events received from csevent.exe?

[VSDomotics]

I use csevents for processing Performance actions from the Windows Performance service and for receiving events from my ISDN monitor program.
See: http://www.promixis.com/phpBB2/viewtopic.php?t=14383&highlight=

Normally I don't receive many events but in case of very high utilization of certain processes events are generated very frequent for a few seconds. Today I tried again to use event.exe instead of csevent but it does not work. I can't trigger events from programs which run as services under Windows. I tried changing prmissions, running using 'runas'. But nothing works.

Is it an idea to get the connected port from the communicationserver and let netremote only react on this port (gir.AddEventHandler("^portnr:",232,232, "NREvent").

[Rob H]

That won't work as the port can be changed, and is the same for csevent as it is for NetRemote I believe.

Besides which the only event I get from comserv is the 'New Client Connection' event.

Just to clarify - the problem is that you are using a program that opens a connection, sends a single event, and then closes the connection.

If you have another PC on your network that's running Girder then you could use csevent to talk to that and use Girder2Girder to forward the events to the real copy of Girder. That way you'd not get the opening and closing of connections to the copy of girder running NetRemote.lua

[VSDomotics]

This was the solution I got from Ron. I did not get the idea he would adapt his event.exe to let it work like it did in Girder 3 (and make it usable again).

Can't Ron and you work out a solution to split the the informtion? Csevent has a parameter to specify the port it will connect. Or is this not a real solution? Also we don't know yet if this is the real problem.

Have you looked in the print statements not showing?

[VSDomotics]

Hi Rob,
This morning I started Netremote and the info displayed immediately! I think the only changes made are the new netremote.lua with debugprintoptions. I also did not start the low level debugger before starting Netremote. Oh, one other thing; I also upgraded to the lates Netremote (the old one had expired). Could this make a difference?

I think we better wait until the slow behaviour is more clear. Tommorrow I will try again and then, if it is still good, replace the netremote.lua for the 'production' one and see what happens.
Thank you so far. I'll keep you informed.

[Rob H]

I'll keep my fingers crossed

[danward79]

Personally, I found low level debugging cause my system to slow down considerably, when I tried it I would avoid it if poss.

[VSDomotics]

Dan, it was just to try find out what was happening in Girder when starting NR. This lowlevel is not really of any use becuase of the extrem delay it is causing.

[VSDomotics]

Here I am again. This morning it was wrong again. This time I saw messages in the LUA-log.
NR Loaded
syncing var TS.Baro:Luchtdruk 1012 Hp
syncing var Day1.Condpm:voornamelijk droog
syncing var LogLine5:08:24:32 PIR Zitkamer
syncing var PrintLogPHC:0
syncing var RunTime:Run: 9u. 55m.
syncing var Day1.Winddirectionpm:NW
syncing var LogLine6:08:24:27 PIR Eetkamer
syncing var TS.CallerID.15:28-03 09:59: VSHolding - Max de Vries (mobiel) - 0651819467
syncing var TS.CallerID.1:04-04 20:30: Privé - Flip en Wilma Wever - 0592543666
syncing var TS.Humid:Luchtvochtigheid 100 %
syncing var Day4.Humiditypm:84 %
syncing var Day1.Windspeedam:5 bft
syncing var RadioMute:1
syncing var TS.CallerID.14:28-03 11:22: VSHolding - Deloitte en Touche - 0591657800
syncing var TS.LastUp:Laatste Update 6:55:00
syncing var Day4.Winddirectionam:ZW
syncing var PrintLogEvents:0
syncing var Day2.Rainpm:20 %
syncing var PCVolume:42
syncing var InfoLine3:FUGA[00:05:17]: <0001039093>
syncing var NRLogErrors:1
syncing var Day1.Dayanddate:Woensdag, 5 april
syncing var Day3.Condam:'s middags regen
syncing var PrintLogErrors:1
syncing var LogLine4:08:25:30 PIR Eetkamer
syncing var Day1.Rainpm:20 %
syncing var Day3.Humidityam:73 %
syncing var Temp7:CVaanvoer 29.34 C.
syncing var WeatherCurrent.Summary:Het Weer: licht bewolkt, temp 4 C, luchtvochtigheid 79 %, gevoelstemperatuur 0 CC wind 6 bft km/h, NW.
syncing var Day1.Windspeedpm:4 bft
syncing var ATAG:0
syncing var TS.CallerID.8:31-03 10:43: VSHolding - onbekend nummer - 0263191919
syncing var humidity.current:79 %
syncing var LogLine2:08:26:16 PIR Overloop
syncing var Day4.Windspeedam:6 bft
syncing var Day1.Sunrise:6:59 AM
syncing var NRLogGALAXY:1
syncing var LogFHZ:1
syncing var Day1.Rainam:20 %
syncing var MotionDetect:1
syncing var MasterVolume:25
syncing var Day2.Windspeedam:5 bft
syncing var Status.DeurJannyOpen:0
syncing var InfoLine2:PHC[08:27:12]:RIO7-1=Link I | PIR Eetkamer (EMD03.12 Ein > 0 Sek)
syncing var Day3.Windspeedam:5 bft
syncing var PHC:1
syncing var TS.WindS:Windsnelheid 3 (matige wind)
syncing var NRLogEvents:1
syncing var PrintLogTel:1
syncing var TS.CallerID.7:31-03 10:54: Fax - onbekend nummer - 00<unknown>
syncing var Day1.Humiditypm:87 %
syncing var LogEvents:1
syncing var Day1.Condam:veel zon
syncing var FHZcount:FHZ: 0
syncing var ATAGcount:ATAG:Off
syncing var Day2.Condpm:licht bewolkt
syncing var FUGAcount:FUGA:36
syncing var StoredEvents:NO Events
syncing var Day2.Condam:licht bewolkt
syncing var NRLogATAG:1
syncing var InfoLine1:ICPCON[08:27:44]:08:27:44;21,47;20,74;15,99;16,92;16,44;18,83;29,3 4;29,64
syncing var GALAXY:0
syncing var NRLogTel:1
syncing var temp.current:4 C
syncing var InfoLine4:---
syncing var PrintLogICPCON:0
syncing var MasterMute:1
syncing var Day4.Condam:plaatselijke buien
syncing var Temp3:Slaapkamer 15.99 C.
syncing var TS.CallerID.3:03-04 20:43: Privé - onbekend nummer - 0592580765
syncing var Day3.Temp:11 C / 3 C
syncing var LogLine3:08:25:39 PIR Zitkamer
syncing var RadioVolume:39
syncing var PrintLogFHZ:0
syncing var MailCheck:1
syncing var Temp8:CVretour 29.64 C.
syncing var TS.TempCel:Buitentemperatuur -2.2 graden
syncing var Temp5:Fitness 16.44 C.
syncing var Status.BuitenLicht:1
syncing var Day3.Winddirectionpm:ZW
syncing var Status.KelderdeurOpen:0
syncing var TS.WindD:Windrichting West-Zuid-West
syncing var TS.CallerID.5:03-04 09:53: VSHolding - geen nummerweergave -
syncing var TS.CallerID.11:29-03 13:38: Privé - onbekend nummer - 0546531964
syncing var Temp6:Overloop 18.83 C.
syncing var cond.current:licht bewolkt
syncing var Day4.Condpm:licht bewolkt
syncing var TS.CallerID.10:29-03 14:45: VSHolding - Max de Vries (mobiel) - 0651819467
syncing var PopUpWeb:0
syncing var TS.CallerID.6:31-03 10:57: Fax - onbekend nummer - 00<unknown>
syncing var suns.current:8:13 PM
syncing var Day2.Rainam:20 %
syncing var PopUpWeb.URL:about:blank
syncing var Day4.Winddirectionpm:ZW
syncing var NRLogFHZ:1
syncing var Away:NOT Away
syncing var Day4.Windspeedpm:4 bft
syncing var sunr.current:7:01 AM
syncing var Day3.Sunset:8:19 PM
syncing var Day1.Temp:7 C / 1 C
syncing var vis.current:?
syncing var Day3.Winddirectionam:ZW
syncing var ICPCONcount:ICPCON:2244
syncing var Day2.Dayanddate:Donderdag, 6 april
syncing var Day2.Temp:9 C / 1 C
syncing var Day1.Sunset:8:15 PM
syncing var LogErrors:1
syncing var NRLogICPCON:1
syncing var Day4.Sunrise:6:52 AM
syncing var Status.AlarmKantVolledig=:1
syncing var Day4.Temp:9 C / 3 C
syncing var TS.CallerID.12:29-03 09:49: VSHolding - onbekend nummer - 0505445151
syncing var LogATAG:0
syncing var Day4.Dayanddate:Zaterdag, 8 april
syncing var Day3.Windspeedpm:4 bft
syncing var Day4.Rainpm:20 %
syncing var Status.AlarmWhVolledig:0
syncing var wind.current:6 bft, NW
syncing var NRLogPHC:1
syncing var Status.AlarmWhDeel:0
syncing var GALAXYcount:GALAXY:Off
syncing var Day3.Rainpm:40 %
syncing var Day3.Rainam:30 %
syncing var Day3.Sunrise:6:54 AM
syncing var TS.CallerID.2:04-04 15:32: Privé - Flip en Wilma Wever - 0592543666
syncing var Day3.Dayanddate:Vrijdag, 7 april
syncing var Day2.Winddirectionpm:ZW
syncing var LogTel:1
syncing var PrintLogGALAXY:0
syncing var PrintLogFUGA:0
syncing var NRMuteStatus:
syncing var FUGA:1
syncing var Day2.Winddirectionam:W
syncing var Day2.Humiditypm:82 %
syncing var Day2.Humidityam:76 %
syncing var Day2.Sunset:8:17 PM
syncing var Day2.Sunrise:6:56 AM
syncing var Day4.Rainam:40 %
syncing var uvindex.current:0, laag
syncing var LogGALAXY:0
syncing var FHZ:1
syncing var Temp2:Hal 20.74 C.
syncing var Day1.Humidityam:70 %
syncing var Day2.Windspeedpm:4 bft
syncing var Day1.Winddirectionam:NW
syncing var Temp4:Garage 16.92 C.
syncing var Day3.Humiditypm:82 %
syncing var Day4.Sunset:8:21 PM
syncing var Day4.Humidityam:75 %
syncing var TS.CallerID.4:03-04 12:46: VSHolding - Max de Vries (mobiel) - 0651819467
syncing var Temp1:Eetkamer 21.47 C.
syncing var Vacation:NO Vacation
syncing var cc.lastup:04-04-06 10:00 PM
syncing var PopUpWebTimer:1
syncing var PHCcount:PHC:157
syncing var LogICPCON:1
syncing var dewp.current:1 C
syncing var uvtext.current:laag
syncing var gust.current:-
syncing var LogFUGA:1
syncing var Status.DeurGeertOpen:0
syncing var ToBed:NOT ToBed
syncing var pres.current:1014.6 mb
syncing var pres.trend:constant
syncing var feels.current:0 C
syncing var TS.CallerID.13:28-03 19:27: Privé - Jaap Mobiel - 0651433440
syncing var NRLogFUGA:1
syncing var TS.CallerID.9:30-03 19:41: Privé - Ma Hendriks - 0592541584
syncing var Day3.Condpm:regenachtig
syncing var PCMute:1
syncing var LogLine1:08:26:36 PIR Eetkamer
syncing var ICPCON:1
syncing var LogPHC:1
syncing var PrintLogATAG:0
syncing image moon.current:H:/Girder/Images/moon/maan_frame_006.bmp
syncing image Weather.day1pmpic:H:/Girder/Images/weather/33.png
syncing image Weather.day1ampic:H:/Girder/Images/weather/34.png
syncing image Weather.day3ampic:H:/Girder/Images/weather/39.png
syncing image Weather.day2pmpic:H:/Girder/Images/weather/29.png
syncing image Weather.day4pmpic:H:/Girder/Images/weather/29.png
syncing image Weather.day4ampic:H:/Girder/Images/weather/39.png
syncing image Weather.today:H:/Girder/Images/weather/L29.png
syncing image Weather.day2ampic:H:/Girder/Images/weather/30.png
syncing image Weather.day3pmpic:H:/Girder/Images/weather/11.png

At about the same sime as the last line in this log in the logger appeared:
Done local cache laptop- geert
This time there was nothing displayed on my NR.
After about 6 seconds I got in my logger (still nothing displayed):
Synchronized client laptop-geert
After about 3 seconds my procedure starts (saw it in the logger) to update the screens of NR (about 50 Setvariable-commands); still nothing displayed
Then it took about 2 minutes before anything displayed on NR. No new entries in the logger nor LUA-log.

In the meantime there appeared about 10 csevent entries in the logger from the communicationserver but nothing what had to to with NR.

It looks when it is an existing client ot goes wrong. But why was it the last two days not an existing client? How is this detected? Last night I did not restart Girder after the last time I disconnected my NR client. Was this the difference?[/i]

[Rob H]

Thanks - that eliminates one possibility.

It seems to indicate that the problem is in processing the queue - unfortunately the only difference between 0.17 and 0.25 in this code is that I've added a queue for sending tables, but if you aren't sending any tables then that won't even come into play.

All I can suggest is that I try putting some print statements in the ProcessClientQueue method - the only problem there is that it will flood the Lua console.

I can't remember if I've asked you, but are you sending any tables?

[VSDomotics]

No, I only send variables and images; no tables.

[VSDomotics]

Rob, last two mornings I have the same problems. I haven't restarted Girder in the evening; iIn the morning starting Netremote then takes a long time. Can you please add some printstatements so we can find out in wich routines the program 'hangs'.

[Rob H]

Okay, try this one.

[Ron]

Rob I am pusing out an update, do I need to sync with your new NetRemote.lua file?

[Rob H]

No, this only contains additional debugging info.

[VSDomotics]

Rob, I changed the printing statement in write-to-a-log commands (and included a th printing of the sended-variables). The printing only shows after Girder is 'quiet' again. And the relevant loglines a then already gone because of the limited number of lines.

I attach a logfile where all the print-statement from one NR session. I started NR (after about a 10 minutes pause), waited till the info was displayed (after about 2 seconds) and then stopped NR again. When I disonnect NR a little longer, the startuptime also increases. The problems are the many empty send-statements I think (but who am I).

What do you think of it?

[Rob H]

That is definitely interesting - the question is why nothing is sent for those commands.

In NRClient:SendQueuedCommand() there are a couple of other commented out print statements - can you convert those to write-to-log calls and we'll see why nothing happens for those commands.

[VSDomotics]

Rob,

I removed all remarks fro the printstatements and converted to printing to log. Also NRFprint to write to log.

I recorded for about 30 minutes. When you search for '04/08/06 21:53:32' you'll find the start of a complete NR session (start, wait until display appears and disconnect). The whole session is between 5 dashed lines.

What wondered me is, when NR is not connected, the always increasing lines with 'skipping label'. Every new setvariable for the same target, seems to let the skipping lines increase by one.

[Rob H]

Ah - that makes sense. And indeed fits with all the known facts.

Can you try this one (NB this hasn't been tested hugely here)

[VSDomotics]

I installed it and did a LUA reset. Then I started NR and stopped it. Tommorow I will see what happens if I connect NR again. It is time to go to bed now.

Do you mean you saw something wrong in the code? If so; why seem I to be the only one having troubles with it?

[Rob H]

It's probably because you are doing things that noone else is doing.

It will be all the CSEvent.exe events that you're receiving - at least some of them seem to be converted to calls to NetRemote.SetVariable. The way that queueing works in NetRemote.lua is that it searches the queue for an existing label of the same name and marks that one with a 'skip' flag. You are receiving a large number of these events and so are building up a very large queue. The version that I've given you includes a fairly crude workaround that packs the queues for a given client so that any skipped entries are removed when that client connects.

This is not a final solution to the problem but should at least demonstrate a greatly reduced delay. I'll probably change the code differently in the production version e.g. so that it doesn't bother to queue anything if the connectionValid property is false.

[VSDomotics]

This morning when I connected Netremote, the info displayed immediately. So your change workes like expected.
I am not sure about your suggestion that is has to do with csevent. During nighttime I do receive only very little csevents (perhaps 25 at total).

Is there a way to reliable check if there are NR-clients connected? I can change my code to only send Netremote commands if there is really someone connected. Preferrable a flag which is set when there is someone (or more) connected and unset when nobody is connected.

[Rob H]

There's no way provided by NetRemote.lua

I'll be making some changes so that it no longer queues anything for disconnected clients.

[VSDomotics]

Are these empty sending lines ( at the start of a reconnection) then gone too? Or only the 'skipping label' entries?

[Rob H]

They should be gone.