Hide Forgot
When the network outage such as mentioned in bug #123334 is fixed, xchat will automatically reconnect to all servers, and to all channels. However, it does not place each channel in the same tab as it used to be -- the left-hand tab seems to remain unused and labelled '<none>', while other channels receive a _different_ channel to the one whose history they already contain, and a new tab is created for the last channel connected. All the channel histories therefore get mixed up over time, because of this shuffling.
Is this still the case in the latest xchat package?
I've seen it recently, but possibly not in 2.0.10 yet. Will try to reproduce. Certainly I've seen it since 2.0.6 when it was supposed to have been fixed.
It just happened in xchat-2.0.7-6. While connected to a server which was disconnected from the rest of freenode, I did /server irc.ipv6.freenode.net to change servers, then had to rejoin all channels -- and they came back in the wrong tabs.
Just happened again in xchat-2.4.0-3 Changed servers with /server Waited for it to reconnect to the channels Decided it probably wasn't going to Typed /join ... Watched it bring a bunch of them back in the wrong tabs. I was on 6 channels, with six tabs. The first tab is now disconnected. The old channel name is in parentheses. Then there's a new tab with no history, connected to what _was_ the second channel. Then there's what was the first channel, in the tab which previously held the second channel. The third and subsequent channels seem to have got reattached this time -- it's not all off-by-one as I believe I remember it being before.
This seems to be better now, but there's still one annoying bug: if I don't have a separate tab for the server, on reconnect, the `active channel' for that server doesn't get reconnected. (by active channel I mean the channel on which the reconnect attempt messages are displayed, even if the currently-active tab is a different one, from a different server) if I do have a separate tab for the server, on reconnect, the name of that tab often changes to the name of a server I'm not even connected to. This is all with xchat 2.4.3 on x86_64.
This isn't fixed. It's still happening for me with xchat 2.4.3 on ppc. After /quit and subsequent /reconnect, I still see channels reconnected in the wrong tabs. What was six channels: #1,#2,#3,#4,#5,#6 is now seven tabs: (#1),#1,#3,#4,#5,#6,#2 The first tab is dead, the first channel has usurped the second tab, and the second channel has moved to a new tab. The rest are back in the right place.
Still happening in FC5.
Bug is two years old now...
maybe this is somehow a ppc specific problem. Otherwise, I wonder why the CC list isn't longer... Does running it through valgrind present any useful spew?
It was first reported on i386. I haven't tried valgrind -- why do you think that would be relevant? That is; what should I be looking for?
bug is three years old now.
CCing upstream...
/RECONNECT alone seems to work, rejoins all the channels and in the correct tabs (can you confirm that too?). Testing 2.8.2 of course. I guess the whole problem is that after a /QUIT it won't send the JOIN line to the IRC server anymore. This could be made to work for /reconnect.
For me it _usually_ comes back in the right places. But not always. In the three years I've been seeing this, I haven't really established a pattern. Perhaps it's more likely to happen when a reconnect attempt has _failed_ -- it happens more when there's a real network outage, but just suspending my laptop and moving from place to place, then issuing '/allserv reconnect' generally seems OK.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Still happening in F8, for sure. Maybe on rawhide as well, although this problem doesn't get my attention any more to the point that I can tell for sure.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still happening in Fedora 10. Bug is 4½ years old now... It doesn't happen on _every_ reconnect, but often enough that it's extremely annoying.
Still happening in Fedora 10...
And in Fedora 11... 5 years now...
And in rawhide which will be F12...
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.