GNOME Bugzilla – Bug 349044
Preferences are not saved when edited?
Last modified: 2006-09-18 23:52:05 UTC
Please describe the problem: Preferences do not seem to be saved upon edit. After configuring Pan, setting servers, group list download, collecting news headers, articles and such, a crash causes a loss of config. When Pan reloads it has no subscribed groups (although the articles are stored). It may also have other config missing (not saved before crash). Steps to reproduce: 1. Clean Pan config. 2. Setup pan and do some normal things, cause a crash :) 3. Reload pan and see that the config is missing. Actual results: Expected results: Does this happen every time? Other information:
Oh my english.... Point 2 above should read, "Setup pan and do some normal things. The problem is only visible if you cause a crash". /G
Writing the newsrc files is one of the more unavoidably slow parts of Pan, so I'd prefer to /not/ have to write it out very frequently. Did you file a bug report on the crash?
*** Bug 349188 has been marked as a duplicate of this bug. ***
> Has Pan been crashing on you, Duncan? Not pan, but sometimes xorg, which of course takes pan with it. A bit OT but... I love the translucency effects of composite, but with XAA rendering they are slow and/or take up huge amounts of CPU, and while EXA rendering is FAR faster (very little composite overhead), it's still labeled "unstable" for a reason! KDE's compositing helper kompmgr causes X to leak memory (restarting it returns the resources most of the time, even tho they were on X's tab). I have that controlled due to having 8 gig to work with and reasonably tight ulimit virtual and resident memory limits, but when it runs out of memory it tries to eat 100% CPU. Luckily I have a dual Opteron and it's single-threaded so only affects one, leaving the other free, and I've ran with it doing that for hours when it triggered when I had several job windows open at once and it wasn't convenient to shut down X and restarting kompmgr wasn't working, but it's not an environment one would exactly call "stable", and once in awhile... =8^( OTOH, I'm deliberately running X with these bleeding edge features turned on, knowing the risk, so... Back to pan. If you are worried about the performance, a manual sync trigger would be nice. As I said, I think switching groups is an appropriate time at minimum, and that's what I formerly used as my sync trigger, but a button and/or menu entry that I could assign a hotkey too (thanks! =8^) would come in handy for those several hundred new posts in a group times. However bad it might be for performance, performance /really/ suffers when you have to go back thru re-marking stuff as read!
*** Bug 349731 has been marked as a duplicate of this bug. ***
_How_ slow is the writing of the .newsrc? A related problem is that I lose my settings and read messages when logging out of GNOME. Pan should definately connect to the session manager so it can be given a chance to save its state when the user logs out.
After the discussion in about this bug on pan-users today, I decided to put in some timing tests to see if there was any way I could speed up saving enough that it could be done periodically. To my surprise, the various rounds of speedups over the last couple of months have made this pretty speedy. Right now, the xover files (~/.pan2/groups/groupname) are already saved when you get new headers, and server information (~/.pan2/servers.xml) are saved whenever they're changed. I've added code to save everything else each time you change groups. (prefs, group prefs, newsrc, xov).
Created attachment 72916 [details] [review] 0.112 patch give this a try...
(In reply to comment #7) > Right now, the xover files (~/.pan2/groups/groupname) are already saved > when you get new headers, and server information (~/.pan2/servers.xml) > are saved whenever they're changed. I've added code to save everything > else each time you change groups. (prefs, group prefs, newsrc, xov). That'll be livable, anyway. In old-pan, when going thru a group with tens of thousands of posts, I was used to clicking to a different group and back, every 500 to 2000 posts, just to save place in case of a crash. I still find myself doing it once in awhile, then realizing it's not going to do any good and that I have to quit and restart. At least I'll have the switch-groups save back again, now. The thing I don't quite get is that it can't be /that/ slow, given a quit and restart, which must load and setup pan itself as well as the group once I go back to it, isn't bad any more -- unlike old-pan where I could start pan, then go make myself something to drink/eat while I waited for pan to finish loading, especially if little of pan's data remained in cache. Back then, I got so I'd leave pan running, to avoid restarting. At least that isn't necessary any longer =8^), but it was still a pain to quit and restart just to save state, so I'm glad switching groups will do it again once this gets in. =8^)