Akregator article counts are often wrong

Bug #112392 reported by Brian Beck on 2007-05-04
10
Affects Status Importance Assigned to Milestone
KDE PIM
Unknown
Medium
kdepim (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: akregator

It seems that very often the count of unread articles in Akregator is wrong. I will attach screenshots to show exactly what I mean. If there's something further I can provide just ask, I know this is a pretty vague bug report.

Version: 3.5.6-0ubuntu6

Version: (using KDE KDE 3.5.5)
Installed from: Ubuntu Packages
OS: Linux

Akregator displays a wrong count of unread messages for a group of feeds (please see the attached screenshot). The number is too low and the error carries over to the overall result that is displayed at the top level and in the systray. As a consquence, sometimes the icon doesn't notify me of unread messages even if there are some.

I've seen #107144 and #135170, but
1.) they're both marked as fixed whereas my screenshot is from KDE 3.5.6
2.) they both mention negative numbers, while I don't see any on my system

So either the bug is still around, or mine is a different issue.

I'm on an up-to-date Kubuntu system (edgy) with the latest KDE packages from kubuntu.org.

> akregator -v
Qt: 3.3.6
KDE: 3.5.6
Akregator: 1.2.6

I'm not sure about how to reproduce the bug but what struck me was that the miscalculation happens with a family of feeds from dradio.de. I noticed that the entries in these feeds overlap sometimes so that items are not unique across feeds (one item may appear in more than one feed). Maybe akregator is confused by this situation. But I'm just guessing ...

Expected behavior: Numbers that add up. :)

Created attachment 19469
Screenie that displays more unread articles than the counter says.

Created attachment 19487
another example of bad summary numbers throughout akgregator

same here but it goes even further: un empty folders akregator shows bogus
number of unread feeds, and summary counters are all "out-of-sync":
Tray icon, summary for all feeds and per-folder numbering. Including summary
page that says in one pane: "no matches" and another pane says :"45.... unread
articles.

I also have noticed that in summaries sometimes it says: "1" for unread article
when using the filter on the right I can't find that article.

Brian Beck (brian-beck) wrote :
Brian Beck (brian-beck) wrote :
Richard Johnson (nixternal) wrote :

Confirming due to images and upstream report. Attaching upstream report to the affects.

Changed in kdepim:
importance: Undecided → Low
status: Unconfirmed → Confirmed
Changed in kdepim:
status: Unknown → Confirmed

Created attachment 21938
Wrong calculation of unread articles

Same here - as you can see from screenshot, there is two unread articles but
count is zero. Of my feeds it happens only in case of Google News and FAZ
(Frankfurter Allgemeine Zeitung) feeds, all other have always been correct.
Mostly it does happen after one or two days non-interrupt work (but it happens
always, and for correcting Akregator has to be restarted)

*** Bug 130752 has been marked as a duplicate of this bug. ***

*** Bug 134496 has been marked as a duplicate of this bug. ***

Richard Johnson (nixternal) wrote :

Requested status update from upstream.

Any status on this issue?

As in 3.5.9, I've seen it over and over again...

I'm also seeing it 3.5.9. The total sum at the top is off by 1 sometimes.

I can confirm that for 3.5.9. But after restarting the program (kontact in my case), all is fine.

You are laucky... I see bad count over and over again (KDE 3.5.9) and restarting helps at best only for a day or so, then the count will be wrong again.

The upstream report says this is still observed in KDE3.5.9. Is it an issue in KDE4, I don't observe it here?

Changed in kdepim:
status: Confirmed → Incomplete
Rocco Stanzione (trappist) wrote :

I can reproduce it in KDE4. I don't yet know exactly *how* to reproduce it, but closing and restarting Kontact seems to reset everything and temporarily fix it. Currently I have a total of 43 unread articles in 3 feeds. The counts for the individual feeds and the folders they're in are correct, but the top-level "All Feeds" unread count is -72. That number adjusts appropriately when new articles appear or get marked as read. I'll update this ticket when I have more info on under what circumstances the count goes wrong.

Changed in kdepim:
status: Incomplete → Confirmed
Rocco Stanzione (trappist) wrote :

After a little more observation, it looks like the top-level total is an accurate sum of the unread counts of all the subfolders, but one of my subfolders has -44 unreads, because one of the feeds in it has -44 unreads. Maybe this makes a difference: this feed is to "mark articles as read when they arrive". I poked around in feed.cpp and there's only one place recalcUnreadCount() is called - maybe it needs another, or maybe something is failing before it's getting called. createMarkAsReadJob() doesn't call it, and maybe it should, I don't know, I don't do a lot of C++.

Rocco,

Thanks for the feedback. It might help if you could leave a comment on the upstream bug saying that you can reproduce it in KDE4 and basically just reiterate what you said here. I think development on akregator has pretty much stopped for kde3 for anything less than a crash. If they know the bug is still present in KDE4 it might get some attention.

Rich

Created attachment 30782
Negative numbers (screenshot)

Well, it works perfectly for me, except for Google News (whatever format, RSS or Atom): http://news.google.it/nwshp?hl=it&tab=wn&output=atom

If I select the "Mark articles as read when they arrive", I get negative numbers! Look at the attached screenshot for an example.

However, numbers are reset (to 0) when akregator is restarted.

Since KDE 4.2 I've no more experienced wrong count.

I can also confirm same; since upgrading to KDE-4.2, the counts are now *accurate*.

Hurray!!!

It still happens sometimes but much more rarely, maybe once in a week (I've Akregator open 24/7)

Harald Sitter (apachelogger) wrote :

Closing in favor of KDE report. Please refer there for updates. Thanks.

Changed in kdepim (Ubuntu):
status: Confirmed → Invalid
Changed in kdepim:
importance: Unknown → Medium

*** Bug 280850 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> It still happens sometimes but much more rarely, maybe once in a week (I've
> Akregator open 24/7)

You wrote that almost 4 years ago, have you seen any improvement?
I have never seen this bug. I also use akregator 24/7

Changed in kdepim:
status: Confirmed → Unknown

I can confirm that this bug is still happening to me. A restart does seem to correct it. Not sure if it will go back to the incorrect count as others suggest or not. I can report back if that would be helpful.

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.

Changed in kdepim:
status: Unknown → Incomplete

Created attachment 101425
attachment-26790-0.html

On Samstag, 24. September 2016 19:39:17 CEST you wrote:
> [akregator] [Bug 140824] Akregator Miscalculates Unread Articles

Akregator Version 5.2.3
KDE Frameworks 5.25.0
Qt 5.6.1
Das xcb Fenstersystem

In dieser Konfiguration zählt bei mir zu Hause der Akregator seit Jahren falsch;
ich habe vor langer Zeit beschlossen, das nicht einmal zu ignorieren!
Ein Beispiel von jetzt eben:
   ungelesen gesamt
   320 463 vor
   326 475 nach “fetch all feeds”.
  ( +3 +12 )

Thank you for your feedback. I set the bug to confirmed again.

Changed in kdepim:
status: Incomplete → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.