Are you using stock Docker compose setup? No
If not, either reproduce this issue on the official demo or switch to Docker and see if the issue is resolved.
Describe the problem you’re having:
There are a few feeds I subscribed to that returns the error:
Could not update headlines (invalid object received - see error console for details)
when viewed via browser and
Not a Json Object: Null
if opened via Android app
I check them with “myfeedsuck” but no error is returned. I added them to feedburner but the error persist if I subscribe that URL
The feeds updates correctly and the unread counter is increased accordingly
No error are logged in ttrss_error_log
Is the issue with the feed or my setup? I just moved from PostgreSQL to MySQL and on the previous setup this issue did not showed up.
…
Include steps to reproduce the problem:
The feeds I have issue with are:
Best of The Atlantic or http://feeds.feedburner.com/theatlantic/GAVA
https://theawesomer.com/feed or http://feeds.feedburner.com/theawesomer/CliT
The Intercept or http://feeds.feedburner.com/theintercept/GiNH
The China Project
…
tt-rss version (including git commit id):
v21.03-efde6d3
…
Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
PHP Version 7.3.27
MySQL Version 10.2.36-MariaDB-log-cll-lve
…
Please provide any additional information below:
…
fox
2
do a viewfeed debug (hotkey f %)
it should look like this:
[ 0 ms, 93 abs] end of articles
[ 0 ms, 93 abs] end
{"headlines":{"first_id":11621438,"is_vfeed":true,
...(long json follows)...
"recent_log_events":0,"daemon_is_running":1}}
unfortunately not
intercept.txt (19.8 KB)
I get the same result for any of the other URL I posted earlier, while I see the long text for any of the working feeds
fox
4
it’s probably some kind of fatal error (out of memory? something like that) that causes a crash while headlines are generated.
unless you figure out where the actual error is logged it’s impossible to say what’s causing it.
e: whats strange is that it goes up until the actual JSON encode and than doesn’t return anything. i’m not sure what could cause json_encode() in php to fail other than an OOM.
I am trying to retrieve them from the provider
I tried unsubscribing and re-subscribing, but once the content are retrieved, the error comes back again.
I tried also to increase PHP’s values, but apparently without any positive result…
For the time being I moved those feeds in a separate category, so that it does not impact viewing the others.
What I really can not undestand is why the problem is limited to certain feeds and not widespread…
fox
6
something about feed data, i guess. do you have any plugins? try disabling them.
I created a new user, with just one feed, no plugin enabled (except system ones) , logged into as “safe mode”.
It still does not work 
I get the same errors on some of my feeds (all, fresh, and others).
I debugged it and found (for me) it’s from feeds.php line 514 json_encode($reply) returning an empty string (and the javascript JSON.parse("") throws an error). I think it might come from an unicode-related issue.
I could not find a json_encode option that fixed it, but then I applied this quick and dirty fix and it solved the issue.
But there must be a better fix, I updated from 41bde84a922d to 2f402d598d7b and the diff is too much for me to find what introduced the bug. I’d bisect it, but I’m too afraid to break my decade-old instance (does ttrss can safely downgrade the db ?).
@fox I hope it may help you get an idea on what could have change to cause the error ? Thanks.
Note: I use php 7, mariadb.
Note 2: I did not had issue before (at 41bde84a922d), but I remember having some other unicode-related issues long long time ago in filters (the issue was fixed). i.e.: I most probably have some feeds with encoding subtleties.
fox
9
tt-rss can’t downgrade anything, migrations are one way. you can always do it manually though, it’s not hard.
this issue is not reproducible on my mariadb docker setup, so i can’t do anything about it, even if i wanted to.
e: there were some kind of mysql charset-related settings, maybe you forgot to migrate those to the new env-based schema? otherwise i don’t think anything really changed database-wise, other than idiorm being introduced (it’s not used there)
Just to report that Gravemind’s fix solved the issue on my side too.
I can provide you with my SQL dump if you have time to dig deeper
I git-bisect it, got 20d0cbff7767 as “first bad commit”, narrowed it down to the changes in _get_enclosures: I have no idea why, except for maybe a difference in encoding handling between PDO and idiorm ?
So, I looked at PDO and idiorm unicode related issues, and I quickly read about how to globally enable/activate/force? utf-8, and it worked: I found a PDO and an idiorm way to do that, they work each by themselves, but I’am not sure if they are redundant or complementary…
- 1st fix I found reading idiorm doc:
diff --git a/classes/db.php b/classes/db.php
index 008275bcab91..46587d0a5c6e 100755
--- a/classes/db.php
+++ b/classes/db.php
@@ -15,4 +15,5 @@ class Db
ORM::configure('password', Config::get(Config::DB_PASS));
ORM::configure('return_result_sets', true);
+ ORM::configure('driver_options', array(PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8'));
}
- 2nd possible fix: add
;charset=utf8' to PDO init:
(seen in comments of PDO doc)diff --git a/classes/db.php b/classes/db.php
index 008275bcab91..2073dbc54355 100755
--- a/classes/db.php
+++ b/classes/db.php
@@ -31 +31 @@ class Db
- return Config::get(Config::DB_TYPE) . ':dbname=' . Config::get(Config::DB_NAME) . $db_host . $db_port;
+ return Config::get(Config::DB_TYPE) . ':dbname=' . Config::get(Config::DB_NAME) . $db_host . $db_port . ';charset=utf8';
It seems to me a way better fix than my previous hack around json_encode (@dariottolo ).
fox
13
good job. this seems like a proper solution, to me. can you file a PR?
idiorm uses PDO but it’s a separate connection, not related to the one Db class is making. so two places might be needed.
In light of your previous post, I guess it is not needed anymore 
