Only 30 Posts load at a time

[ddowdle]

IIS 7.5
MYSQl 5.5.3
Tiny Tiny RSS v15.7 (583f163)

When scrolling through unread posts in "All articles" or "Fresh Articles", it seems to be limited to 30 posts most of the time. After the 30th post it has a message that says new posts found reload to view - the console says: we seem to be at an end and an error shows up in the log:

E_WARNING (2) classes\db\mysqli.php:45 mysqli_num_rows() expects parameter 1 to be mysqli_result, integer given

Anyone have any ideas?

[nameless]

sounds like your configuration is fucked up. most likely your mysql.
are there anymore logs for you mysql?
i don't know much about IIS with mysql though.
get a cheap linux based vps and start using postgresql.

[ddowdle]

there are no entries in mySQL error log. It seems unlikely to be mySQL though - i am running other code against data stored in this mysql instance without a problem and this only started occurring with the most recent update of ttrss.
I notice lots of calls in the code are like:

Code: Select all

if (!is_numeric($result) && $this->dbh->num_rows($result) > 0) {

and the error is occurring here:

Code: Select all

    function num_rows($result) {
      return mysqli_num_rows($result);
   }

it seems there might be a missing checking for result to be an integer somewhere. I am just not sure how to find the "where" that might be.

[ddowdle]

Another bizarre data point: If i use the keyboard to navigate instead of the mouse, it works without issue.

[TJ500]

I've had the same problem lately. I'm hosting ttrss (from git) on my own LAN with a Ubuntu 14.04 server with mysql. I've noticed that it only happens when going through articles in All or Fresh Articles or a category of feeds. If I view a single feed, there's no problem.

On the server, the mysql logs are all empty and the Apache error logs don't have anything the line up with when I have this problem.

When I get the "New articles found, reload feed to continue." message, in the browser console it says: "xx cur: yyyyyyy next: false index.php:419" where xx is number of times I've pressed down for next article. I think yyyyyy is the active article id if I'm reading line 419 of index.php right.

The opposite of the previous post is what I've seen. Scrolling down with the mouse wheel, I never have the problem. Watching the browser console, I never see index.php:419 either. If I have been moving through the articles with the keyboard and get to the last one of the thirty but it's too long to fit on the screen; if I scroll down with the mouse wheel, the next articles will then load.

It happens in the android app as well. I'll get 30 articles and then have to reload the feed. What's weird is that if I go through the headlines fast enough, I'll see the "Loading, please wait" message and after a second the next 30 headlines load. If I scroll through them more slowly, reading each headline, I'll get the "New articles found, reload feed to continue." message.

Sorry if my attempt at trying to figure it out doesn't make any sense. I realize it's probably not very reproducible. If there's somewhere else to look for clues, any help would be appreciated.

ttrss is an awesome piece of software that I use every day. Thanks fox!

[fox]

well if there *are* new articles then that's working as intended, paginating correctly is kinda hard when starting index is moving around.

>I've noticed that it only happens when going through articles in All or Fresh Articles or a category of feeds.

because any feed updating in the background would cause this message to appear, as opposed to some specific category or feed where its the subset of all feeds

>If I scroll through them more slowly, reading each headline, I'll get the "New articles found, reload feed to continue." message.

that's easily explained though: when you read slowly the possibility of some feed updating in the background and shifting current view is higher

e: now if this message is appearing and you're absolutely sure there's no new stuff after reloading, then its some kinda bug

[TJ500]

I sort by oldest first and I'm about two weeks behind right now with around 4K of unread articles, so I'm not at a point where I'd be seeing new articles just put into the database. I'll turn off update_daemon2 and see if I can reproduce it though.

edit: it still happens with the update daemon not running.

[fox]

if you are sorting by oldest first first_id shouldn't really change at all so i'm not sure why would you be receiving this message

[linoth]

I wish I could post a more useful reply, but I also sort by oldest first and can confirm that at least sometimes, I get the "New articles found" when I'm nowhere near current posts and I know for certain that the feed updated.

I'm not confident enough to declare that it goes either way, but I suspect it may be intermittent. I'll try to keep an eye on counts to see if I get a case where I am certain there was an update and no notice. For what it's worth, I'm also viewing the feed via a category, instead of individually.

[fox]

i think this check should be disabled altogether when sorting by oldest first not sure why it isn't tbh

[sleeper_service]

I was going to say, I read oldest first, and it's very often pausing and telling me there's new stuff, and to reload.

the check doesn't make any sense to me either in oldest first mode.

[fox]

well the check is no more

[TJ500]

Thanks, this fixed it for me. It doesn't tell me there's new articles and to reload, but since I have crappy internet service for my home server, when I'm away from home and using the app, swiping down through the headlines and I get down to the end of what has been loaded, I have to wait a few seconds for it to load the next how ever many headlines. It seems like it waits until I'm 2 or 3 articles from the end of what's been fetched to start fetching the next bunch. Would it be possible to start fetching the next articles sooner, like when it's 5 or 10 articles from the end?

I realize this is probably the fault of my slow connection, so yeah. Consider this some feedback from a guy with crappy internet I guess.