My setup is hidding the left tree panel (pressing c s), and keeping the headline area on top and the article content at the bottom, filtered by unread only.
I press j or n to jump to the next article, but sometimes, even with a lot of unread ones left, the j or n just stops working as if there is no unread articles left. I have to press r or F5 to refresh in order to continue reading.
This seems doesn’t happen all the time but has happened to me a few times in the past few days. Is it just me or everyone else? Is it possible to fix?
there’s no information here to go on. post logs, f12 console, screenshots, etc.
as a general advice, when posting about a problem, try to think whether someone not intimately familiar with you and your setup will be able to replicate it from the information you’ve provided.
Thanks for your advice, fox. I thought this was a common problem but maybe I was wrong.
I am not very familiar with web developing. I will do more research and give more details about this issue later.
Here is a screenshot. As you can see, there are still 42 unread but I cannot press j or n to go next.
I am not sure about how to post logs or using f12 console… Sorry.
The last phrase says: “New articles found reload feed to continue”
I know I can click it , or press r, or F5 to reload the feed, but it should reload/scroll automatically, shouldn’t it? In this case, the 42 unread ones are not brand new ones, they had been there since I started reading.
does it tell you it’s going to reload automatically? then why did you assume it would?
you don’t understand how or why this works. i’m not going to explain it again so i refer you to the search function on this forum.
tldr: this is working as intended. in the future please don’t post threads here based on your assumptions or intuition or whatever other irrelevant bullshit that wastes everyones time. thanks.
fox, sorry for wasting your time.
I didn’t post it based on my pure assumption, but based on my experience of the previous version, 19.8. I was able to press n until the very last unread item.
If the new version is supposed to work like this as intended, then I guess I have to live with it.
BTW, I did search on the forum, but didn’t find anything similar…
that’s not true. this particular behavior has been implemented several years ago:
commit f5a0fb8b64c57e98fcf73369cb4dbb1b31620fd7
Author: Andrew Dolgov <[email protected]>
Date: Sun Jul 12 01:29:36 2015 +0300
queryFeedHeadlines: move to array-based arguments, optionally check if first element changed when paginating
you just got lucky with new articles being added or didn’t notice it. i remember posting about the reason behind this but since i can’t find that post either (duh!) i guess there’s no harm in repeating it.
tt-rss does pagination in terms of SQL LIMIT/OFFSET. when you scroll down, it calculates how many articles are currently loaded and requests a bunch more starting from X.
this approach has several problems but arguably the most obvious one was what happens when new articles have been added to current view perspective. frontend keeps counting articles showed when X was the first one, but backend counts from Y, so some articles get silently skipped.
forcing pagination to stop in this situation (i.e. making user reload the feed) was the least painful (i.e. easiest to implement) solution to this.
a proper way to solve this (and several other minor issues related to race conditions) would be reworking pagination entirely somehow but i have no idea how to do that and don’t really want to bother anyway since current approach works, most of the time.
I looked it up earlier because I was going to reference it but figured this thread had run its course. Seeing as I was wrong, the post from the old forum is here:
It gets crazy complicated because TT-RSS has several view modes and sort orders, both settings independent of one another. You’d have so much logic to calculate just so someone could keep scrolling.
Just a thought: A potential change that could be made would be when the “next” keyboard shortcut is clicked, if there is not another article trigger a .click() event on that “Load More” link (if it exists).
Thanks for taking your time to explain, fox.
Since this is a hard-to-fix problem, I was wondering if it is possible to increase the page size from the default 30 to something like 300 as a walk around. I checked the settings and I cannot find it.
this is a separate action because it loses context irrevokably, if you press n by mistake and feed reloads you won’t be able to easily go back to where you were.
i think 30 is hardcoded in a bunch of places but it’s probably not that hard to add. then again,
it’s going to be one more per-user option to clutter the prefs UI
it’s going to make initial load slower, a lot slower if the page is huge and server is slow
idk if pressing f r from time to time is such a big deal to warrant adding it
