[BUG]: Fetching messages; marking read messages as unread

[tonebacas]

Brief description of the issue

When fetching new messages for the following feed, messages which were marked as read are now marked as unread.

feed: https://www.gamingonlinux.com/article_rss.php

How to reproduce the bug?

1. Launch RSS Guard.
2. Fetch messages for feed (https://www.gamingonlinux.com/article_rss.php)
3. Mark messages as read.
4. Fetch messages for same feed again.

What was the expected result?

On step 4, I expected any new message to show as unread on the feed.

What actually happened?

On step 4, messages which were previously marked as read are now marked as unread, along with any actual new message.

Other information

I've experimented with database options use DB transactions and use in-memory database, restarting the application when needed. The result is the same regardless.

Operating system and version

• OS: Windows 10
• RSS Guard version: 4.0.1

[martinrotter]

Will check. These kinds of errors are usually caused by problematic feed but I will check tomorrow and report back.

[tonebacas]

I checked the contents from the feed in two distinct instants, not 10 seconds apart, and there's a difference between an article's old and new 'fetch'. Some HTML content has unique ids that seem to be generated on the fly. This happens for a lot of articles, and presumably this could be the issue if you're determining the uniqueness of an article based on its contents.

[martinrotter]

@tonebacas You did investigation for me.

Indeed this is the culprit and source of problem. I can add switchable global option which would ingore changes made to "content" of article (not to date of postage, author, etc.) so that these "bad" messages would not be treated as "updated". What you think.

Other option is to write clever article filter in RSS Guard which will use some regexp magic and will replace those problematic parts of message.

You pick.

EDIT: There is very sophisticated algorithm which decides if the article is "updated" as there are many situations where the decision must be made correctly.

Here is documented code of the algorithm: https://github.com/martinrotter/rssguard/blob/master/src/librssguard/database/databasequeries.cpp#L1266

Basically for your situation article is considered updated if its date of publish OR contents are changed. Perhaps it would make sense to add option to take contents comparing out of the algorithm.

[tonebacas]

Curiously enough, this wasn't happening back in 3.9.2. I would assume now you're using a different strategy to determine if a message is considered new.

As much as I understand the logic behind comparing messages down to their content, I would say this could become problematic in the future if done to such extent. I can't gauge how many feeds use automatic HTML code generation like the one I provided, but webdev is unpredictable like that, and I would not be surprised if new variations of this problem arise.

Performing the comparison in terms of the other attributes besides content should suffice.

[martinrotter]

@tonebacas I agree. I will therefore add new global option "Do not take changes of article contents into account when updating the article" and will enable it by default - current behavior will not be affected and these problems will be solved.

[martinrotter]

@tonebacas OK, introduced the option in "Feeds/messages" settings dialog.

ceb88b3

By default the option is ON - ignore contents. It should provide more stable results and not overwrite message needlessly.