All/Unread Results grouped by source - not a bug it seems

[Yetangitu]

A recent update - 14.2.0 most likely - changed the sorting order for results in the All Articles and Unread Articles sections. Before the change these results were sorted chronologically without grouping, after the change they are grouped by source in loosely clustered batches. Like this, somewhat:

Before:

Source1    Blah blah blah    5 minutes ago
Source2    Blah blah blah    6 minutes ago
Source2    Blah blah blah    7 minutes ago
Source1    Blah blah blah    8 minutes ago
Source2    Blah blah blah    9 minutes ago
Source1    Blah blah blah    10 minutes ago
Source2    Blah blah blah    11 minutes ago
Source1    Blah blah blah    12 minutes ago
Source1    Blah blah blah    13 minutes ago
Source2    Blah blah blah    14 minutes ago

After:

Source1    Blah blah blah    5 minutes ago
Source1    Blah blah blah    8 minutes ago
Source1    Blah blah blah    10 minutes ago
Source2    Blah blah blah    6 minutes ago
Source2    Blah blah blah    7 minutes ago
Source2    Blah blah blah    9 minutes ago
Source1    Blah blah blah    12 minutes ago
Source1    Blah blah blah    13 minutes ago
Source2    Blah blah blah    11 minutes ago
Source2    Blah blah blah    14 minutes ago

Results in subcategories are still sorted chronologically. I had a quick look at recent changes but have not yet found the culprit. If this change is intentional I think it should be possible to revert to the original - chronological - behaviour since that makes way more sense than the current rather messy presentation. If it is not, this is a bug.

I'm using PostgreSQL, for the rest my installation is rather standard. There are no 'issues' in the admin settings, everything seems to be the way it is supposed to be.

[SMillerDev]

AFAIK nothing even related to that code changed. Could you get some real examples where the order is incorrect?

[Yetangitu]

I'm starting to suspect the problem is related to the new update interval setting so I'll do some testing with a lower interval, maybe that explains the new behaviour. Here's a screenshot to show what it looks like now, before changing the update interval:

[Yetangitu]

Experimenting with the update interval is made more difficult by #775 - the settings don't stick, adding them manually to the database does not make a difference so I changed the default (in lib/Config/Config.php) to 300. From what I can see after 2 updates this brings back something which resembles the old behaviour. In other words, this is not so much as bug as something which should be mentioned in the documentation, especially for those who are used to the original behaviour.

[Grotax]

Yea it's not a bug an people have found this before, really old actually #51

[Yetangitu]

Hm, that's ancient. I'll see if I can find some time to fix it, it is rather annoying.

[john-2000]

thanks @Yetangitu , @Grotax and @SMillerDev I am experiencing the same sorting / order issue, let me know if I can help testing

[Grotax]

It's not really a bug, the sorting is just not based on the article date. This grouping happens because the feed fetcher starts feed by feed to request the updates and places them in the dB.

Then the reader API will simply fetch them in the order they were added to the dB.

Currently and for a long time nobody wanted to work on this. Might also have some performance implications I guess