Tiny Tiny RSS: Community

Libpng warning: Interlace handling should be turned on when using png_read_image

Describe the problem you’re having:

Update via cron job is scheduled every hour. Once a day I receive an email with the error in the title.
I am shared hosting and my provider asked me how to reproduce the error.
I am not sure if this is related to rss or with some settings of the server. I can not figure out if some particular feed generate the error. If I run the update manually, with --force-update as parameter I do not see any issue. error_log is also empty

If possible include steps to reproduce the problem:
I can not figure out how to reproduce the problem

tt-rss version (including git commit id):

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
Shared hosting, (i believe) CloudLinux7, PHP 7.2.29, PostgreSQL 9.2.24

Please provide any additional information below:

And what exactly is that error? It could be specific to your provider, it could be a generic “non-zero exit status”, it could be something else. And what’s in the body of this email?

I rather suspect they were being lazy, and decided to stick it just the subject of the topic, rather than in the body of the message where most people would normally expect it.

Even more lazy, since if they’d put it into google instead, they might find the answer to their problem.

The body of the mail is:

Libpng warning: Interlace handling should be turned on when using png_read_image

I thought that using the error as subject of the topic would be easier . My mistake.

I tried googling it before posting, but I could not find anything helpful.
As I wrote in the original post, I asked the tech support of my provider and they asked how to reproduce. Maybe next time I will tell them to google it…

those kinds of warnings i think are impossible to disable, because it’s a third party library (i.e. libpng) which is invoked by a PHP module (very likely GD, while resizing an image in some particular article).

i suggest filtering it out in your cron script, there’s not much to do about it otherwise.

e: i’m assuming that this happens because of something tt-rss does, but it could really be any PHP or otherwise application.

Ah yes, I totally missed that it was in the topic here.

Still, that’s a warning, not an error per se.

The real issue is that something is causing non-zero exit status, presumably, else you’d not get an email at all. If you feel like living dangerously you could put a || exit 0 on the end of the cron job :wink:


I now realize the original post could have been written differently and I apologize.

The initial request came because I run cron with --quiet, therefore I am not expecting any email, unless something is not working.
For a couple of days though I was receiving something like this, only once a day:

-------- Forwarded Message --------
Subject: Cron /usr/local/bin/php /home/user/public_html/tt-rss/update.php --feeds --quiet
Date: Tue, 21 Apr 2020 04:31:58 +0200
Sender: (Cron Daemon) <>
To: [email protected]

libpng warning: Interlace handling should be turned on when using png_read_image

Therefore I assumed something was happening, but I was not entirely sure it was caused by TT-RSS or some misconfiguration of the server, maybe an older version of libpng.

As I am on shared hosting, I first asked them, and their answer was “how could we replicated it”.

Since I was unaware of what might have been the cause, I thought I might ask here, and then report to the hosting provider.

usually it’s either non-zero or something in stdout.

well you can try removing that so you’d see when exactly this warning is generated.

That did the trick:

[15:33:59/2964704] Base feed: http://gizmodo.com/rss
[15:33:59/2964704] => 2020-04-21 14:27:15.316304, 150 2
libpng warning: Interlace handling should be turned on when using png_read_image
[15:34:04/2964704] Purged feed 150 (7): deleted 0 articles
[15:34:04/2964704] 5.5739 (sec)

Among 275 feeds updated, this is the only one that this time had issue.

I am trying to compare what’s in TT-RSS and the original feed and it seems that some articles are missing, but I am not 100% sure.

Usually when I want really silent cron jobs I’ll add:

&2>1 >/dev/null

>/dev/null 2>&1

to the end of the command. This sends stderr to stdout, then stdout to null. You’ll never see anything at that point. (Which could be good or bad, you decide.)

You could always redirect to a file (in truncate first mode) instead. That way you can check the last run, be that when you think there’s an issue, periodically, or, er, in another cron script :wink: .

i think you mean >/dev/null 2>&1.

yes, the order of your redirections, ie stdout to /dev/null then stderr to stdout, and the placement of the ampersand, ie so it applies to the redirection and not misinterpreted as backgrounding the current command, are significant.

[email protected]:~$ cat << EOF > std-out-err.sh
> #!/bin/sh
> echo stdout
> echo stderr >&2
[email protected]:~$ sh std-out-err.sh 
[email protected]:~$ sh std-out-err.sh > /dev/null
[email protected]:~$ sh std-out-err.sh 2> /dev/null
[email protected]:~$ sh std-out-err.sh > /dev/null 2>&1
[email protected]:~$ sh std-out-err.sh 2>&1 >/dev/null
[email protected]:~$ sh std-out-err.sh &2>1 >/dev/null
[1] 27589
[email protected]:~$ stdout

Thanks. That was a typo on my part. I’ll fix it just in case someone finds the post during a search.