Broken Images in Feeds?

[sleeper_service]

It's a default installation of tt-rss 1.8, with the settings and feeds imported via OPML from the older instance. I haven't made any other changes.

Anyway, thanks. It's obvious tt-rss is not the issue here.

did you check the feed settings on both installs to see if all the checkboxes are set the same?

[fox]

Nah I just post bears because bears are p. cool

[sleeper_service]

Nah I just post bears because bears are p. cool

on the internet, nobody can tell you're a bear.

how do you type with those long clawz?

[fox]

Don't get all furry on me now

[ZeGuigui]

how do you type with those long clawz?

Probably the same way you type with those small fingers!

[xtaz]

I thought hotlinking was basically the reason local image cache options were in ttrss? So it shows the image from your ttrss install rather than hotlinking to the origin website.

[sleeper_service]

how do you type with those long clawz?

Probably the same way you type with those small fingers!

quickly? *tappa* *tappa* *tappa*

[moronim]

I've enabled image caching for the feed as well as disabled image caching. Still no luck - images show up a broken. It makes sense that if the site has hotlink protection enabled for the images to show up as broken, but wouldn't image caching circumvent that?

EDIT: One other data point to add... The images from the feed show up in the tt-rss mobile clients (yattrssc) and reeder (using the fever API), so if hotlink protection on the site is enabled, wouldn't they be showing up as broken images on the mobile clients?

[fox]

>, but wouldn't image caching circumvent that?

It should, you are doing something wrong.

>The images from the feed show up in the tt-rss mobile clients (yattrssc) and reeder (using the fever API), so if hotlink protection on the site is enabled, wouldn't they be showing up as broken images on the mobile clients?

Why would an embedded webview send a referrer? You don't know how any of this works, do you?

[moronim]

>It should, you are doing something wrong.

Does selecting this option only cache images for new articles that arrive? Or would it apply to the full set of articles and also cache the images for existing articles in the feed?

Outside of going into the preferences and selecting "cache images locally" for the feed, what other suggestions would you have to help me try to address this?

> Why would an embedded webview send a referrer? You don't know how any of this works, do you?

Master of the obvious! If I knew how this works, why would I be posting to a support forum?

[fox]

>Does selecting this option only cache images for new articles that arrive

Feed should be updated afterwards. You can open image in a new tab and see if image.php?hash= opens.

>Master of the obvious! If I knew how this works, why would I be posting to a support forum?

This has very little to do with tt-rss.

[moronim]

Problem solved... Thanks. Opening the link to the cached image pointed me to the problem. The linux virtual machine which hosts tt-rss on my network resides on my internal network and my external web server (running on a windows OS) acts a reverse proxy to the linux machine. When I opened the cached image link directly, the URL was pointing to my internal IP URL (http://192.168.1.x/tt-rss) - obviously wrong. I went back in and corrected the SELF_URL_PATH in the config.php to the external domain / URL for the tt-rss install and voila! The image path was corrected and now the cached images appear correctly in the feed. Thanks for your help...

[sleeper_service]

When I opened the cached image link directly, the URL was pointing to my internal IP URL (http://192.168.1.x/tt-rss) - obviously wrong. I went back in and corrected the SELF_URL_PATH in the config/php to the external domain / URL for the tt-rss install and voila! The image path was corrected and now the cached images appear correctly in the feed. Thanks for your help...

it's amazing how much better things work when configured correctly, innit, people should take note