SUMMARY With some podcasts platforms, such as podcasts distributed on Patreon, the download URLs in the RSS feed are only valid for about two days, at which point you need to fetch the RSS feed again to download the episodes. But Kasts, when updating an RSS feed, ignores episodes already in the database, and does not update the URL if it has been changed in the RSS feed. STEPS TO REPRODUCE 1. Add a podcast from Patreon 2. Update the feed 3. Wait three days 4. Update the feed again 5. Try to download an episode OBSERVED RESULT It tries to download from the expired URL. EXPECTED RESULT It should use the URL from when I updated the feed in the fourth step, not the URL for the episode provided in the second step SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Mmm, I guess it's not forbidden to do such a thing, but it sure is very strange to be changing the enclosure URLs constantly. If I may ask, do you have more information about this? I tried searching, but couldn't find a single reference or example of such a situation. Anyway, I can confirm that Kasts currently doesn't refresh existing entries. This is deliberate, since it saves many minutes of feed refresh time on underpowered hardware. I'll have to think about how to address this. Maybe a separate option to "force refresh" a particular feed...
same effect here in a first version it worked as expected, but in a newer version (and newest) an update of all podcast list, they're taking a very long time. Also after a restart of the application, the performance of the refresh (update) isn't better. If I check the network there isn't network traffic. I suppose that the problem could be internal. The gnome app 'vocal' update the podcast list faster, not comparable with kasts
@mschnide: I'm not sure your issue is related to this topic. Kasts has never updated existing episodes so that can't cause any differences between older and newer versions. It sounds like you are describing a different issue which is unrelated. Do you happen to use gpodder or gpodder-nextcloud syncing? Because that's a new bit that was changed in more recent versions that has got to do with the podcast update functionality.
@mschnide: The issue you reported is a different one and tracked through this ticket: https://bugs.kde.org/show_bug.cgi?id=452585
A possibly relevant merge request was started @ https://invent.kde.org/plasma-mobile/kasts/-/merge_requests/71
Git commit aac899a7f006678252a196471db475b81bd69afa by Bart De Vries. Committed on 31/05/2022 at 14:11. Pushed by bdevries into branch 'master'. Refactor feed update routine to allow for entry, enclosure, authors and chapter updates This commit adds a bunch of API extensions (public and private) to the entry, enclosure, etc classes to allow runtime updates of internal data. Additionally, the feed update routine has been adapted to find updates in entries, enclosures, etc and pass them on to the relevant objects. All of this functionality is put behind a new toggle exposed in the settings (default is on). This is useful since a full update takes quite a bit longer on underpowered hardware, so users should be able to switch off this potentially non-essential overhead. M +7 -0 src/CMakeLists.txt M +50 -0 src/enclosure.cpp M +9 -4 src/enclosure.h M +163 -35 src/entry.cpp M +28 -11 src/entry.h M +1 -1 src/fetcher.cpp M +2 -1 src/fetcher.h M +6 -1 src/qml/Settings/GeneralSettingsPage.qml M +4 -0 src/settingsmanager.kcfg M +256 -45 src/updatefeedjob.cpp M +8 -12 src/updatefeedjob.h https://invent.kde.org/plasma-mobile/kasts/commit/aac899a7f006678252a196471db475b81bd69afa