SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. subscribe to some podcasts 2. hit refresh podcasts button 3. wait.... OBSERVED RESULT Subscribed podcasts take a loooong time to refresh and often the dialog box remains open indicating '0 of x podcasts updated' until the application is terminated EXPECTED RESULT Quick update of subscribed podcasts episodes SOFTWARE/OS VERSIONS Ubuntu 21.10 Kasts 22.02 installed via Flatpak ADDITIONAL INFORMATION Fast ethernet connection Toshiba Portege Z30-A laptop 7.7 GiB memory Intel® Core™ i7-4600U CPU @ 2.10GHz × 4 256.1 GB disk capacity Gnome version 40.4.0
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.
Created attachment 148331 [details] CL output for Kasts
Thanks for the debug output. I *think* it's the same thing that I'm seeing on the pinephone. It looks like the feed update routine keeps switching between update tasks rather than executing them. It only seems to happen under certain circumstances, though. Unfortunately, the definitive solution would require a complete re-write of the update/sync routine to either process everything completely sequentially or by using multi-threading.
I have tried to update the subscribed podcasts individually instead of as a group (update all). Definitely some podcasts take considerably longer more than others to update but none more than 20 seconds (average is 5-7 seconds). Ok when there are 18 this adds up but it is significantly quicker than the update all option. I will use this as a workaround or eliminate the podcasts that take the longest to load from the group.
workaround: If I update all podcast and click after on 'settings', the update process is very fast I suppose that an event is 'hanging'
I can replicate that - clicking on settings while the queue is downloading seems to bypass the delay. That's a workaround! Would this be a local network or a program issue?
As far as I've been able to analyze it, the issue is related to the fact that the feed updates are done in parallel. Those parallel jobs are all running on the main thread (which means that they are actually still running sequentially), but are programmed in such a way that they will give control back to the main event loop (which is handling the separate jobs and the main UI) after processing a podcast episode to ensure that the UI keeps responding. For some reason, on certain hardware/software combinations, it seems like those parallel jobs keep giving control to each other over and over again, leading to a semi-infinite loop. I really don't know what the underlying cause is and why it doesn't happen on all hardware/software combinations. I do plan to re-write the update code to use multi-threading, but it will take a while since that's not trivial.
Git commit 633f4fd0f0353103ad3635590354de7d95b59e72 by Bart De Vries. Committed on 29/05/2022 at 13:22. Pushed by bdevries into branch 'master'. Use multithreading for feed updates (using ThreadWeaver) This contains the following changes: - Use separate db connections for feed updates (required for multithreading. - Add ThreadWeaver dependency. - Port update job from KJob to ThreadWeaver::Job - This should also solve the bug where the update process would hang on the "processEvents" call, which was intended to keep the UI responsive during updates. M +1 -0 .kde-ci.yml M +1 -1 CMakeLists.txt M +2 -1 README.md M +1 -1 src/CMakeLists.txt M +25 -14 src/database.cpp M +11 -5 src/database.h M +2 -2 src/datamanager.cpp M +1 -1 src/datamanager.h M +38 -10 src/fetchfeedsjob.cpp M +1 -1 src/fetchfeedsjob.h M +38 -50 src/updatefeedjob.cpp M +10 -7 src/updatefeedjob.h https://invent.kde.org/plasma-mobile/kasts/commit/633f4fd0f0353103ad3635590354de7d95b59e72