I'm afraid Linux is not my field, but I've forwarded your post to my friend, a Linux guru, maybe he'll have some ideas. Anyone else having suddenly troubles with Airio 2.3.4 running on Linux?
Another suggestion may be to use the !ver command (or some other) directly in server console (or while connected, but with output to chatlines instead of buttons) and see if some lines are shown before the error.
We did some testing of the latest Airio 2.3.4 under Linux with Mono and everything worked as expected, so I'm really not sure where could be the trouble...
As Bunder shows (thanks!) it is not in fact a command, but a configuration option. The example shown means that FXO will be restricted by 3 percents on all tracks... People with lower (none) restriction will be spectated and show what is expected.
We were running Airio for the last months, but as you may know we're having some problems that we are unable to solve
I'm checking the logs and we get some errors form time to time (about two or three per day).
The error is this:
09.09.23 22:35:51 #1 AEGIO ERROR : System.Net.Sockets.SocketException No connection could be made because the target machine actively refused it
at System.Net.Sockets.TcpClient..ctor(String hostname, Int32 port)
at LiveForSpeed.InSim.Aegio.Connection.ConnectionOpen(String hostName, Int32 hostPort, String adminPass, String insimName, Char prefixChar, Boolean hostLocal, Boolean keepColours, Boolean sendNodeLap, Boolean sendMultiCar, UInt16 updateInterval, UInt16 udpPort) in c:\Development Files\LFS_Airio2\Aegio\InSimConnection.cs:line 99
Would you have some tips about this? We are very happy with the system and it fits perfect for our league system, but we really need to solve this before the next league (we're currently racing a little champ) as we're using Airio for the inscriptions
Thanks a lot for the great work and for all the help you've provided to us!
Uhm. Version 2.3.4 added things that solved certain requirements and since I released it some corrections were needed fast. This is all done now and I'm waiting for possible feedback - mostly bug reports. I have no issues that need quick solution now, as far as I can see the new version runs smoothly. And that means I can get back to my real work for a time. I have some nice proposals to implement, such as a warning system or universal pit exit lights, but they're no easy things so I need a small break with real work to keep my family going before plunging back into these.
Are your troubles always of the same nature, that means broken connection? Because that is what the "error" is. It is not a bug, it is a condition when the connection to LFS server cannot be established or gets broken.
Connection troubles may appear when running Airio remotely, by that I mean running it on some other computer (e.g. from your home PC). There are quite a lot of data to be transferred in both directions and if using remote connection, it may fail. In this case server may disconnect Airio, just as it sometimes disconnects other people (connection lost).
My first suggestion would be to run Airio either remotely from a very good (fast, reliable [wifi is not an option]) connection or best run it locally, right on the computer where LFS server runs. Local connection errors are then very very rare events. Hm, in fact I'm not sure I've ever seen one.
If you're running Airio locally already and still get many disconnects, well, then it would require more detailed analysis. Any other troubles you're fighting with? Never hesitate to let me know, either through private message or this thread. Best is also to have Airio log ready in case there's some error.
Today I did some tests. Server is Linux Fedora 10, Mono 2.2-2 and LFS S2 0.5Z.
Resluts: 2.3.3 Full - works fine 2.3.4b Full - crash after any commands. 2.3.4a Free - works fine
Server is Linux Fedora 10, Mono 2.2-2 and LFS S2 0.5Z13. Results: 2.3.3 Full - works fine 2.3.4b Full - crash after any commands. 2.3.4a Free - works fine
Why is the free version 2.3.4x works but not the full version? This is a bit strange. Probably have to downgrade mono version This not good
Thanks for these tests. I'll send you a link to special Airio versions, both FREE and FULL that contain additional syslog messages so that we can see where exactly the problem is.
The interesting fact is that it is Mono that fails for some reason, not Airio. Bugs in Airio are captured, stored into log, the applications stays running. In your case something fails in Mono and the whole process is stopped.
My friend was experimenting with Mono. Using 2.0 he had no problem, using 2.2 he had once the same problem as you. But then he reinstalled Mono, or upgraded to newer version, I'm not sure, and suddenly there was no problem again. All this with one and the same Airio executable...
UPDATE: If I understood the test results correctly, it seems the latest Airio is working fine with Mono 2.0 and Mono 2.4. Strangely enough, it does not like Mono 2.2, causing it to crash...
That's what I supose looking at the error.
From the server hosting they tell us that Airio is running in the same machine as the dedicated servers. It's currently controlling 2 servers, both with great ping times... but the disconnections are there.
They told me also that they use FireDaemon to run Airio as a service. Could this be the source of the relaunching problems? Maybe when Airio gets a socket error it turns off before trying to reconnect and then FireDaemon relaunch it... so eventually they will get those huge amount of Airio instances running and collapsing the server
Not so many data from the servers to find out the problem... if you think that a log or the config files could be relevant just tell me
Mono 2.0 i dont know, but Mono 1.9 and 2.4 Airio work with no crash. One thought: my Mono 2.2 was run in regular user. I can't run it in root user. Now my FULL Airio works fine.
Disconnects from local run are very, very rare. Please check your TCPSendDelay setting in CFG file. If it is set to 0, use at least 5, if it is already set to 5, try 10. These are milliseconds to wait between sending any two messages (commands) to server, which then has enough time to process it.
I do not see any way Airio could "re-create" itself and run in many instances at once. However, FireDaemon is certainly an application that can start by itself new processes, even several Airio instances. But a socket error is captured in Airio and handled, it is not a service breakdown. I'd suggest 2 things here: 1) Get the latest Airio, that is 2.3.4a, because it contains new code in the internal InSim library to capture serious errors resulting from very bad packets that look like coming from server but in fact are completely wrong. 2) Check FireDaemon settings, maybe even change them so that the service (Airio) is not restarted automatically or it is but only when it really completely crashes. But in fact this should never happen, at least not with the latest compile.
Logs are always helpful, especially if they come from the day when several Airio instances were suddenly running, causing memory depletion and then server crash. But I have to say e.g. on AirAttack we're also running Airio under FireDaemon, for days and weeks in one haul, without any problems...
Hi Roby! One of the basic Airio requirements is to use dedicated host. If someone uses graphical host, meaning he starts host directly from the game, then some things will not work for the host quite OK, because connection 0 (the host) is not expected to drive, it is handled in a special fashion.
However, your picture is another case. Here you've connected Airio directly to your LFS instance. That's why there are the failed messages, you've connected it to client (yourself) and not to server. And client connections do not support messages to other connections/players.
If you want to use Airio, even e.g. for home practicing, I'd suggest starting dedicated host and connecting Airio to that host first. Then you can connect with LFS to the host and everything will work as it should.
Yes, that is possible, you just type !sb xrt+rb4+fxo (note that !sb stands for server best and it is exactly the same as !top). To simplify typing, default Airio files (TCD file, to be exact) specify TBO car category and this allows you to type just !sb tbo to get the same output.
If you'll always have on that server only TBO cars, you may use StandardCars item in the appropriate SRV file and set it to =TBO. Any time a car type (or group) is not specified, TBO is supplied, and that means you can then type only !sb and see all TBO cars. Still, !sb fxo will give you only FXO lap times.
Hmmm I thought it was connected to the server. I was using my own dedicated server when I tried to connect Airio, but other players could not see the Airio connect messages. I tried starting Airio, then the server, and visa versa, with no luck.
You could be actually very right, I'll check what happens in case there are numerous breaks in server connection, maybe some listening/sending threads are not closed properly but new ones are started...
The important thing is where you set/type the /insim= LFS command. It MUST be typed directly on server (that is in dedicated server console) or set specifically in server configuration. If you connect to server as a client and then type /insim=, you're setting the InSim port for your client. Airio finds the port open and connects, but to your client.
First start the dedicated server, type e.g. /insim=29999 in its text console. Then run Airio, it should connect to server. Then connect to server as a client and it should be OK...
Both things have very probably a common cause. Current default Airio files allow any operations on stats (such as !clr or !del) only to limads level 5. The catch here is, and I would need maybe to change the default settings, you cannot use super-admin (limad 5) in FREE version, such setting is turned to limad 4.
So you need to use lower level to be able to change stats. Open CFG file, find EnableStats items and set it to =4. Type !rld and the above mentioned operations should work for you. To protect stats, it may be good to change the setting back to 5 later.