'Could not connect to Matchmaker' Dedi Error Now that I have your attention It's not a fix as such, it's a work around that I have found.. Ever since rF2 was released many users including myself have experienced the 'could not connect to matchmaker' on their dedicated server.. 1. The problem only exists if you are running more than one dedicated rF2 server. I have tried everything from ports, different ranges of ports (ie having one server on port 32000 and the other on 54000). I have tried the one install, copy and pasted, renaming the folder to ie rFactor2_2, changing the profile name and port numbers. I have tried two installs, installing the mods and tracks in each install, changing profile names and ports. I have changed the properties in the links for IP addresses and ports. I have tried one install and creating different profiles with the different ports (and tried different port ranges ie 32000 for one, 54297 for the other). What happens in all instances, is either what ever server runs first you can't connect to the other OR if you can connect to both servers (99% of the time in my testing) either one, the other, or both will display the message 'could not connect to matchmaker'. This happens at random times, could run for days, could run for hours.. Very Frustrating.. When this happens, as many may know by now, is that no one can join your server. You need to restart it before it becomes visable again in the list and for your fellow drivers to join.. What I've noticed in this build (134) is that it's much worse than previous builds, in that I get more of the messages 'could not connect to matchmaker' when trying to run more than one dedicated server on the one server.. Enough ramblings.. The fix.. The fix is only for those who have access to their physical server in full (administration access). As long as you have administrative access to your server (in a datacentre, remote location or in your home/work) you can create another user profile.. I've found that the only way to run multiple servers from the one physical machine (for those trying to run more than one at present) is to either create a VM (virtual machine) for each user / install, or create another user profile.. From here, the rest is straight forward. You now have two alternate logins, two 'seperate' installs, two registry etc etc.. I've run now 2 x rFactor2 servers (with different ports of course) on the 2 x user profiles for a few days now with no dramas what so ever. In my instance I have 2 x communities who use the server, each running rFactor 2. Yes it can be a pain in the backside if you are one community wishing to run more than 1 x rFactor 2 servers, and yes this never happened for rFactor 1 (and still doesn't). In the past I've had 5 x rFactor1 servers running on the one user profile.. My find is simply to advise ISI (and others) of the temp fix until rF2 goes gold (or soon after gold), where in the instance of more than 1 x dedi server is required to be run, it can only be done via seperate VM's or seperate user profiles, this is the only way it can be done to avoid the dreaded 'could not connect to matchmaker'. Hope this helps ISI (in a fix) and others in running (where they can) more than one server.
Thanks for this, good info. I hadn't thought to try running one of the servers from a second user profile (we have several on the server, so individual series admins can do whatever they want without affecting the others), we had done the more obvious things such as changing ports plus changing the user name as suggested in another thread, which seemed to work pretty well until 134 came along (like you, we've had an increasing number of these issues with the latest build). It will take time to help confirm the effectiveness of this approach, especially because of the intermittent nature of it, but I hope this sheds some light on the potential cause and something clicks for someone at ISI. I had a single rF2 server get this message not long ago, which is a bit of a worry, but I'm not sure how long it had been since the last 'attempt' at running two servers and what residual data might have been left, somewhere. There were no denied connections in the firewall logs, anyway, so it seems the issue is either with the matchmaker (perhaps matching the two servers based on some info, and discarding what it perceives is now an outdated server) or the game itself getting confused because of data shared between the servers. Here's hoping the cause is found quite soon, anyway - especially now we're no longer waiting on a gold release, it seems. Half off-topic: it appears it's not possible to autoconnect to a server (including password) via the command line / shortcut as it was in rF1, which was a great way to speed up the connecting process but also bypass issues with the matchmaker service. Is this functionality going to be returning? (very handy for leagues)
It would be nice to see the 'autoconnect' work again and lets hope ISI could shed some light on this also.. Regarding the one server at the time when you got the message.. I too got this once but then restarted and it ran for days without issues (just the one). So I could only put that down to matchmaker being updated at the time or as you say, some residual data in that one instance.. For the above I made sure I uninstalled rF2 from the account I was using, cleaned the registry so it had no residual data present, then installed the full 134 build, installed the mods etc, switched logons (users) and installed.. So far, this has been running none stop for the past 3 days and users are still able to connect to both. I've even been able to change the line 'Pause when zero players=1' where previously if this was paused, it would crash soon after (could not connect to matchmaker).. Report back when you have had some time to investigate also but I'm confident that it will work for you
Hi again Rader, Wonder if I could trouble you for a bit more info on what you have(n't) changed in your installs? Previous to today we ran our rF2 servers via a copy of an rF2 Core folder (local install, packed up and sent to the server), so in our case the registry probably wasn't an issue unless the dedi creates some keys. But as I said, after 'fixing' the issue with the "change profile name and main port" in the previous build we had to look for something else with 134. Got on there today, installed the game under 2 different users, to different folders obviously, with the only common files being a shared packages folder (neither installer got told about it, but using ModMgr to install mods for the dedis I pointed both to the same folder). I then changed the second server's ports (+1000 in all lines, except +100 for the http server), started up one server at a time (just to the first screen, not actually connecting to the matchmaker) to create the player folders and then rename them as before (so the first server has the player folder and PLR set to Server1, and the second server is... wait for it... Server2... ) I left server pausing on 0 and changed minimum voters to 1 (so a single player can join and restart the weekend if it's in qualifying or something). And I'm pretty sure that's all I've changed from the default PLR and multiplayer.ini values. Unfortunately about 3 hours later one of the servers dropped offline. I'm thinking I might have forgotten to do something else that helps a server run properly, but I'm not sure what else there is (the http server, for example - maybe you disabled it because you didn't need it, and that might help the situation) So would appreciate if you can think of anything else you've set in your installs. Still wouldn't be too surprised if it improves over the coming day or two, so we'll keep rolling along and see what happens.
Hi Lazza, happy to help out.. I can say that I turned off the HTTP server (HTTP Server Enabled="0) because this was adding CPU load (see here...) What I will do Lazza, is upload my player and multiplayer file for you.. I certainly didn't go as far as you on the changes, my port ranges are only about 100 apart as I wasn't interested (at the time) of the 'Get Mod' feature, but this will change in time.. From memory (and you looking at the files will see this), the only changes I made were port numbers, Pause for Zero players, Player must stop (the line where players can hit esc without having to come to a complete stop), and maybe one other.. but basically that's it.. Anyway, will post the files tonight for you..
Well Lazza.. Here is what I changed.. Multiplayer.. WAN Join Port="54200" (300 on the other) HTTP Server Max File Size="100" ( It was 200 but I reduced it for some testing at the time and left it, prob has nothing to do with your prob).. Pause while zero players="1" Players while stopped="0" In the Player file.. UnsportsmanlikeSensitivity="0.30000" (only because I was testing the sensitivity, and previous comments I found in this forum on settings). Relative Fuel Strategy="1" One Lap to go warning="3" That's it.. nothing more I looked at really.. Not at the moment anyway.
Lazza.. I have some further development that may assist in your testing also.. Only one of my servers was running the "Pause while zero players="1", last night while I was writing this post to you I decided to switch users and found the dreaded 'could not connect to matchmaker'. It disconnected once before while the other was still running but I put it down to a minor hiccup, changed the settings to "0" (zero players) and ran the server for days with no issues.. Late last week I decided to put it back to "1" for zero players and well, as said above when I switched users, the 'could not connect to matchmaker' message was on that one server, the other one was still running fine.. I will look further into this one setting on the weekend and monitor that one server to see how long it lasts. One thing is clear, the additional user profile is working for me in this build, but the Zero player option may still be an issue which has been for a few builds now..
Well Lazza.. I can report officially that the 'fix' was not a total fix... Although it has 'minimized' the crashes 'could not connect' it does still happen.. I've done everything except open every single port on the router.. Why rF1 can run with not one single problem but this one has 'non-consistant' problems is doing my head in.. I see in the forums fixes for various things, but they don't work for others.. What I find is a fix clearly doesn't work for another, or it minimises for myself.. Sorry Lazza for not being able to find something that was more stable for myself, and for others..
Atleast your having a crack mate...Lazza and myself have tried everything we can possibly think of and like yourself we arnt noobs when it comes to running servers...the way it is at the moment is a joke compared to how smoothly rFactor 1 ran... there should be more official involvement in this problem
Agree Jim.. Last night I restarted the dedi server 3 times, once when only 1 person was in it, the other 2 when no one had been in it.. Many people reporting it but I don't think it's being looked at seriously (can't say for sure no).. We already know it's not an ISP problem as too many people experience this problem all over the globe.. I know that it doesn't matter if your server is in a DataCentre or running behind a router, I've tried both.. Originally my server was in a DataCentre in Queensland, all ports were open and we had this problem.. Now it's at my place behind a router and only the required ports open and still the same issue (although this build is worse).. We know it's not the Zero Players line in multiplayer.ini is not the problem (although it does seem to crash more often if this line is set to '1'.. We know it's not different profiles on one install, 2 seperate installs, or even 1 install per user account... What I also know is, that I am getting older, my hair is going greyer and my head is becoming flatter from bashing it against the wall.. My next test will be to wait for the next build.. It works for some, but it also doesn't work for some and we are not in the same area of the globe, nor have the same hardware.. My specs (if this will help).. Windows 7 x 64 with 4gb ram. It was (before the software upgrade) running Windows XP x32, so it's not an OS specific problem. 2 x profiles. 1 profile doesn't have anything installed except rF2.. it drops out. the other profile has Teamspeak 3 additional to it, but only runs when this profile starts.. I have fibre connection.. 100mb with a 40mb upload. The datacentre was 100mb with 100mb upload.. The machine is a dual core Intel processor. I can run 5 x rF1 servers with not one single problem.. connect to matchmaker and run for days, weeks and probably the whole year if I wanted too.. What I also know.. You can run an rF1 server and rF2 server together, rF2 will drop off, but rF1 will continue.. So connections to Matchmaker (although it maybe a different server from rF2) are still being maintained.. Oh look, I found another grey hair... One day I might be able to play the game long enough to enjoy it..
no answers yet radar ? wonder when we can start the league racing with rf2 then next update or what ? and radar you know we are all waiting for you to sort this out so we can get on with this yrs first league race becoming a joke i think big lack of communication going on some where.
has any1 got an idea we are not just relying on ISI if you are currently running a season with no problems maybe you could drop in with some help TYVM
I think when the next build is released, some of the current problems pertaining to the matchmaker problems we have all been contending with at one time or the other will be addressed. Jeramey posted some-where in one of the other threads, what it will include as I like to call it "a heartbeat" that will poll matchmaker every 60 seconds saying hey we are still here. Also the memory issues with the get mod HTTP:// setting I would hope will be addressed. I fail to see why league play is that much of an issue, if all concerned with administration of there server are aware of the matchmaker issues and can monitor it's behavior. A complete closing of the server application is not necessary, Just a click of the options and then re-enabling to have the server re-appear on the desktop. If I am wrong on any of the above, lets discuss it. Radar, and a couple of others have really wrapped there heads around this try to get temp work around's, and they are to be commended. Dave
You need to adjust the ports to run more than one rfactor dedicated instance on a single machine. Example Instance 1 multiplayer.ini (default) WAN Query Port="44297" // range is 1025 - 65535 WAN Join Port="54297" // range is 1025 - 65535 LAN Query Port="44297" // range is 1025 - 65535 LAN Join Port="54297" // range is 1025 - 65535 HTTP Server Port="64297" // range is 1025 - 65535. Used for file sharing Instance 2 multiplayer.ini WAN Query Port="44298" // range is 1025 - 65535 WAN Join Port="54298" // range is 1025 - 65535 LAN Query Port="44298" // range is 1025 - 65535 LAN Join Port="54298" // range is 1025 - 65535 HTTP Server Port="64298" // range is 1025 - 65535. Used for file sharing Instance 3 multiplayer.ini WAN Query Port="44299" // range is 1025 - 65535 WAN Join Port="54299" // range is 1025 - 65535 LAN Query Port="44299" // range is 1025 - 65535 LAN Join Port="54299" // range is 1025 - 65535 HTTP Server Port="64299" // range is 1025 - 65535. Used for file sharing And so one.... As you can see, you need to give each process its own ports. This is very common and a requirement so the network stack can map a port number to a process running on the machine. You may ask; then how did rF1 work with no interaction? Well, it discovered open ports on the machine and just picked them. Your follow up question may be; why doesn't rF2 do that? There are many posts, now long gone on RSC, about people not being able to connect to rF1 servers. That was because the rF1 dedicated server chose a port that the firewall did not know to open (nor did the admin know without doing a netstat). When instructed people to open a range of ports to accommodate this rF1 dedicated server "feature"; I got many complaints about being forced to open a range of ports instead of given precise control to the server administrator. So now admins have that control. As for using a single "UserData/Player File" location. If server instance 1 is setup even slightly different than server instance 3 you will run in to trouble. The most powerful example I can come up with is weather. You also have the problem of not explicitly defining ports as I described above. I do see your point though about sharing a single data/asset location so you have only a single install of assets. That is something on my plate but I have not had a chance to implement. I also hope in the future to get this number of open ports down to something more reasonable but for now each server opens 3 ports. I also would agree that we need pop up dialog to come up when a port is already taken by another process (which can be anything, not just rfactor) Just to clarify, the WAN ports are what is reported to the matchmaker. You must set up your firewall/NAT to forward WAN ports to LAN ports. As for the fix that Dave mentioned. The matchmaker was picking up what it determined to be malformed data from a rF2 dedicated server. It responded with certain code that caused the heartbeat thread on the rF2 dedicated server to stop sending heartbeats. In this state it would never reconnect. This what I fixed in build 141.
Thanks for this Jeremy, good news. I certainly think running separate server folders is the only realistic option, having a shared data store would be cool but server space shouldn't really be an issue (for a league at least... you rarely need to have hundreds of options all sitting there at once). Having all the ports different is logical too, doing the same with rF1, actually went back to just changing the first port with rF2 because of the servers falling off matchmaker with all the ports different - so just taking blind shots at 'solutions' that worked. Even with several admins, some league members might be on during the night (or very late at night), so if the server has dropped off no one is around to reset it (even when it's as easy as you point out). You could automate that process (when the error is shown, reset the server) but you either have to wait for it to empty or you're interrupting the drivers already on there. Secondly, if the server drops off the list because (or, coincidentally, when) a single driver drops out, that driver can't reconnect until you reset the server - if you're in qualifying that's a difficulty. You can say bad luck, wait til warmup, and then you still have to save the realroad so as to not interrupt the 'weekend' progress - but then you've got things like parc ferme being affected. So yes, there are workarounds and you can be aware of the issue, but in the currently released build it's still a pain in the a***.
Lazza: I got ya I can see now where babysitting it 24/7 is not an option. I understand now ..thank-you! The way Jeremy gave an example of running multiple instances of rF2, Is the way we have been doing it on clients with multi core servers. DedicatedrF2#1 DedicatedrF2#2 DedicatedrF2#3 Yes...a bit of a pain when a new build comes out granted, but the way I do it is as follows. Install the new build, it creates a new folder rfactor2, at the same time, if anything as changed in My Documents, It updates it on the first run. Then I open the rFactor2 folder it just installed, and copy the contents to : DedicatedrF2#1 DedicatedrF2#2 DedicatedrF2#3 and it has been patched, to be sure I run the dedicated.exe from each folder to make sure it patched correctly, and the correct build number loads away they go. Early on I had asked Jeremy about server companies having another option to patch there server instances, he said he would look into it, I would think fixing bugs would be of greater importance at present state of the builds. I know above seems old school to some and why is he posting this?..I post what works for what we do. Jeremy, thanks for taking time to respond and clear some things up. Dave
Thanks Jeremy for posting, but my problems are not with the ports being the same etc.. I've tried different ports and running only one dedi rf2 server and I still get the same problem of random 'could not connect' messages.. I have changed this one server now to the same port numbers you have indicated above, to see what happens.. I can say, that my WAN, LAN and HTTP ports were different, and were Open.. Lets see what happens anyway.. To Dave.. I was doing this same thing until this latest build.. Looking forward to the 141 build..
No difference Jeremy.. Used the same ports as you have indicated above, only running 1 server at the moment and still get the 'cannot connect...' at random.. Some days it lasts for days, others it hours.. Is it OK Jeremy if I send you some info, specs, what's running, other machines on the same network.. If I can help you to norrow it down as much as possible before the next build (or build after).. Is there a log file I could send you that may assist ?
You are right, clicking Options then re-enable works also.. Thank you Jeremy.. Can you also advise on what properties to use (if any) in the command line / shortcut.. I don't think this has been mentioned in the past, and it will rule out any extra that may or may not contribute to our issues or confusion on what we should have in the command line / shortcut.. Looking forward to 141
