[SOLVED] Connection error when scrolling all articles and fresh section

Hello,just recently stumbled across some odd behaviour while scrolling through the all articles and fresh

section with view all articles set, after the section updates some 5-6 times it comes to a halt and feed locks up

and wont refresh then times out some 3 minutes while giving the yellow triangle with “communication error”, it

locks up at same place always in browser,i thought it might could be some query limit on apache or db or so,

but it only applies to above mention sections, my main feed

category i can scroll endlessly without it ocurring,also this only applies to browser, ttrss android app i cant

reproduce while scrolling past the articles where it locks on browser. While i can just scroll through the

“folder/category” i placed most of my feeds without problems im hesitant reporting this as it doesnt cripple the

functionality to scroll through all feeds,also tried different browser with same results. Im using systemd

daemon to update and also using syslog and

cant find any errors there,also tried httpd error log couldnt find any errors related, Just thought i should report

though also again want to throw thanks for this awsome software its made my day alot better regarding to

news :slight_smile: also apologise in advance if post is off in some terms, i dont frequent forums often…

System: centos 7, php 7.2.10, mariadb 5.5.60, Ttrss v18.8 (df0115f)

Sounds like MariaDB is getting stuck on some query or PHP is having trouble.

Login to TT-RSS as the admin and in Preferences view the log to see if any PHP errors are logged. If not, then in config.php change the log destination to an empty string and re-create the issue. Then check on the server wherever PHP error logs are stored (depends on what you have set in your system’s PHP config files).

You can also enable the slow query log in MariaDB (search the Internet for steps).

One thing to also try, SSH into your server and run top, then re-create the issue and observe if there are CPU or memory spikes for any of the processes. It might help narrow down the issue.

Thanks, i will report my findings next few days

Thats weird, i changed log destination from syslog to sql and now i cant reproduce. It would seem possibel if it

was the other way around that it would time out due to queries or so but for syslog id think maybe not. I’ll tinker

some more with it and report back,so with sql logging no problemo :slight_smile:

By default TT-RSS logs errors to the database, but if the error is with the actual database it can sometimes fail in logging the error as well. fox has made some improvements to this recently, but if the database itself is the problem (e.g. too many connections, etc.) it obviously isn’t going to get logged.

I suggest running with PHP logging to a file for a few days, if the timeout occurs again then check the error logs to see if you can find where the problem is and report back.

Sorry for the delay,my setup got all scuffed had to start all over,used postgre this time and apache2,also switched

to ssd and lan network so think we can rule that out.

This time i managed to reproduce and finally an error is shown in apache2 log when i get connection timed

out,nothing in postgre log or syslog though also now im on

v18.8 (74736fc) following is error which occurs everytime i get “timed” out and yellow triangle and have to

wait for feed a while to get back or refresh. This is fresh install also no upgrade or anything

[16/Oct/2018:22:57:14 +0200] “GET /tt-rss/errors.php?1539605469&mode=js HTTP/1.1” 200 1180

http://maskedip/tt-rss/prefs.php” "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML,

like Gecko) Chrome/69.0.3497.100 Safari/537.36"

Did you check the time stamps based on when the issue occurred? The log shows the referrer being the Preferences page.

Sorry im late again but yes they correlate. Today however i cant reproduce after i disabled updates on 5 very

busy feeds. I saw new errors in the log today since last day without me using the server even,was uncarefull

and deleted/overwrote it whilst was about posting it here but will monitor and post tomorrow or so,saw this in

sql log though dont think its releated to main issue as its only 1 occurrence:

|E_WARNING (2)|classes/feedparser.php:34|DOMDocument::loadXML(): Empty string supplied as input1. classes/feedparser.php(34): loadXML()
2. classes/rssutils.php(265): __construct()
3. classes/rssutils.php(330): set_basic_feed_info(41)
4. classes/rssutils.php(192): update_rss_feed(41, 1, )
5. update.php(197): update_daemon_common(50)||Oct 17, 22:36

Ill try switch to php and syslog’ing on new install aswell,astleast for now things appear to be working so lets

see tomorrow or so (,")

Update: i think ive found the culprit, removing this feed https://www.limetorrents.info/rss/ seems to have

restored funcionality again, so not a problem with ttrss itself. This has been really annoying as couldnt find this

in logs,i was just randomly removing feeds to test, anyone able to spot what could cause this behaviour in

that particular feed? also i want later to donate to project ,have googled but couldnt find any, appriciate pm or

so with adresse thanks (,")