SUMMARY On Fedora 38 Workstation with GNOME 44.4, using last version of Kasts (flatpak 23.08.1). Kasts won't update subscriptions nor download podcasts, saying that it is not allowed on a metered connexion: - regardless of the settings - regardless of the connexion (which is not metered and not detected as such in GNOME) - could not reproduce this on my Debian 12 computer with GNOME and Kasts (flatpak) STEPS TO REPRODUCE 1. Launch Kasts and verify the settings: all options are checked in the "Network" tab (so everything is allowed with metered connexions). Verify GNOME network settings: computer is connected to the internet through a non-metered connexion (through ethernet port). 2. Press the "Refresh All Podcasts" button. 3. Kasts says "Podcast updates are currently not allowed on metered connections". Click on "Always Allow". Refresh works. 4. Download one episode. 5. Kasts says "Podcast downloads are currently not allowed on metered connections" *. Click on "Always Allow". Download does not start and an error appears: error 0 "Podcast updates not allowed due to user setting". (6. Try again to "Refresh All Podcasts": same happens than in step 2.) *btw, the french .po files contains a translation error concerning that line (it says updates are not allowed when it should say downloads are not allowed). OBSERVED RESULT Connexion is identified as metered when it's not, and Kasts'network settings are not followed. The "always allow" is not followed either. It is still possible to refresh podcasts, but not to download them. EXPECTED RESULT Connexion should be identified as not metered when it is not metered. When it is metered (or seen as such), Kasts should follow its own network settings. The "always allow" button should have an ongoing impact. It should be possible to download podcasts.
(In reply to yga1vsm0 from comment #0) > SUMMARY > > On Fedora 38 Workstation with GNOME 44.4, using last version of Kasts > (flatpak 23.08.1). > > Kasts won't update subscriptions nor download podcasts, saying that it is > not allowed on a metered connexion: > - regardless of the settings > - regardless of the connexion (which is not metered and not detected as such > in GNOME) > - could not reproduce this on my Debian 12 computer with GNOME and Kasts > (flatpak) > > > STEPS TO REPRODUCE > 1. Launch Kasts and verify the settings: all options are checked in the > "Network" tab (so everything is allowed with metered connexions). Verify > GNOME network settings: computer is connected to the internet through a > non-metered connexion (through ethernet port). > 2. Press the "Refresh All Podcasts" button. > 3. Kasts says "Podcast updates are currently not allowed on metered > connections". Click on "Always Allow". Refresh works. > 4. Download one episode. > 5. Kasts says "Podcast downloads are currently not allowed on metered > connections" *. Click on "Always Allow". Download does not start and an > error appears: error 0 "Podcast updates not allowed due to user setting". > (6. Try again to "Refresh All Podcasts": same happens than in step 2.) > > *btw, the french .po files contains a translation error concerning that line > (it says updates are not allowed when it should say downloads are not > allowed). > > OBSERVED RESULT > Connexion is identified as metered when it's not, and Kasts'network settings > are not followed. The "always allow" is not followed either. > It is still possible to refresh podcasts, but not to download them. > > EXPECTED RESULT > Connexion should be identified as not metered when it is not metered. When > it is metered (or seen as such), Kasts should follow its own network > settings. The "always allow" button should have an ongoing impact. > It should be possible to download podcasts. I have encountered exactly the same behavior in case of the Kasts 23.08.1 installed via Fedora RPM. Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.6-200.fc38.x86_64 (64-bit) Graphics Platform: Wayland I have also specifically marked my Wi-Fi connection in network settings as non-metered, but Kasts still does not allow for download even if I check all four consents in application's own network settings, which should let me do it on a metered connection.
(In reply to maizjoris from comment #1) > (In reply to yga1vsm0 from comment #0) > > SUMMARY > > > > On Fedora 38 Workstation with GNOME 44.4, using last version of Kasts > > (flatpak 23.08.1). > > > > Kasts won't update subscriptions nor download podcasts, saying that it is > > not allowed on a metered connexion: > > - regardless of the settings > > - regardless of the connexion (which is not metered and not detected as such > > in GNOME) > > - could not reproduce this on my Debian 12 computer with GNOME and Kasts > > (flatpak) > > > > > > STEPS TO REPRODUCE > > 1. Launch Kasts and verify the settings: all options are checked in the > > "Network" tab (so everything is allowed with metered connexions). Verify > > GNOME network settings: computer is connected to the internet through a > > non-metered connexion (through ethernet port). > > 2. Press the "Refresh All Podcasts" button. > > 3. Kasts says "Podcast updates are currently not allowed on metered > > connections". Click on "Always Allow". Refresh works. > > 4. Download one episode. > > 5. Kasts says "Podcast downloads are currently not allowed on metered > > connections" *. Click on "Always Allow". Download does not start and an > > error appears: error 0 "Podcast updates not allowed due to user setting". > > (6. Try again to "Refresh All Podcasts": same happens than in step 2.) > > > > *btw, the french .po files contains a translation error concerning that line > > (it says updates are not allowed when it should say downloads are not > > allowed). > > > > OBSERVED RESULT > > Connexion is identified as metered when it's not, and Kasts'network settings > > are not followed. The "always allow" is not followed either. > > It is still possible to refresh podcasts, but not to download them. > > > > EXPECTED RESULT > > Connexion should be identified as not metered when it is not metered. When > > it is metered (or seen as such), Kasts should follow its own network > > settings. The "always allow" button should have an ongoing impact. > > It should be possible to download podcasts. > > I have encountered exactly the same behavior in case of the Kasts 23.08.1 > installed via Fedora RPM. > > Operating System: Fedora Linux 38 > KDE Plasma Version: 5.27.8 > KDE Frameworks Version: 5.110.0 > Qt Version: 5.15.10 > Kernel Version: 6.5.6-200.fc38.x86_64 (64-bit) > Graphics Platform: Wayland > > I have also specifically marked my Wi-Fi connection in network settings as > non-metered, but Kasts still does not allow for download even if I check all > four consents in application's own network settings, which should let me do > it on a metered connection. Kasts today has been updated to 23.08.2, but this issue still affects the installation.
Updating to today's 23.08.2 did not help. I tried downgrading. Here is how it goes when going back in time. 1) Commit: 6107bc4f80179c2945ceb510bd475dc503990ebb4a0daae0cbb61b0f98b092d1 (548120ad), 2023-08-24, v23.08.0 The issue is already happening. 2) Commit: af539c223a9c115dcc188710da64022022a3bba0b9a9ea83563e6e445180493a (65a6a22e), 2023-08-16, v23.04.3 (v0.11.0?!) The issue was not happening yet. So for now, getting back to version 23.04.03 would be the way to go until there's a fix: sudo flatpak update --commit=af539c223a9c115dcc188710da64022022a3bba0b9a9ea83563e6e445180493a org.kde.kasts
Thanks for tracing back the problem to individual commits. That really helps since I can't reproduce the problem on my side. This at least gives some pointers on where to start looking.
I confirm that downgrade helps to work around this issue. DNF has allowed me to downgrade only to version 23.01, but still it seems to be not affected.
I've thoroughly reviewed the code, and the only possible explanation that would explain the symptoms would be that either networkmanager or the connectivity dbus service is saying that you're not connected to the network or on a portaled or very limited network connection. The code of Kasts did indeed change to also include an additional connectivity check for downloads (because of refactoring for the upcoming qt6 version). Only if your system responds by saying that you are not connected (or limited), then it is indeed impossible to actually get into the download routine no matter what the state of the metered settings. This is because the problem is actually not the connection being metered, but because Kasts thinks it's offline. So, that means: - The error reporting needs to be updated to actually report that the problem is connectivity instead of the metered status. - The code should probably take into account the fact that it can receive a completely wrong status of the connectivity. One possible solution is to remove the connectivity checks altogether, but that will lead to downloads and refreshes hanging until timeout. One additional thing that would really help: if you know how to do it, could you check what NetworkManager or dbus "org.freedesktop.portal.NetworkMonitor" is reporting as value for the "connectivity" property? (And while you're at it, you might as well doublecheck the "metered" property as well, but that shouldn't be the problem.)
In order to test it further, I updated Kasts to v23.08.2 again and... the issue is gone 🤔 I rebooted... It still working perfectly. I don't know if it will be the same for maizjoris? (is going backward and then upgrading straight to 23.08.2 is supposed to bring different results than going through each version to 23.08.2?) So I'm not sure I can help further, as I no longer encounter that bug 🧐
(In reply to yga1vsm0 from comment #7) > In order to test it further, I updated Kasts to v23.08.2 again and... the > issue is gone 🤔 > I rebooted... It still working perfectly. > > I don't know if it will be the same for maizjoris? > (is going backward and then upgrading straight to 23.08.2 is supposed to > bring different results than going through each version to 23.08.2?) > > So I'm not sure I can help further, as I no longer encounter that bug 🧐 It is the same for me. I have encountered this issue in both RPM and flatpak versions, but right now both are working fine. I have wanted to check connectivity property as Bart suggested, so I ran "nmcli networking connectivity check" in Konsole. It retuned "limited" when I was connected to VPN and "full" otherwise, so it gave me an idea that Kasts may possibly mistakenly recognize VPN connection as metered. I had previously downgraded both Kasts intallations (RPM to 23.01, flatpak to 23.04.03), so I ran the upgrade of both via Discover. However after reboot problem no longer occurs.
Thanks for the quick feedback, both of you. I still don't understand why you would first encounter the issue and why it would then disappear without really changing anything. Anyway, I'm happy that it works for you now. I'll keep the bug report open anyway, because it's clear that if a network connection falsely reports to be offline, there is currently no way to circumvent that. Also the error reporting needs to be updated to report that the issue is actually the connection itself rather than the fact that it's metered.
@bart Unfortunately the problem has reappeared on my end in regard to both, no matter if I there is VPN connection or not, so I have reinstalled the flatpak. Issue briefly disappeared, but right now it still occurs. It behaves too erratic to pinpoint what may be at fault here. Could you please advise how to obtain the log files from Kasts? I would like to provide you with logs from both versions, for it seems to be the only way to get to know what exactly is going on here.
> Could you please advise how to obtain the log files from Kasts? I would like > to provide you with logs from both versions, for it seems to be the only way > to get to know what exactly is going on here. In principle this is possible by running Kasts with this environment variable specified: QT_LOGGING_RULES=org.kde.kasts.networkconnectionmanager=true But I was looking at that a few days ago and the current code doesn't have sufficient debug logging to actually see which of the individual variables/function calls are causing Kasts to think that it's not connected or metered. So it will just output whether any of the four items from the settings menu are actually allowed or not, but it won't specify exactly why. That's also something that needs to be improved. Would you perhaps be ok with compiling Kasts from (git) source to verify that my intended solution works once I've made the updates?
Ok, I will try. Let me know once the source is ready.
A possibly relevant merge request was started @ https://invent.kde.org/multimedia/kasts/-/merge_requests/139
(In reply to maizjoris from comment #12) > Ok, I will try. Let me know once the source is ready. The implementation is available as MR at https://invent.kde.org/multimedia/kasts/-/merge_requests/139 Or you can directly retrieve it through the git branch "work/rip-out-connectivity-check"
Git commit ea5d01043d01a8d5ecdcf81ef30d3313361c8ad4 by Bart De Vries. Committed on 17/10/2023 at 09:36. Pushed by bdevries into branch 'release/23.08'. Remove network connectivity check Apparently in some cases the network manager is incorrectly signaling that the system is offline while it's actually online. The current implementation does not have a way to circumvent that incorrect reporting. Also the error reporting made it seem that the actual problem is a metered connection. Ripping out the connectivity check solves these issues at the expense of connections timing out rather than the connection not being set up in the first place when the system is offline. M +8 -16 src/networkconnectionmanager.cpp https://invent.kde.org/multimedia/kasts/-/commit/ea5d01043d01a8d5ecdcf81ef30d3313361c8ad4
Git commit 52a1f08e02dd2d9d03e0cd144ca5d3e4ff84cc42 by Bart De Vries. Committed on 07/11/2023 at 22:06. Pushed by bdevries into branch 'master'. Add a switch to globally enable/disable network status checks Make error reporting less ambiguous: report either "no connection" or "not allowed on metered connection". Also show hint how to disable network status checking altogether. M +18 -12 src/audiomanager.cpp M +12 -7 src/enclosure.cpp M +7 -1 src/error.cpp M +1 -0 src/error.h M +8 -4 src/qml/ConnectionCheckAction.qml M +23 -0 src/qml/Settings/NetworkSettingsPage.qml M +1 -1 src/qml/main.qml M +4 -0 src/settingsmanager.kcfg M +35 -8 src/utils/networkconnectionmanager.cpp M +3 -0 src/utils/networkconnectionmanager.h https://invent.kde.org/multimedia/kasts/-/commit/52a1f08e02dd2d9d03e0cd144ca5d3e4ff84cc42