Thanks for your bug report. Unfortunately I have not been able to reproduce this issue so far. mIRC unsets UPnP ports automatically when a socket is closed.
In my tests, I monitor UPnP port usage through the router UPnP web page and through the
PortForward UPnP utility.
/socklisten -p Name 80
-> adds UPnP port 80
/sockclose Name
-> removes UPnP port 80
If several /socklisten requests are created for the same port, eg:
/socklisten -p Name 80
/socklisten -p Name2 80
/socklisten -p Name3 80
Any /sockclose on one of the above sockets will remove UPnP port 80, which is the only potential issue I have found. mIRC should probably look through its entire list of open ports, across all features, to determine whether any other internal sockets are using that UPnP port, and leave it open if that is the case.
If you restart your computer, are you able to reproduce this issue? If not, it may be due to network/UPnP/router issues.
Update: After more testing, it looks like this could be down to intermittent network/UPnP/router issues. When using PortForward, every so often it will suddenly report that it is unable to monitor the UPnP settings on the router, even though it was able to a few moments ago. mIRC also reported this issue occasionally in the Ports dialog. It is difficult to say exactly why this is happening. UPnP has always been a bit unpredictable and a search through Google shows up a large number of UPnP issues. It may just be that it is not 100% reliable.
