Graham Peter Davis posted on Mon, 13 Jun 2011 12:22:28 +0000 as excerpted: > On Mon, 13 Jun 2011 11:52:03 +0000, Graham Peter Davis wrote: > >> I select "Get new headers in subscribed groups" and it does a few and >> then stops at 0/17. I've tried cancelling all the tasks and trying >> again, selecting all groups and "get new headers in selected groups", >> closing down and restarting. Presumably, similar to when TB gets its >> knickers in a twist, I've got to edit/delete file(s) (in .pan2) but >> which one(s)? > > Or I could just go away and leave it! Whilst I was away, it just decided > to start working again. Mind you, I'd left it before for an hour and > nothing happened. Weird.
Three possibilities: * A server went offline: If you have multiple servers configured, one went unreachable for a period, then came back. Note that when you check headers (um, overviews...), pan creates a task for each server that a group appears on. So if a server carrying 17 subscribed groups goes unresponsive, you'll get 17 stalled tasks, even if you have pan set to / post/ to a different server for those groups. You can get the same if you have say five such groups and try three times, plus try downloading two messages that appear on only that server (3*5+2=17). You'll get similar behavior if a single "server" is in reality a many- server backend, perhaps categorized, one server (or server group) for multi-part binaries, one for single-part-binaries, one for text groups, and one of the server-side servers it's mapping to goes down. Or, if your connection hiccups and the server is left with a bunch of stale connections that are still counting against your allowed connection total, it may not allow further connections until the stale ones timeout. With the common highwinds commercial server products, I believe there's one default timeout set to 15 minutes and another to three hours. (And, unfortunately, I've seen it get connections stuck more or less permanently, that you have to contact the server admin and have them manually kill, as well.) If you happened to trigger that three-hour timeout... * Massive multi-million header (generally binary) group(s). These can cause pan quite some pain as it doesn't scale as linearly as it might in this regard. Things are **FAR** better than they used to be, but if it has to thread multiple millions of headers, as might happen when you first add a new heavy-use binary group or if you haven't visited/ refreshed a group for a time, it can take awhile. Tho this probably was NOT your problem, as AFAIK, pan's entire GUI can appear to freeze in this case. * Interfering local applications. Some time ago people were having problems with pan going unresponsive for long periods when they were running gnome, but NOT when they ran kde, or something else. That was kind of strange as pan is considered a gnome app, with gnome-hosted bug- tracking and main public repository, etc. So if anything, gnome SHOULD be the one with LEAST problems. But as it turned out, there was some gnome accessibility daemon that Ubuntu had decided to enable by default, that... somehow... conflicted with pan, so pan could make essentially no progress sorting and threading headers after it fetched them. Again, this probably doesn't apply to your case since AFAIK it made pan's entire GUI unresponsive, but that one was a humdinger to trace/debug since it only occurred with gnome and only if this daemon happened to be active. First we had no clue, then someone quite by accident noticed that pan worked fine in kde but not in gnome and for a few weeks/months we were telling folks not to run pan in gnome if they were affected, while I had people comparing library versions and all sorts of exotic stuff. Then I think it was Walt that finally made the connection with the accessibility daemon, after which it was easy enough to piece together the rest, that Ubuntu was now enabling it by default. The thing to realize about that one is that while that accessibility daemon is the only known trigger so far, if it could do it, something else running locally could probably do it as well. Altho, I think part of the problem there was that the daemon was running at a higher priority, under the assumption that people using it would be needing it to interface with their computer at all, and it and pan were apparently contending for some internal resource (presumably a kernelspace lock of some sort), such that it was essentially locking up pan, and very possibly the accessibility daemon as well. But we didn't have anyone reporting that actually needed the daemon, so once Walt nailed it, it was easy enough to tell people that pan and it were simply incompatible and that if they wanted to run pan they had to turn the accessibility daemon off, which people happily did since they didn't need it anyway. ... That means the offline server thing's the only real possibility I know of, here. If it doesn't apply, then... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/pan-users
