Describe the problem you’re having:
I remember this was discussed earlier, but I can not remember (nor find) if Fox could not reproduce or there was no way to fix it. I apologize if this was investigated already.
The issue is for some feeds with short articles, I can scroll with hundreds of articles with “Ctrl+Down”.
For feeds with longer articles (that exceed the width of the screen) I can not go further than 30+30 (more on this later) without reloading the feed.
…
If possible include steps to reproduce the problem:
Subscribe to The Register and Quartz and wait untill there are about 100 unread articles for each.
In combined expanded mode, select the first feed and scroll the articles with “Ctrl+Down”. I am able to reach the last one.
If you select the second one, once you scrolled the first 30 articles, typing “Ctrl+Down” won’t do anything. If I go through the article with just the “Down” key, once I reach the end of it, TT-RSS loads the following 30 articles, which I can scroll again with “Ctrl+Down”. If the unread articles were more than 60, the only way to go through the remaining, is to “f+r” the feed.
…
tt-rss version (including git commit id): Tiny Tiny RSS v19.2 (5829ee9)
…
Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
Shared hosting, PHP 7.1.30, 10.1.40-MariaDB-cll-lve
…
Please provide any additional information below:
Tried with Google Chrome and Microsoft Edge
…
those kind of issues are an absolute hell to debug. what happens if you scroll down with mouse wheel in this situation? anything interesting in the f12 console?
in my personal opinion having to - maybe - reload the feed from time to time is not really that big a deal to bother with some kind of overhaul (or, even worse, more hacks piled on) of the current lazy loading system. maybe i’m missing something obvious here of course.
e: can you PM me your database dump? i’ll take a look.
Hi Fox,
Thanks for your reply. I sent you a Pm for the dump.
Right now I do not have access to a computer, but I will test this evening. If I remember correctly, scrolling with the mouse does not behave differently from using the down key.
I am not complaining about refreshing the feed. I was just reporting a different behavior depending on the length of the articles.
The strange thing is that automatic refresh get stuck at exactly 30 articles and is “unstuck” only once after exactly 30 more articles.
I have ran into Ctl-Down issues, but they were fixed by scrolling the mouse. At home using my kodi box w/ wireless keyboard w/ built-in mousepad; it is a bit of a pain to do a 2-finger swipe to scroll. But not something that I hit so often that either a scroll for “f-r” refresh didn’t handle well enough.
Seems like scrolling down with the mouse wheel does the trick, and unlocks the 3rd batch of unread articles. I would perform more tests, but I have to wait that feeds with longer articles publish something, as I am not good at mysql and I do not know how to “unread” articles directly in the database (if that’s even possible).
as I wrote in my previous reply, I am not complaining about having to reload the feed. I wanted just to report a strange behavior. The strangest thing is that if the articles exceed the width of the monitor, TT-RSS is unable to display the following. If there are a bunch of long articles, but around position #30 there are short ones, TT-RSS “fetches” the following, sometimes displaying the warning “loading, please wait”, sometimes without that warning, or maybe for such a short time I can not even notice.
I hope it is helpful somehow.
f+r surely solves the issue. Thanks for pointing out, as Fox did, that even the mouse wheel achieve the same result.
update ttrss_user_entries set unread = true where feed_id = X
you can easily figure out feed id from the url (#f=number) when that particular feed is open.
re: other stuff
i don’t really remember how lazy load is triggered but it’s either race condition between marking as read and requesting lazy load or lazy load not being triggered in the first place because of some oversight.
you can try checking in f12 console to see if anything is mentioned about loading more headlines or viewfeed when you get to the end of the loaded headline block and nothing happens.
what kind of article view mode are you using? if its adaptive or unread try switching to “all articles” to see if that makes it work better.
this way next batch offset calculation won’t depend on the unread article amount which may easily desync between frontend and backend (because it’s marking stuff as read as you go, asynchronously) which removes a major race condition out of the equation entirely.
i’ve made some changes related to lazy load (described in the commit message, so i’m not going to repeat them here). it would be interesting to hear your feedback related to them.
I git updated and have been reading hundreds of articles without the need to reload or scroll down to refresh.
It works beautifully for me, without any side effect so far.
Thank you very much for investigating and the time you used to correct it.
FWIW, I was and still am using “unread”. After the update, as I wrote above, scrolling does not get stuck anymore. I guess now there is no need to switch to “all articles”.
I hit it pretty hard in my test environment, holding N down for long periods, and I managed just once to freeze it on “Click to open next unread feed.”; but that was after fetching pages upon pages of new articles. Otherwise I have scrolled through hundreds of articles w/o stopping.
i’m glad to hear it. as soon as i’ve finally noticed this was about long articles (for some reason, initially i thought this was about short ones ), i had a hunch and it seems to have worked out.
if lazy load works for you, obviously you don’t need to change anything.
that said, you still might run into issues from time to time because the underlying fundamental race condition between frontend changing unread status of articles and backend selecting batches based on this state has not gone anywhere, however bugfix related to lazy load being broken on long articles specifically is not related to that race condition, it was a completely separate issue.
I don’t know if it’s related, but I noticed that in a few cases when I was scrolling really fast, TT-Rss sort of froze few seconds, but the next article was loaded nonetheless.I think that in normal working conditions, it should not be noticeable.
Thank you. It was long overdue.
I hope Paypal will let you have some of it…
when you scroll down tt-rss renders articles as they appear in the viewport, this might become cpu-intensive if you do it fast enough (you might notice circular progress bars in place of not yet rendered article content if you go fast enough).
chrome has an excellent profiler (F12 → performance tab), if you manage to reproduce this slowdown consistently and record it, i could take a look at the data, although i’m not sure if there’s anything left to improve there).
(if that’s even possible).
), i had a hunch and it seems to have worked out.