Open S7venLights opened 10 months ago
I haven't been able to reproduce this - airplane mode works fine for me. Could you confirm if this is happening even with VPN completely turned off? I'm wondering if this interferes even if Obtainium is excluded.
Also could you provide screenshots of the errors showing up individually? They should be grouped.
PS when will Obtainium qualify as Vesion 1?
I would probably have removed the beta label by now if it wasn't for #608.
Ah okay - the ungrouped notifications are normal since it's not the same host (multiple apps from the same host will result in a single grouped notification).
The screenshot shows wifi+VPN - is this happening even when both are off?
It happens only while wifi is off, although I Ieft the phone on last night with no wifi or data connection and the VPN disabled as you asked before and this issue didn't present. Testing with the VPN only (no internet) today again.
Not sure if there are any updates on your end but the BG task plugin was changed in v0.15.0 so the behaviour might be different now.
Behavior has been different, no longer had errors showing, but also background updates seemed to stop working (There were no checks happening) but i see 0.15.11 has enabled 'start on boot' for the BG task, so I imagine that will fix things. This issue is probably closed
This happens to me once or twice a day. No VPN involved, at home wifi available. I had just figured my phone went into some sleep type mode where wifi maybe isn't on or some such. I'll try to be more cognizant of conditions next time now that I know there is an issue about it.
Background updates have been working again, I occasionally get the list of notifications of all the error checking updates when offline still.
Perhaps a separate issue, all of the DivestOS f-droid repo apps have been getting 'Connection timed out' errors for days now. May be the repo server is down or may be an Obtainium issue I'm not sure.
Perhaps a separate issue, all of the DivestOS f-droid repo apps have been getting 'Connection timed out' errors for days now. May be the repo server is down[…].
Doesn't seem to be the case. At least it looks good in the browser (but that doesn't necessarily have to tell anything): https://divestos.org/apks/official/fdroid/repo/
I get the same error recurringly when the phone is in airplane mode. This can be quiet annoying especially when the alarm of the notification wakes you up in the night. It would be highly appreciated if the checks would only happen when there is an active internet connection.
I have the same issue as Grishnackh. This has been going on for months for me, but when it woke me up this morning (because I forgot to silence notifications), I decided something needed to be done. Kind of glad it's not just me, but I hope it gets resolved soon.
I think I have similar problems like other posters from this thread. Sometimes I wake up and see a few notifications from Obtainium saying that the host lookup failed (from Obtainium logs):
I don't use VPN or any of the special ”night modes“ triggering airplane mode or something like that. I just use DND (Do Not Disturb) mode provided by Android (14). The device seems to stay connected according to logs from Home Assistant, so it's a little weird behavior. I don't know, why the host lookup fails at all. This is an output from the ICMP ping sensor:
So, I want to help a bit more but I just don't know what kind of information could help you to identify the cause. If you get an idea, please give me a message.
This issue hasn't presented for a long while now, probably fixed
The issue still persists when you're connected to a permanent VPN and then switch to airplane mode. When the scheduled check is triggered, the error appears as notification recurringly.
The issue still persists when you're connected to a permanent VPN and then switch to airplane mode. When the scheduled check is triggered, the error appears as notification recurringly.
Not for me in the same conditions. May be unique to your device or sources?
I can confirm the issue persists with current Obtainium version on a Pixel 8 with GrapheneOS. I am using RethinkDNS, which is creating a permanent active VPN. As soon as WiFi is disabled, a lot of those (ungrouped) error messages appear.
Is there any more information I can give to find the root cause of that problem? I guess it must have to do something with the always-on-vpn (RethinkDNS).
In my opinion the check in https://github.com/ImranR98/Obtainium/blob/06cbe74c6c6518c556b2c7e04ffd9c44f29236fe/lib/providers/apps_provider.dart#L1766 is insufficient. When wifi and mobile data is turned off but you're connected to a permanent VPN (like RethinkDNS) the above check will return ConnectivityResult.vpn
most likely (not tested).
One solution could be a real connection attempt with a network request. I don't like that too much, maybe it's enough to simply check for mobile, wifi, ethernet, bluetooth or other. If none of these are active, one could assume that the device has no internet connection.
By the way: the plugin "Connectivity" 3.0.6 used for the connectivity check is deprecated. Better use connectivity_plus: 6.0.3 instead.
In my opinion the check in https://github.com/ImranR98/Obtainium/blob/06cbe74c6c6518c556b2c7e04ffd9c44f29236fe/lib/providers/apps_provider.dart#L1766 is insufficient. When wifi and mobile data is turned off but you're connected to a permanent VPN (like RethinkDNS) the above check will return
ConnectivityResult.vpn
most likely (not tested).One solution could be a real connection attempt with a network request. I don't like that too much, maybe it's enough to simply check for mobile, wifi, ethernet, bluetooth or other. If none of these are active, one could assume that the device has no internet connection.
By the way: the plugin "Connectivity" 3.0.6 used for the connectivity check is deprecated. Better use connectivity_plus: 6.0.3 instead.
Hi, as you seem to understand it pretty well… Could you look at it and make a pull request, please?
I just investigated a bit in the debugger. When you're only connected to a (permanent) VPN the connectivity check indeed returns [ConnectivityResult.vpn]
. When you're connected to both, a wifi and VPN, the check results in [ConnectivityResult.wifi, ConnectivityResult.vpn]
.
While testing I discovered the option "Disable background updates when not on WiFi". I'll first check if this already resolves my issues with the current background checks. Have you tried this already, @ceskyDJ?
I don't have these problems after some update. It seems like the problems stayed just for users who uses permanent VPNs (which I used to use, but not use these days).
@Grishnackh thanks for looking into this. Sounds like if the connectivity result contains vpn
and nothing else, we can assume there is no internet.
While testing I discovered the option "Disable background updates when not on WiFi". I'll first check if this already resolves my issues
This would also resolve the issue but not on mobile data.
Same issue. Phone is permanently in airplane mode with an always-on vpn.
Background updates are (and always have been) turned off but a 'Checking for updates' notification shows up once the phone is turned on and moments later, there's a loud notification accompanied with errors like in the screenshot.
If you clear them and open Obtanium or an app page within, it repeats itself. Although 'Check for updates on startup' and 'on opening an App detail page' are both enabled, it could just error out with a no internet message.
While testing I discovered the option "Disable background updates when not on WiFi". I'll first check if this already resolves my issues with the current background checks. Have you tried this already, @ceskyDJ?
This option does not solve the problem for me. When background updates are enabled and the mentioned option "Disable background updates when not on WiFi" is enabled the error messages still occur when WiFi and mobile data are disabled and always-on-vpn exists (when turning on WiFi again).
I added the ConnectivityResult.vpn
check suggested by @Grishnackh: https://github.com/ImranR98/Obtainium/releases/tag/v1.1.14
Not sure if it helps with every scenario mentioned above, we'll see if the error still occurs.
After upgrading to 1.1.14 the issue is gone for me, I had no more annoying notifications. Thank you very much, @ImranR98.
I added the
ConnectivityResult.vpn
check suggested by @Grishnackh: https://github.com/ImranR98/Obtainium/releases/tag/v1.1.14 Not sure if it helps with every scenario mentioned above, we'll see if the error still occurs.
It seems that version v1.1.14 still has a bug. When I turn on WIFI and VPN, it still prompts "Host search failed".
@wanzh5 Are you sure this is related to this issue? The fix from @ImranR98 addressed particularly the situation when you're connected to a (permanent) VPN without any other connection like wifi, bluetooth or ethernet. The above fix won't apply when you're connected to wifi + VPN.
Do you use any ad blockers or custom DNS settings?
I can also confirm the problem is gone in v1.1.14, thanks!
I'm still getting this issue in v1.1.23. I'm an always-on VPN user. Once I open the app, the update check seems to work fine. Happy to try and provide more info if needed.
Describe the bug I've had this bug for over a month now, only getting time to report now. When my phone is offline in airplane mode the app still attempts update checks on my 3 hour schedule. I know, because I get a bunch of individual notification all at once for each app that fails. The notifications fill up my screen, one on top of the other and aren't grouped. . Most say 'failed host lookup' This happens whether or not the setting 'Disable background updates when not on wifi' is toggled on or off. When i am connected to wifi in airplane mode, updates work fine.
Expected behavior: The app wouldn't attempt updates if the phone is offline and wifi is off.
To Reproduce Mentioned above. I also use InviZible pro in VPN mode, but I've excluded Obtainium from going through TOR.
Screenshots and Logs Not necessary, logs just show each app saying "failed host lookup"
Please complete the following information:
Additional context Thanks for the app as always.