Bug 185507 - state of feeds (read/unread) not stored when restarting system
Summary: state of feeds (read/unread) not stored when restarting system
Alias: None
Product: akregator
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
: 187080 210408 (view as bug list)
Depends on:
Reported: 2009-02-25 10:41 UTC by paalsteek
Modified: 2017-01-07 21:44 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description paalsteek 2009-02-25 10:41:37 UTC
Version:            (using Devel)
OS:                Linux
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.

Comment 1 Dotan Cohen 2009-04-23 23:17:12 UTC
*** Bug 187080 has been marked as a duplicate of this bug. ***
Comment 2 Thomas Capricelli 2009-04-27 13:24:36 UTC
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 :-(
Comment 3 Frank Osterfeld 2009-04-28 09:11:53 UTC
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.
Comment 4 Thomas Capricelli 2009-04-28 12:35:16 UTC
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 :-(
Comment 5 Dominik Stadler 2009-11-05 00:35:40 UTC
This sounds similar to Bug 210408, Bug 199232 and Bug 196633.
Comment 6 Christophe Marin 2010-02-22 01:32:00 UTC
*** Bug 210408 has been marked as a duplicate of this bug. ***
Comment 7 m.wege 2010-02-22 09:06:41 UTC
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?
Comment 8 Oliver Henshaw 2010-03-06 14:46:09 UTC
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?).
Comment 9 Oliver Henshaw 2010-04-20 17:30:45 UTC
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.
Comment 10 Denis Kurz 2016-09-24 19:40:42 UTC
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.
Comment 11 Denis Kurz 2017-01-07 21:44:12 UTC
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.