https://bugs.kde.org/show_bug.cgi?id=452585
b...@mogwai.be changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |NEEDSINFO
Resolution|--- |WAITINGFORINFO
--- Comment #1 from b...@mogwai.be ---
Thanks for reporting. This behaviour obviously shouldn't happen. I don't
think it's a network issue because each rss download request is set to expire
after about a minute. In that case you would see the podcast update finish
with errors instead of just hanging. So that might point to a problem in the
rss parsing step(?)
Unfortunately, I don't seem to be able to reproduce this problem. I've tried
quite a few combinations of slow/fast hardware, flatpak/native packages,
different types of network connections. The only thing that comes close is
kasts on the pinephone (but that's about as slow as you can get in terms of
hardware). But even then the update finishes after a few minutes max.
Could you try and narrow down what could be causing this behaviour? E.g. do
you have other systems or hardware on which kasts works as expected? Other
network connections etc.?
What could also help is if you would be able to share debug output. You can
run the flatpak package with debug info by running the following command from
CLI:
QT_LOGGING_RULES=org.kde.kasts.*=true flatpak run org.kde.kasts
If you could share the CLI output that this generates, then that might shed
some light onto the issue.
--
You are receiving this mail because:
You are watching all bug changes.
