Articles marked as read are reset

[AndyM48]

After upgrade to v5 I find that some old articles that I have previously marked as read are changed back to unread, if that makes sense?

Looking at the database I cannot find any changes in the fields for those articles, except that the read flag changes to false (0).

This applies most frequently to two feeds - BBC (https://feeds.bbci.co.uk/news/rss.xml?edition=uk) and Guardian (https://www.theguardian.com/uk-news/rss). The BBC is notorious for editing their articles and adding a # number to it's guid, which produces duplicate articles in the article list. This does not seem to be the cause of the problem since the articles where the read flag has changed do not appear to be duplicated.

I have a filter which removes these guid additions, (and also keeps only one image). I have removed this filter to ensure that it does not cause this problem.

I have limited the articles shown to: Relative time 2 day(s) and 0 hour(s), keep 200 newest article(s), and in the feeds keep 40 newest article(s).

Before I look into this any further, have you changed any tests for duplicate or read/unread items in v5 which might have affected this?

PS. v5 has some nice improvements, Thank you for your hard work.

[martinrotter]

Take a look at these two settings:

RSS Guard only marks existing article in database as unread if its new version if fetched - what "new version" means depends on many variables. There have not been any substantial changes for this in v5 release I believe.

If the thing happens very frequently, I could test with the feed myself.

[AndyM48]

My settings are identical on that page.

This did not happen with v4.

It happens with pretty much every update on the BBC feed.

Thanks for the reply

[martinrotter]

OK so I checked the BBC feed. You are right that they update article very often. They for example change the title, contents or publishing date. I observed that.

But if you have the setting the same as me, then these articles are updated in rssguard DB, that's fine, but they should not be really marked as unread. The source code in that part is relatively simple. I do not really see a bug, yet.

[AndyM48]

Interesting.

Can you check for a coupleof days, if it is not too much trouble?

All of these articles have been marked as read before, and are now showing as unread:

I am considering starting from a fresh install/database, but I would prefer to find the problem. What do you think?

[AndyM48]

I may have found a clue. In the settings for each Feed affected I have set a limit of 40 article:

In the BBC Article list there are 40 articles listed correctly, followed by 10 older articles which have been read, but which are erroneously shown as unread, In the Guardian feed there is a similar result viz. 40 listed correctly and 7 older articles erroneously shown as unread.

Any idea why this may have happened?

[blackwaterpark22]

Definitely wait for @martinrotter response because I might be talking nonsense here, but I believe I had this happen to me before

I believe what's happening is let's say you read Article 1, with the 40 articles limit that same article will eventually be purged instead of "deleted" from the database. For example if you delete the articles to the recycle bin and empty it, it's still technically there until you clean your database with the Remove articles from the recycle bin option ticked or if you used the Purge feed option on the feed itself, so if you try to fetch that same feed again after emptying it from the bin, the articles won't be fetched again because technically it still exists in the database

What the article limit does is purge those articles from the db automatically which is a good thing because it helps with optimization, but because Article 1 does not exist in the db anymore, once Article 1 - Update 1 or Update 2 appears in the feed, it will get fetched as if it the original never existed because it cannot do the check to see if "Article 1" already exists (Again, might be completely wrong here)

Maybe try to check the "Move to the recycle bin without purging them" option to see if that might be it until Martin can give you a definitive answer

[AndyM48]

I think I have completely misunderstood the way that the database operates. I had assumed that the setting keep 40 newest article(s) in the feed would actually show the latest 40 articles, and that keep 200 newest article(s) in the Feed Fetching settings would keep the latest 200 articles in the database. I have no idea why I should have made that assumption, that is not what the settings say! I am very old, so you need to make some allowances.

In mitigation I thought that the fields is_deleted and is_pdeleted were used for this purpose. I was wrong!

I will remove the keep 40 newest article(s) setting and rely on the limit the articles shown to: Relative time 2 day(s) and 0 hour(s) to reduce the number of articles unread in each feed.

[martinrotter]

Well, yes, I completely get your confusion.

What keep 40 newest article(s) does is exactly that. It goes into database and makes sure that only 40 newest articles remains in the database. Everything else is PURGED from the database entirely - the goal here is to keep DB file fit and small.

If you set low enough value here, than it can happen that some articles will be purged from DB and later again fetched from the feed, particularly if the feed source updates article date-times and shuffles articles that way.

I recommend setting the value to higher number - like 200 articles - which is perfectly reasonable number. The setting is meant for users which have hundreds of thousands of articles (yes there are those users) and want to keep their DB file and relativaly normal size.

As for limit the articles shown to: Relative time 2 day(s) and 0 hour(s) - same logic applies. The limit needs to be as far in the past as needed because some "nasty" feeds might update and shuffle their article date-times and previously purged articles (which were too old) might re-appear because feed changed their date-time to a newer one, etc.

And yes Move to the recycle bin without purging them will be of some help here as the above situation could be greatly eliminated by it.

[AndyM48]

Understood.

I am sorry to have wasted your time. Thank you for your patience.

[AndyM48]

Just one small point:

limit the articles shown to: Relative time 2 day(s) and 0 hour(s)

is actually Avoid adding articles before this time/date into the database - Relative time 2 day(s) and 0 hour(s). so surely this means that Fetch will not add older articles to the database rather than that any existing database articles will be purged?

Your point about feeds changing article dates is well made.

[martinrotter]

That is actually true. That option does not work retrospectively. It simply drops incoming article older than the limit.

You got it exactly right. You can look at these functions which do the job and let GPT write your human readable descriptions of them:

// limiting
https://github.com/martinrotter/rssguard/blob/master/src/librssguard/core/feeddownloader.cpp#L540

// purging
https://github.com/martinrotter/rssguard/blob/master/src/librssguard/database/databasequeries.cpp#L476