|
Joined: Jul 2017
Posts: 10
Pikka bird
|
OP
Pikka bird
Joined: Jul 2017
Posts: 10 |
For reasons unknown the status logs are being redirected to other server status log files...
status.freenode.log -> status.Rizon.log status.Rizon.log -> status.DALnet.log The DALnet log ends up with both freenode and Rizon entries within the log file.
When the redirection occurs it isn't instant and seems to happen periodically, without mIRC being restarted.
This also happens to be the order the servers are loaded in the switchbar/treebar (freenode, Rizon, DALnet)
Some of my settings to possibly help you reproduce.
I have Joins/Parts/Quits events suppressed (Hide setting) except for 1 channel events being redirected to status window on freenode and Rizon. DALnet events settings are default (show in the channel).
Log settings...
Automatic log and reload -> All checked
[X] Lock log files [ ] Trim log files to [X] Timestamp logs [X] Strip codes [ ] Line colors [X] Include network [ ] Make folder [X] Date filenames (by Month) [X] Except status
Thanks!
Last edited by bewilder; 06/08/17 12:16 PM.
|
|
|
|
Joined: Jul 2017
Posts: 10
Pikka bird
|
OP
Pikka bird
Joined: Jul 2017
Posts: 10 |
Log file details You can see the DALnet.log is less than a week old and has already reached 28MB. While freenode.log is a month old and only 67KB. The data is actually being flushed down the line and gathering in DALnet.
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
Thanks for your bug report. How are you connecting to the servers? Are you using a script that uses /server to connect to all three networks on startup?
|
|
|
|
Joined: Jul 2017
Posts: 10
Pikka bird
|
OP
Pikka bird
Joined: Jul 2017
Posts: 10 |
Yes, I have a script that uses /server on startup but only for freenode at this time. Rizon and DALnet /server lines are commented out at the moment and have been for weeks. I have been connecting to Rizon and DALnet manually because I don't always want to connect to them everytime I open mIRC.
I right-click the lightning bolt when connecting to Rizon and DALnet. Not the /server command.
Last edited by bewilder; 09/08/17 11:33 AM.
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
Do you have entries for the servers that you are connecting to in your servers list, each with the correct group name? If you do not, then mIRC will create a shared status.log file for all status windows which only gets renamed to use the network/group name once it has connected to the server and the network/group name has been determined from numeric 005. This will cause any servers that do not have pre-connect group names specified to use the same log file. This is a known issue and was addressed some years ago (there are several previous posts regarding this issue), however the feature was reverted as users thought the solution made managing log files too complicated.
|
|
|
|
Joined: Jul 2017
Posts: 10
Pikka bird
|
OP
Pikka bird
Joined: Jul 2017
Posts: 10 |
That was the problem, the servers were non existent in the server list. Since I used the /server command at one point in the past they were in the recent menu when right clicking the lightning bolt. Logging now works as expected...
I have retry enabled with 'Try next server in group' checked, if it happens to connect to a 'Random server' will that cause problem again? Or would that only happen if two server connected to a random server? Maybe it would be a good idea to remove the random server entries. Thanks.
|
|
|
|
Joined: Jul 2017
Posts: 10
Pikka bird
|
OP
Pikka bird
Joined: Jul 2017
Posts: 10 |
The logs can still get mixed up even when the servers are added to the server list with the correct group.
mIRC remembers the last server/network you connected to, so, for instance...
When following these steps disable 'Connect on startup'. 1. Open mIRC connect to freenode 2. Disconnect and close mIRC 3. Open mIRC again (auto connect disabled), the status window says freenode
This is where the mix up occurs. (step 4)
4. Instead of reconnecting to freenode, choose another network other than freenode (Rizon for example) and connect
Now looking at the status logs Rizon will have freenode entries and vice versa, it's from switching to another network from the one that was remembered from last connect when the mix up happens.
Last edited by bewilder; 11/08/17 06:15 PM.
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
Thanks, I was able to reproduce this issue. The logging method has worked this way for a long time as there were side-effects with resolving it.
I can change the logging method so that if you are connected to network A, and you /server to network B in the same status window, mIRC will close the log file for network A, open a new log file for network B, and then connect to network B. However, this will result in the following side-effect:
If you have an alias that /echos out connection details regarding network B to the status window before calling the /server command, all those connection details will remain in the log file for network A. For example:
test { echo Initiating connection to network $1 echo You last connected to network $1 on ... echo Your current settings for network $1 are ... server $1 }
In the above case, the first three /echos will remain in the log file for network A as that was the active connection in the status window at the time of the /echos. As the logging method has always worked the way it currently does, this will affect all existing scripts that depend on the current behaviour. On the other hand, the logging issue you describe will be fixed. If no one has any objections to or sees any other issues with this change, I will implement it in the next beta.
|
|
|
|
Joined: Jan 2005
Posts: 192
Vogon poet
|
Vogon poet
Joined: Jan 2005
Posts: 192 |
I would call this expected behavior. As long as I have not made the actual connection to the network B everything that I echo in fact should end up in the previous network log.
Or to look at it from the other perspective: I would rather that few such lines end up in the "wrong" log than the entire logfile ending up in wrong place.
So personally I would be happy to see this change implemented.
echo -a $signature
|
|
|
|
Joined: Jul 2017
Posts: 10
Pikka bird
|
OP
Pikka bird
Joined: Jul 2017
Posts: 10 |
I would also call this expected behavior.
Something else that happens is duplicate data in the logs. The screenshot above with the 28MB file had repeating data like 30+ times. That explains how it got so big.
I see no objections... Therefore, I take it the fix will be released in next beta? Thanks for fixing!
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
The new beta has been uploaded. This fix required quite a few changes to related stable code.
mIRC determines the network name used in the log filename in several ways. First, there is the group name in the server list entry. Second, the network name specified in numeric 001. Third, the ircd version in numeric 004 (deprecated in the next beta). Fourth, in the network token in numeric 005. If no group/network name is found, mIRC creates log filenames without network names, eg. status.log as opposed to status.network.log. In cases where you open multiple status window that connect to the same network, these log files end up merged.
The group/network name is used in many features in mIRC. mIRC has to decide when to use the group name found in the servers list and when to use the network name determined at connect. For example, if you connect and then disconnect, current versions of mIRC revert to the using the group name for the status window (changed in the beta so that mIRC continues to use the network name until you initiate a new connection in that status window). The group/network name is used in many other routines, eg. to determine if any open channel windows are to be closed on connect, if you are connecting to a different network, and so on. So the order in which the group/network name is set/reset is important.
As the code had been stable for some time, the new changes may have side-effects and will need testing. Please let me know how they work out for you.
|
|
|
|
Joined: Jul 2017
Posts: 10
Pikka bird
|
OP
Pikka bird
Joined: Jul 2017
Posts: 10 |
So far so good with the beta fix, working well.
|
|
|
|
|