ntp
ntp copied to clipboard
"TimeoutException after 0:00:05.000000: No stream event"
I am getting this error on some networks. specially when I submit the app to app store for review they rejected my app 5 times , because this plugin. It does not respond for infinite time until I have set an timeout of 5 seconds. I am not getting any issue in my network and it worked well. below is my code can you please check the issue and resolve it. i have tried time.google.com, time.windows.com but nothing works for app store review.
var networkDate = await NTP.now(lookUpAddress: "time.windows.com", timeout: Duration(seconds: 5));
@uc-dve which version are you using?
I am using version NTP 2.0.0
How often are you calling this?
I am calling it only once while trying to login
hello Any update on the issue?
Hey sorry for delay. Hmm not really sure, you could try with time.apple.com? Not sure what could cause that since I didn't have problem with app store and this lib.
I am getting this error on some networks. specially when I submit the app to app store for review they rejected my app 5 times , because this plugin. It does not respond for infinite time until I have set an timeout of 5 seconds. I am not getting any issue in my network and it worked well. below is my code can you please check the issue and resolve it. i have tried time.google.com, time.windows.com but nothing works for app store review.
var networkDate = await NTP.now(lookUpAddress: "time.windows.com", timeout: Duration(seconds: 5));
Omg! Same with me! My app got rejected as well more than 5 times and i am using this package for all my apps (which are like 5 apps in total). They send me screenshots that they are getting the network error but on my side it works fine. Please let me know if you have found an alternative.
Hey sorry for delay. Hmm not really sure, you could try with time.apple.com? Not sure what could cause that since I didn't have problem with app store and this lib.
time.apple.com does not work on my side.
I am getting this error on some networks. specially when I submit the app to app store for review they rejected my app 5 times , because this plugin. It does not respond for infinite time until I have set an timeout of 5 seconds. I am not getting any issue in my network and it worked well. below is my code can you please check the issue and resolve it. i have tried time.google.com, time.windows.com but nothing works for app store review.
var networkDate = await NTP.now(lookUpAddress: "time.windows.com", timeout: Duration(seconds: 5));
Omg! Same with me! My app got rejected as well more than 5 times and i am using this package for all my apps (which are like 5 apps in total). They send me screenshots that they are getting the network error but on my side it works fine. Please let me know if you have found an alternative.
I didn't get any alternative yet I am using my website API to get current time. Just wrap it with try-catch block and implement your own logic on catch block when timeout exception.
try {
var networkDate = await NTP.now(
lookUpAddress: "time.windows.com", timeout: Duration(seconds: 3));
} catch (err) {
print("NTP time err $err");
// I caught this issue by uploading the error and device, info to the firebase.
return false;
// throw "Unable to get NTP time.";
}
Hey sorry for delay. Hmm not really sure, you could try with time.apple.com? Not sure what could cause that since I didn't have problem with app store and this lib.
Hey, still facing this issue with ntp 2.0.0. Is there a fix?
So I can confirm this package is causing the iOS version to be rejected.
I use this package for my API Validations. They weren't able to login into it and rejected the app.
This time, I submitted the app again and used http://worldtimeapi.org/api/timezone/Africa/Nairobi to get my time when i was calling my login API and they were able to log in.
But it still got rejected because when they were going through the app, they weren't able to get access of some sections where the API was called using this package..
Plz let us know if this bug is on your side or not? I am in a very big dilemma!
@knezzz ??
Not sure why this is happening to you.
I have multiple apps on appStore and know of few apps (Some apps that use it for 2FA) that use this lib and they never had any problems nor were they ever rejected because they used this lib.
My suggestion for now would be to call NTP offset and remember offset locally, don't call NTP.now() since that will return DateTime and you cannot reuse that, but you can reuse offset. Then handle timeout and when offset is fetched just apply it to current DateTime.
I have the same problem: my app got rejected twice on the App Store.
I've been using the approach you have just recommanded @knezzz: fetching the offset once in a while and storing it locally to use it when needed (I had to do it because I need true utc time while in offline mode). I am also calling NTP.getNtpOffset()
from inside a try
/catch
block.
As for @uc-dve, the NTP request didn't seem to ever end when apple reviewers were testing the app and setting the timeout
parameter in getNtpOffset
solved it.
Thoughts:
- May be a timeout value should be set by default to avoid this? Nobody wants a request to run forever.
- #16 seems to be a duplicate of this issue, but the OP says that the error occurs when the device is connected on IPv6 only. It might be the explanation of the problem described here.
#36 may also be a duplicate as the OP talks about a NTP.now()
request that never ends.
@mr-mmmmore Yeah fix with default timeout seems like best option. I will add default timeout to NTP.now()
and that should fix few issues.
But yeah, this is imagined as low level library just to fetch the NTP time. Keeping time synced, managing timeout and possibly saving it to local database is left to the user. Since this will work in pure dart on all platforms, and adding such functionality can only limit the package.
I will add default timeout to
NTP.now()
You mean to NTP.getNtpOffset()
don't you? Since now()
uses getNtpOffset()
.
hey, any news about this? I'm facing with this error in some specific devices. cc @knezzz
explaning, in certain devices in certain network the flow is as expected, but in specific devices (as J600GT), this appears.