There is more news. Multiserver operation is possible. A separate LiveTiming folder must be created for each rF2 Dedicated Server. The port to be listened to must then be a different one. Plugin Server 1 Plugin Server 2 And in node Config File index.js Server 1 Server 2 You must open only the Ports 8080-8081 in your firewall.
Hi, which runtime library is needed here please? With a new Windows 2019 Server install und rf2 Dedi only there are no connection between rf2livetiming dll and node server. rf2 brings only 2012 and 2013 in 32 and64 bit. Thanks a lot.
Download the last one at Microsoft ... Search for "Microsoft Visual C++ Runtime Download" and install 2015 version (last one).
@DanRZ there is one problem, if i use the rF2LogAnalyzer for championchip. If you use "clone to modify" funktion, there's a new file named *********E.xml in the Resultfolder. If it so, rFactor2 Dedicated.exe is crashing if you switch to the next session or restart weekend. This has now cost me several gray hairs in troubleshooting. Maybe, do you have any idea? Thank you for more information Best Regards ennimann EDIT example 2023_04_30_21_14_00-77R1.xml -> original filename 2023_04_30_21_14_00-77R1E.xml -> modified by rF2LogAnalyzer
Hello. Maybe disable the plugin, and see if same crash happen. To make sure the plugin causes the crash and not anything else. If the Livetiming plugin causes the crash, there is something unexpected happening in the plugin while results files are cloned and modified. Some data is probably corrupted by that and causes a crash. Check if you have something in log/txt files.
I don't think this plugin accesses rFactor xml log files at all? Or does it? That's strange for xml log file to cause crash... As far as I know rFactor also does not access them.
I'm pretty sure too. But in some cases if some plugin reads two times the same data on two different files, it can reallocate some memory for the second and screw the first one memory allocation. When it accesses first data, it can crash or have unexpected behaviour. Maybe a plugin also checks last result xml on session switch and see two files with same data, instead of only one, like with a wrong pattern on file name and then crashes for a case not expected. In some case, there can be some warning logs, if the coder was aware of those cases.
Hi, thank you. If i disable the Plugin, rF2 Dedi is not crashing. The Result files with "E" are older. If i delete all files with "E", the Plugin is running fine by switch the session. But we need the cloned files for our championchip. ;-) I think, its a problem with the letter lenght of Resultfiles. I don't know why the plugin check this. I found some references to the results folder in the plugin's code. Unfortunately, I'm not that experienced with this type of programming.
I think i also found where the problem is but don't understand the issue. Do you have some logs in UserData\Log\rf2livetiming.log ? And maybe try : SEND RESULTS="0", in rf2livetiming.ini see if it stops crashing. Edit : There is also error.log to check in rf2livetiming node server.
Hi, thanks a lot! The 1. rF2livetiming.log is after dedi crash and with: SEND RESULTS="1" The 2. rF2livetiming_2.log is after run dedi with: SEND RESULTS="0" -> dedi crased also :-( The error.log is zero.
No send but still crash. I will probably give you another dll later with added logs to try analyze where it crashes.
Can you try this dll ? I added some logs to see where it crashes hoping the logs will work in real time. Keep the old one, and use this one instead, then post here the rf2livetiming.log.
I reinstalled livetiming on my PC and reproduced the crash. It was a wrong size array, 29 instead of 30. There is a real bug on file names. The pattern need to be modified. It will probably still crash if you add 2 letters after R1 ... Be cautious. Maybe i can make it more robust. Try this very last one, which doesn't crash anymore with a R1E.xml file. And maybe leave SEND RESULTS="0" in the ini file. I really don't understand what this feature does.
Hm, sorry, unfortunately still no log file but no crash either. I have checked the settings several times.
Activate logs with +trace=2 on your dedicated and see if you have an issue while loading the dll (trace... .txt). I tried on my local dedicated and had the crash on "next session", right after the first practice with the original version. With the last dll, the crash disappeared. And i made another version that don't try at all to read files and don't send results with the ini at 0. It doesn't read any files now if SEND RESULTS="0" in the ini. I will make the test in my real hosted dedicated server with the very last dll (Windows 2019 server) and see if it still works. I already had issues with the Runtimes version used when generating the dll. If you want to try this one, here it is. Make sure the server is totally stopped before copying the dll.
