If you uncheck "move to top of list on connect", the recent servers list in the file menu is not updated anymore on new connections.
I don't think that option was meant to affect the recent servers feature, especially since the servers.ini has a separate section [recent] to handle that.

~edit~

The above bug exists in older versions of mIRC as well. In 6.32 however, it seems that even with that box checked, servers aren't always moved to the top of the list. This leads to mIRC sometimes trying to connect you to a server using the port range of the server you had previously selected. Try this:

- Load the default servers.ini
- In options, select a server with some open ports and click connect. I tried Starfusion (6663-6669)
- Disconnect, select a server with a smaller port range in options and click connect. I tried Absurd-IRC (6667,7000)

The 2nd server is not moved to the top of the list here, even though the box is checked. This results in connect attempts like this:

* Connecting to irc.absurd-irc.net (6665)
-
* Connect cancelled
-
* Connecting to irc.absurd-irc.net (6668)
-
* Connect cancelled

Very odd. I hope someone can reproduce this, following the steps above.

Without trying it, one thing I noticed is that you cancel the connection attempt, therefore no connection is actually made.
Since the check box is "move to top of list on connect", it makes sense that it would need to see an actual connection before updating.

Can you reproduce this using actual connections, where the first one connects, then you disconnet, then connects using the second?

You are right, when connecting all the way, servers are moved to the top. However, the bug itself remains, only the cause must be another then. I tested again, actually connecting to Starfusion this time, then quit and selected Absurd-IRC. Result:

* Connecting to irc.absurd-irc.net (6666)
-
* Unable to connect to server (Connection refused)
-
* Connecting to irc.absurd-irc.net (6665)
-
* Unable to connect to server (Connection refused)

Clearly it's attempting to use the ports of the previous server for the 2nd connection, which are not available for Absurd-IRC.

As for the other bug regarding the recent servers list, this stays reproducible when connecting all the way as well.

Has anyone else tested this so far?

I don't see how you can make that conclusion from the log snippet you provided.

I also can't reproduce this bug with my list. Can you describe in detail exactly what you're doing? Perhaps provide part or all of your servers.ini in some form (or if its the default just say so).

My test:

I have a group "net" with two servers: test1:6667 and test2:6666

I type /server net and it cycles through the servers properly.

I'm using the default servers.ini for this, and I can make that conclusion because the ports it's trying to connect on in that log snippet are not listed for that network in the file (only 6667 and 7000). I gave that info in my reproduction steps further up.

Also this issue might not apply when using /server. I used the options dialog for all of this, clicked select for the networks and then just clicked the connect button in mIRC.

Tested some more: The issue does indeed not appear when using /server. So I guess the problem is somewhere in the Options dialog, as mIRC only attempts to use wrong ports when using the select button under Connect -> Servers and then connecting via the toolbar button.

If the "move to top of list on connect" feature is enabled, the server is moved to the top of the list regardless of whether a successful connection is made or not. This also updates the "recent" list in servers.ini which affects the "Recent Servers" list in the Connect menu. These are all part of the same feature. The "move to top of list on connect" was actually added long before the other two features - it should probably be renamed "Maintain recent servers list".

So far I haven't been able to reproduce the ports issue, using the same networks that you listed. I tried connecting by clicking on the Connect button in the Options dialog and disconnecting via the Toolbar disconnect button. The correct port range was always used for the connection. I also tried creating two new servers, using a single different port for each, and was unable to reproduce the issue. If you test this with a clean install of mIRC, does it still happen?

1. I see. I thought "Move to top of list on connect" was only meant to affect the list of servers in Options -> Connect -> Servers, not the recent servers list in the menu. Knowing how it's meant to work now, I agree that renaming it would be a good idea.

2. Yes, I'm always testing on a clean install. You say you used the connect button in Options; I stated I was using the one in the toolbar (after closing Options via OK). I just tried your way and couldn't reproduce the issue then. Here are the steps again:

- In Options -> Connect -> Servers, find Starfusion and click the Select button
- Click OK to close Options
- Connect via the toolbar connect button
- Disconnect
- In Options -> Connect -> Servers, find Absurd-IRC and click the Select button
- Click OK to close Options
- Connect via the toolbar connect button

Using these steps, the issue is 100% reproducible for me, with any network.

I tried that earlier and wasn't able to reproduce the issue either. Then as soon as I went back to using the default servers.ini, it was there again. So I played with the settings for a while and I think I found the source of the issue: It's the "Description" part of the servers. As soon as I put the same description for both of my newly created servers, the problem appeared (only when connecting via the toolbar, of course). Now this also explains the reproducibility with the default file: It uses the same description ("Random server") for almost every network.

While testing I noticed again that even though "move to top of list" was checked, servers/networks were not always moved to the top of the list in Connect -> Servers. This issue also only appears when connecting via the toolbar button though, so it must be part of the same problem.

Hope this helps!

Thanks I was able to reproduce this issue, it has been fixed for the next version.