Julien Michielsen <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 29 Sep 2008 13:46:23 +0200:
> A few days ago I posted a message that pan did not show the messages it > had collected from the server. I got a message from Duncan that the > error probably was caused by an old ~/.pan directory. So - as he > suggested - I created a new .pan2 directory, and everything went fine (I > thought): I could read the newly posted messages, and I thought I could > read messages and use Pan as it was intended. However, a few days later > when I tried to collect new messages, they did not show up in the > pan=panel. After starting up, it shows an upper line showing "File Edit > Go Groups Articles Post Help" and some icons. There below a large panel > which is subdivided in two sub-panels: the left one showing Subscribed > groups and a line Other Groups. The right sub-panel did show messages in > subscribed groups I had not read yet. But at present it is entirely > empty. When I try to re-read a newsgroup I can see a number of lines is > read, but nothing shows up with headers showing the titles and contents > of the messages. Anyone a hint what to do to make the messages visible > (again ;-) ) Thanks The symptoms you describe are somewhat vague, and could be caused by one of several things. Without more info it'd difficult to answer appropriately. The below is sort of shooting in the dark, hoping I hit something that you recognize as possible in your circumstances and can work to check and correct if necessary. Are you still using 0.132? If you haven't upgraded to 0.133, have you checked to see if your distribution has patched that security vuln I mentioned in the other post? (And BTW, which distribution or OS are you using? If I knew that, I could possibly make some of the below a bit more specific.) It should be listed in the changelog, or try searching your distribution's bug database and see if it is listed and fixed, there. It had to do with the way pan handles *.nzb files, including pan's own tasks.nzb. While the problem usually results in a crash, it's conceivable that it might simply fail to fetch further updates (or to clear existing tasks thus the problem) in some cases. I'd call this one not so likely, but because there's a potential security issue involved and there's a known fix, I'm listing it first. Perhaps the simplest fix might be if you set the display to filter messages incorrectly. Under the view menu, header pane submenu, make sure all the "match only" entries (save perhaps for match only unread) are NOT checked. One time I set pan to show only my own messages for some reason, and forgot about it. Needless to say I was left wondering why nothing was showing up, until I chanced across the check, remembered what I had done, and undid it. Similarly, at least for testing, make sure all the "match scores of..." entries are CHECKED. If there's a bad score marking /everything/ ignored, you won't see it unless that's checked, after which it'll be EASY to see what's going wrong. Did you perhaps crash pan, or shutdown with pan running and downloading, or even after simply checking messages for a group without switching to a different group when you were done? Pan saves state for a group only when you change groups, so one thing I've learned to do here is to always switch to a different group when I'm done reading messages and the like, so it saves what I just did in the /last/ group. Fail to do that and you will likely lose the state for that group, tho other groups should be fine. Of course, if you crashed while pan was actively downloading or something, you could lose more. Actually, that's what most often triggers the *.nzb bug I mentioned, but other files may be corrupted as well. What filesystem do you have ~/.pan2 on? ext3? fat? reiserfs (what I use)? Something else? How long has it been since you did a proper fsck on the filesystem? Perhaps filesystem issues are causing things to go haywire. Related to that, have you had any other strange issues with crashes or disappearing files? Maybe it's hardware (failing disk?) related? Under pan preferences (edit menu), on the behavior tab, what are the settings under Groups set to? In particular, are the following set checked or not: get new headers on startup, and when entering group, and to mark group read when leaving group, and when getting new headers? Obviously, if you don't have pan set to grab new headers at startup or when entering a group, you won't get anything new until you tell it to do so. If you have the view set to hide read messages (as mentioned above), you read all the old ones (or had pan mark them read automatically according to your preferences), and you haven't fetched new ones (or there's no new ones to fetch yet), there won't be anything new to display until you fetch new headers. Talking about which... There are three "get headers" buttons. Unless you use the middle one, "get headers in subscribed groups", pan won't do anything until you enter (or select) a group, because the first button works on the group you are in, and the third works on selected groups. .... If the above doesn't turn up anything, maybe it's time to get out the diagnostics tools and see what pan's actually doing. First, run pan from a terminal window. Do your normal thing and see if pan spits out any unusual messages to the window it was run from. Of course, close pan before closing the terminal window. Another thing you can try is the trial and error problem bisection via filesystem approach. Basically, you move your entire pan data dir (~/.pan2, unless your distribution changed it or you you have the PAN_HOME environmental variable set) elsewhere, say to ~/.pan2.test. Then restart pan and see if it looks right, which since it started without a config will be a brand new clean installation, no config yet. If that works, close pan, delete the stub dir it created, and copy some files, say everything but cache, back. Now open pan again and see if it has your setting back, but without what would be expected to be missing based on the files you didn't copy back. Work back and forth by trial and error, deleting files or copying more back, until you find the culprit config or data file. If it's a config file, you can then dive into it, removing parts of it while keeping other parts, until you nail a specific section (if appropriate), then a specific setting in that section. I've used this sort of troubleshooting technique to find and fix problems I didn't otherwise know enough about to fix, a number of times. It requires a LOT of patience, some intelligent guessing in figuring out what parts of the config are most critical and what parts are least likely to be involved, a bit of luck, and often a LOT of time, but it's surprisingly effective. One more possibility, but it gets rather more complex. Assuming you're on some form of Linux (other OSs should have similar utilities), try (from the terminal window) strace -eopen pan (assuming you have strace installed, if not, you may have to install it). That'll spit out quite a bit of output as pan opens various files to read from them. Most of the early ones will be libraries, fonts, icons, and system config files. If you know how to use grep you can filter most of that out as we're not interested in it for what we're doing. You'll probably be amazed at how many pan opens or tries to open. But then it'll start opening its data files, and this is where it gets interesting. Verify that it is indeed using the ~/.pan2/ dir (perhaps your distro changed the defaults and it's using something else?), and note any file open errors it gets. You can save the output by redirecting it to a file using > like so: strace -eopen pan > ~/pan.filedump If you have a web page or other location you can post files to and link them, you can then post the link here and we can take a look and see if anything looks strange to us. (Of course, be sensitive to the fact that the filenames may include the newsgroups you subscribe to. Some people wouldn't mind that being public info. Others would mind as that can be rather personal info and may be embarrassing. It's your choice of course whether you post it, and entirely understandable if you don't wish to.) Other than that... unfortunately it could well be one of those things I could fix if I were there, looking at the actual machine where I can see things I'd miss remotely and try stuff without the latency of a mail exchange, but that's incredibly difficult to fix remotely. If you mention the distribution/OS, filesystem, etc, perhaps someone else with more specific knowledge in that area can be of help. -- 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 Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
