Where does Akregator store read/unread status of feed items?

Help
1

I’ve had a couple of incidents where Akregator crashed. On starting up again it remembered all my feeds, but not the status of any items within those feeds - i.e. it refetched everything and showed every item as unread.

To recover from this more easily in future, I’d like to be able to restore the relevant data from backups. However, I can’t find where the state of feed items is stored.

I expected this kind of data to be in ~/.local/share/akgregator or ~/.local/state/akregator (as per this previous topic).

Looking in those directories, I find:

  • ~/.local/share/akgregator/data/feeds.opml - stores the feeds I subscribe to, and their hierarchy, but no information on individual items
  • ~/.local/share/akgregator/Archive - has a bunch of files, one for each feed, but they’re all zero-length so can’t carry any state information.
  • ~/.local/state/akregatorstaterc - has some information about the window size, and a “State” string which seems to be base-64 encoded data. However, if I delete this file, Akregator still remembers which items are read/unread, so it can’t be storing that information.

There’s also a directory ~/.cache/akregator, but the only thing that contains is an empty subdirectory.

Where should I be looking for this state data?

2

@pg-tips:

First, welcome to the KDE Discuss Forums!

Almost but, not quite –

  • The directory “Archive” is where Akregator maintains local copies but, only if the application’s settings are correctly set.

<Archive>
If, the button “Disable archiving” has been selected then, all the downloaded articles are discarded when you quit Akregator.

I took a look in the Akonadi database to check – Akregator has no entries in the Akonadi database.

3

Thank you :slight_smile: Long term Windows user, I switched to Fedora KDE a month ago and I’m really enjoying KDE.

I checked, and I don’t have the button selected. (I chose “Delete articles older than 60 days”).

What I think is happening reproducibly is:

  • If I close Akregator, then open it again within the same session, then the status of each article is correctly retained. (However, the files in ~/.local/share/akregator/Archive are not being used to do that - they remain at 0 bytes length and their mtime corresponds to back when I first added the feed.)
  • If I end my session, log out and in again, and start up Akregator, I get a message “Akregator did not close correctly. Would you like to restore the previous session?”. I click “Restore” and I get the problem I described - every article appears as unread.

My guess is that somehow:

  • Akregator fails to persist state to those files in Archive. (I agree that’s where the state should be persisted, based on Akregator troubleshooting I’ve seen on other forums). The key is going to be to understand why that’s happening.
  • When the app runs, it stores state in memory. Closing the front end does not kill some back-end process that does this, so when I close and open the app within a session, I don’t experience the problem.

Agreed. I also looked at the Akonadi DB and didn’t see anything Akregator-related.

4

@pg-tips:

Hmm – maybe simply wait a while until the archiving kicks in –

..akregator/Archive> LANG=C ls -gG --human-readable
total 56M
-rw-r--r-- 1 4.4K Mar 26 15:49 archiveindex.mk4
-rw-r--r-- 1  29K Mar 25 19:18 feedlistbackup.mk4
-rw-r--r-- 1  41K Mar 15  2024 file____home_Users_xxx_Heruntergeladen_1IbMxzN9.atom.mk4
-rw-r--r-- 1 343K Jan 29  2024 file____home_Users_xxx_Heruntergeladen_meldungen.xml.mk4
-rw-r--r-- 1 289K Dec 16 12:23 file____home_Users_xxx_Heruntergeladen_qBYTNFw5.rss.mk4
-rw-r--r-- 1  45K Dec 10 19:02 file____home_Users_xxx_Heruntergeladen_vbpO58us.atom.mk4
-rw-r--r-- 1  98K Jan 29  2024 http___rss.dw.com_xml_rss-de-all.mk4
-rw-r--r-- 1 2.1M Mar 26 15:07 http___rss.dw.com_xml_rss-de-news.mk4
-rw-r--r-- 1 127K Mar 18 10:08 https___blogs.kde.org_authors_release-team_index.xml.mk4
-rw-r--r-- 1 648K Sep 25 18:43 https___dot.kde.org_rss.xml.mk4
-rw-r--r-- 1 2.4M Mar 26 15:37 https___news.opensuse.org_feed_.mk4
-rw-r--r-- 1 892K May 15  2024 https___petapixel.com_feed.mk4
-rw-r--r-- 1 782K Dec  2  2020 https___planet.kde-espana.org_atom.xml.mk4
-rw-r--r-- 1 6.8M Mar 26 15:09 https___planet.opensuse.org_global_rss20.xml.mk4
-rw-r--r-- 1  25M Mar 26 15:49 https___planetkde.org_rss20.xml.mk4
-rw-r--r-- 1 188K Dec  2  2020 https___store.kde.org_content.rdf.mk4
-rw-r--r-- 1  81K Mar 12 11:28 https___willuhn.de_blog_index.php?_feeds_index.rss2.mk4
-rw-r--r-- 1 1.6M Mar 26 15:07 https___www.destatis.de_Aktuelles.xml.mk4
-rw-r--r-- 1    0 Jan 29  2024 https___www.linux.com.mk4
-rw-r--r-- 1 7.5M Mar 26 15:09 https___www.linux.com_feed_.mk4
-rw-r--r-- 1 192K Apr 30  2024 https___www.phoronix.com_rss.php.mk4
-rw-r--r-- 1 5.4M Mar 20 17:05 https___www.raspberrypi.org_feed_.mk4
-rw-r--r-- 1 656K Mar 26 15:06 https___www.schneier.com_feed_atom_.mk4
-rw-r--r-- 1 1.4M Mar 25 09:21 https___www.w3.org_blog_news_feed.mk4
..akregator/Archive>
5

I made a bit of progress.

I mentioned before that “closing the front end does not kill some back-end process”. What I hadn’t realised is that clicking the window close button (which I was doing before) doesn’t do the same thing as File >> Quit (which I tried today). Just closing the window seems to leave the app running without a GUI, and if you then end your session, I guess that’s how you get to “Akregator did not close correctly” in the next session.

When I did File >> Quit, I did see the .mk4 archive files get written. So that’s some progress.

Something is still a bit weird though: I had set “Delete articles older than 60 days”. However, the application does show me articles more than 60 days old, but it gives them all a date of 1 Jan 1970 (i.e. zero Posix timestamp).

I’ll keep searching around and experimenting.

6

Further discovery: this is because I went the wrong way about removing the Akregator tray icon. I should have achieved this by disabling it in Akregator settings, but instead I hid the entry in the tray settings.

When I disable it the proper way, closing the window does properly exit the application.

I still need to look at the issue of old article hanging around and showing a 1970 date.