-
|
Since a few months now CapyReader takes a long time to startup and, afterwards, to refresh feeds. Even if I don't have anything new to read, pulling down to refresh shows a spinner for approximately 34 seconds before finishing. If this happens during startup I get the Android pop-up asking me whether I want to wait or force close the app. I've tried clearing the cache, and I've set the "keep history" period to 1 week. I'm connecting to an instance of MiniFlux that's on my NAS, through WireGuard. This is just a http connection which works fine from the browser, there's no lag then. I'm on the latest version of CapyReader (2026.03.1202), but this has been an issue for a while now. Is there anything can do to help pinpoint the issue? I've attached two crash logs from today. In them, I see that CapyReader is trying to connect to localhost:80 for some reason, which is timing out after 30 seconds. I have no idea why it's doing that. capy_crash_logs - just doing a few pull to refreshes.txt |
Beta Was this translation helpful? Give feedback.
Replies: 11 comments 9 replies
-
|
I've also been experiencing the same slowness over the past few weeks of releases. Normally, refreshing took a 3-5 seconds at most, but that time has slowly started increasing with no changes other than CapyReader releases. The latest version (2026.03.1202) has been the slowest by far. Like OP, it takes well over 30 seconds to refresh initially whereas previously refreshes were usually around a few seconds. I'm using a self-hosted FreshRSS instance (version 1.28.1), no VPN or anything, and I have the Refresh Feeds set to manual only. Here's the interesting thing. Each successive pull-to-refresh (PTR) takes longer than the last in the same app session:
I imagine that if I did it fourth time it'd take even longer. Attached are my logs after a clean start up immediately followed by a pull-to-refresh until it finished, and then another pull-to-refresh afterward. I am seeing a lot of SSL-related exceptions. If there's anything else to help you out let me know. Initial refresh on clean startup - capy_crash_logs.txt |
Beta Was this translation helpful? Give feedback.
-
|
I'm seeing the same issue with a self hosted instance of FreshRSS. Right now my refresh for new articles is taking a minute and a half. I am NOT seeing this on my other RSS app which I keep around for testing. There the refresh is almost instant. |
Beta Was this translation helpful? Give feedback.
-
|
While looking at my FreshRSS logs when I did a refresh using Capyreader I saw a Post request 647 times. One example request is below. [22/Mar/2026:12:05:19 -0400] "POST /api/greader.php/reader/api/0/stream/items/contents?output=json HTTP/1.1" 200 76592 "-" "CapyReader (RSS Reader; https://capyreader.com/)" I tested the same thing with my other RSS client and it did 5 API requests and took less then one second. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @sagacity, the Android pop-up sounds like a request from Capy blocking the UI, so something's wrong there. This may be related to how Capy starts up with Wireguard - I've seen similar issues with Miniflux via a Tailscale connection but haven't dug into why yet. As for the |
Beta Was this translation helpful? Give feedback.
-
|
Ok, good to know! The more pressing issue is probably the "pull to refresh" one but it's good to hear you're aware of the VPN issue as well. I'll see if changing a few parts of my setup (no VPN, no DNS-based adblocking) fixes the startup "wait" pop-up. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I confirm that since the Cappy Reader update of last week I'm experiencing an higher time before the refresh on startup ends. I'm using it with a Freshrss instance. |
Beta Was this translation helpful? Give feedback.
-
|
I'm facing the same problem, a feedupdate took over 30 seconds recently. |
Beta Was this translation helpful? Give feedback.
-
|
My connection was apparently using the "Google Reader API" integration and not the "MiniFlux" integration directly, so I recreated it and switched to "MiniFlux", but that didn't help. |
Beta Was this translation helpful? Give feedback.
-
|
I think I found an issue. My MiniFlux history has grown quite large over time (~28.000 articles over a number of months), and when I "pull to refresh" and inspect MiniFlux logs, I see a lot of this: followed by: So "Pull to refresh" first refreshes all feed icons individually and then goes over the entire feed history. I've flushed the MiniFlux history (so it's empty), this mostly gets rid of the second part of the logs I pasted above, which is good! But now it still refreshes all the icons every time, which still takes about 8-9 seconds to do for 211 feeds. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the details. The icon refresh may be a red herring. I took another look and the That said, I found a regression (7e9dc2d) that was still present in v2026.03.1202 that affected any Google Reader API account. Each group of articles was fetched sequentially, 100 articles at a time. over 28k articles, that's 280 sequential requests! I have a potential fix in the latest nightly release: https://github.com/jocmp/capyreader/releases/tag/2026.03.23-nightly. It re-introduces parallel/simultaneous requests from build 1198 and decreases the amount of requests made (250 articles at at time instead of 100). This installs alongside the existing app without affecting its data. Eager to hear if that improves anything if you try it out! |
Beta Was this translation helpful? Give feedback.
-
|
I think the release you linked is the old one and I should go for 1203.nightly, right? Anyway, the behaviour for "Capy Nightly" seems identical. This is using the MiniFlux API integration btw. What I see:
|
Beta Was this translation helpful? Give feedback.
-
|
Yep sorry, wrong link. It should be 2026.03.23-nightly. Only the Google Reader API/FreshRSS integration has changed in the nightly, not the Miniflux one. I'll take another look at the Miniflux integration which is a separate module. That's still capped to 100 articles per request for unread articles. I'm not sure why favicons would take 10 seconds, but those are handle differently in the Miniflux integration. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, apologies. I've tried again with the Google Reader integration and that seems to refresh quickly now, excellent! Btw, extra points for making the "Capy Nightly" icon a sleeping Capy :) |
Beta Was this translation helpful? Give feedback.
-
|
Tried the nightly with my FreshRSS instance as well and the refresh of feeds of MUCH quicker now. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Can confirm as well. Really fast now with FreshRSS. |
Beta Was this translation helpful? Give feedback.
-
|
This fix is available in the main app starting in v2026.03.1203. |
Beta Was this translation helpful? Give feedback.
-
|
I can confirm it's working fine, thanks for the quick fix and for Capyreader in general. |
Beta Was this translation helpful? Give feedback.
-
|
Hi I confirm it fixed! Thanks for your great work!! |
Beta Was this translation helpful? Give feedback.
-
|
Same here, refresh is much better now, thank you! |
Beta Was this translation helpful? Give feedback.
-
|
I'm still seeing an issue and different behaviour from the nightly build vs the 2026.02.1203 release. Below is a comparison of the logs. The bolded entries are the nightly followed up by the 2026.03.1203 release. Shouldn't these two releases work the same? Nightly release 2026.03.1203 |
Beta Was this translation helpful? Give feedback.
This fix is available in the main app starting in v2026.03.1203.