App version:
2.3.2 (7b87b9c0), from sailfish-apps default app store for Sailfish OS.
Sailfish OS version:
3.4 (Not sure of android version, but that shouldn’t be too relevant.)
Device model:
Jolla C
Expected behaviour:
Performing a manually initiated full refresh of all pod feeds should only happen when user explicitly decides to do so.
Current behaviour:
Scrolling the listening queue triggers undesired refresh of the full pod feed almost every time, essentially making the app and the phone unresponsive since the refresh is a very expensive operation.
First occurred:
According to release notes for 2.3.0, which I upgraded beyond about half a week ago, introduced this behavior as feature 5104. This bug has already been reported by someone as issue 5254 on github but, for reasons which imho needs to be reevaluated, was closed with no action. Could reopening of it please be considered?
Some background:
I’m a long term AntennaPod user. I love the many great parts of the software and appreciate it, including the fairly recent wonderful work in making it more efficient and responsive. Thanks a bunch for all your efforts!
Just like everything else, AntennaPod isn’t perfect though, and I happily live with it’s limitations and am accepting of its flaws. Yet this issue did get me to register for the forum and feeling the need to post.
Steps to reproduce:
- Remain on an excellent phone as long as it works well. Jolla C is still the latest (and last) phone sold with Sailfish OS. It still great for everything (except this bug), but isn’t in the top league when it comes to available system resources.
- Be a fairly avid podcast listener, with a non-trivial amount of feeds. (In my case 106 active, 279 in total. Statistics currently says 2065 hours played.)
- Accept that feeds need to be updated manually at appropriate times, because AntennaPod just can’t handle this use case. (Updating all feeds takes about ten-fifteen minutes, rendering the phone unresponsive and practically useless while that’s going on.)
- Update to 2.3.0 and try scrolling to the first entry in the listen queue. Even after PR-5281, I find unintentional refresh practically impossible to avoid in reality. The only thing that PR stopped was unintentional refresh due to already built up inertia.
Discussion:
While I can definitely see the arguments behind the position against unnecessary configuration options which the AntennaPod team has made very clear in other threads on this forum, I would like to initiate a conversation leading to a better handling of this somewhat new scroll-to-refresh feature.
As things are now, since it’s introduction I need to completely deactivate both wifi and cellular data to be able to listen to podcasts. That’s an inconvenient workaround, to say the least.
Am I making myself understood in why I perceive this new user interface feature to be a problem?
One could argue that the mere fact that the refresh button ⟳ still needs to exist is evidence that the pull-to-refresh feature is unexpected enough to motivate adding a configuration option for it under Settings → Network. Disabled by default would be my preference, but the opposite would likely be more reasonable.
Odd balls like myself, who use half-a-decade old devices are greatly annoyed by this. But also those who just do not want to accidentally trigger downloads on metered or non-trusted internet connections, right?
An alternative possible change, which I personally would consider an improvement but one which might still be insufficient for anyone who do not wish undesired network traffic at all, would be to make it possible to cancel a refresh. How feasible would it be to turn the refresh button ⟳ into a cancel button 
once a refresh is active, and abort all pending downloads if pressed? (I could not find any issue disussing this already, the closest I found was 4904 which could be considered a more generic variant.)
One could argue that the fact that refreshing the podcast list takes several seconds per feed is the real issue, but reworking that seems like a close to impossible task. Even if the code was heavily redesigned and somehow optimized to minimize resource usage on the local device to a fraction of the current toll, opening up say a hundred tcp connections and fetching data from all around the globe will never become zerocost. Hence the pragmatic solution must be to only perform the refresh when desired.
A part of me almost wishes I hadn’t placed all of my feeds in categories, so that I could have reverted back to 2.2.1 and lived happily ever after in legacy land. But since being upgraded, and liking the addition of folders, it seems reasonable to throw in a Thanks for that long awaited welcome improvement!
Could there though be a path forward, reaching a better state with regard to this unintended refresh-issue?
Please feel free to re-categorize this post, if believing another tag would be more appropriate for constructive discussion.
