Version: (using Devel)
Installed from: Compiled sources
I'm using aKreagator within Kontact an everytime I'm restarting my system, I have to mark several postings as read again.
When I'm quitting kontact manually everything is fine and next time when I'm rebooting alls feeds are marked as read.
So I have to quit Kontact manually everytime there are new postings in one of the newsgroups to prevent them to be marked unread next time starting my system.
I have this problem at least since switching to KDE 4 two months ago.
*** Bug 187080 has been marked as a duplicate of this bug. ***
i can confirm this bug with 4.2.2. I've just restarted (without crash) my kde session, and when akregator is back, it's a real mess with hundred of supposedly unread articles, mixed with actual new items..... Know i need to choose between loosing some information or loosing quite some time to check it all :-(
orzel: Did this happen only once after upgrading to 4.2.2, or does it happen each time you restart Akregator?
We changed the way to detect duplicates for 4.2.2, thus when upgrading to that version, bogus unread items are expected, but that should happen only once.
It has happenned several times. I think it only happens when i quit the session. What i do now is to first exit akregator, and then quit the session. So far it seems to fix the problem.
I'm really really sorry, but i can not remember if it happened before 4.2.2 or only since i've updated :-(
This sounds similar to Bug 210408, Bug 199232 and Bug 196633.
*** Bug 210408 has been marked as a duplicate of this bug. ***
I believe the reason for this problem is to be found in the fact the closing of many tabs goes on very slowly and therefore akregator is killed during shutdown before it is able to save the session. At least the problem with slowly closing tabs occurs in Konqueror to. To reproduce only has to open many tabs (with content) and choose "close other tabs" from the context menu. It appears that Konqueror closes the tabs one by one and that takes very long. It is very slow since kde4. I assume that Akregator does it the same way. When closing Akregator manually I often (depending on the amount of tabs) receive a message telling me that Akregator does not react and if I want to kill it. I assume this killing of Akregator is done during shutdown without asking. So solving this problem would solve the bug. May be also switching to webkit (don't know if webkit does this more efficently). Is this already possible for Akregator?
If I understand session management correctly, session saving is triggered before application shutdown starts.
It looks like the opml feedlist is saved during ksmserver session saving - in KMainWindow::saveProperties() - but the feed db is not updated until sometime during the akregator_part::~Part() in akregator teardown.
But the session manager may timeout and kill akregator before it gets this far (maybe because there are many tabs as suggested above or maybe because part of the app is swapped to disk?).
It does seem that paging in swapped-out memory during application teardown is indeed responsible for the session manager timing out and killing desktop apps.
Since upgrading from 768MB ram to 1.25GB I have not noticed unclean shutdowns of akregator, amarok or firefox. Before the upgrade, around 50-100MB of swap use was normal - now more than 5MB is unusual.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?
If noone confirms this bug for a Framework-based version of akregator (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.