-
Notifications
You must be signed in to change notification settings - Fork 425
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nearly identical location records saved to SQLLite DB 10 minutes apart; What does event:null mean? #1993
Comments
FYI...the library log timestamps are in IST and the API log timestamps are in GMT. |
Yes, they are. |
Certainly didn't mean to imply that was the issue. Just trying to be helpful to figure out what's going on. |
Good morning, Chris. Just wanted to check to see if we can get any guidance on this issue? Thank you! |
It’s not unusual that a location with coords the same as the last could be inserted if the OS is only able to provide the last known location. |
Agreed, but the logs demonstrate pretty clearly that something else is happening here. There are something like 100 other locations inserted to the plugin db over that 10 minute gap. And we're getting large batches of repeated entries into the plugin db (with only the noted slight differences). |
You're using a very aggressive |
Absolutely. But the question isn't "why are we getting a lot of data?" The question is "why are we getting the same big batches of data 10 minutes apart?" |
What timestamps from your logs is this phenomenon evidenced? |
The data associated with timestamps are also seen in the API log file. I believe the repeated batch is highlighted in red. |
And what is your I'm not interested in your excel file. I'm only interested in my plugin's logs. Which timestamp(s) in the log are you interested in me having a look at? |
I don't believe HeadlessTask is doing anything. We're using autoSync. The reason we provided the API logs is that they show the data collected by the plugin where the plugin logs do not. That is how we know that nearly identical data is being inserted into the plugin db across relatively long time spans.
Those timestamps appear to be the initial insert of the data (age = 90) and the nearly identical second insert of the data (age = 602120). |
Each location has
|
Exactly, we've done that which is how we know that this is not new original location data. |
Then tell me some particular |
Chris, I've listed this same UUID info several times...
|
From the API log, UUID 24cbed22-c547-43b1-b9b9-ae0e0e7c7bca is in a batch of 10 on row 3 and has this data:
From the API log, UUID 4faa7d99-b8d2-4412-a415-84df5c4f9a6d is in a batch of 10 on row 21 and has this data:
You can see that everything is identical except for age, is_moving, and activity.type. |
These two locations were provided by the native location API stream while in the tracking state. They are separated by about 10 min, reflected by a high |
But, as you would have no doubt noticed as you scrolled through those logs, there were about 100 newer fresher location results received in that 10 minute gap. |
at ~
These locations you're receiving are being provided by the OS location stream. For some unknown reason, the native location API had no fresh location to provide. It was likely re-turning into GPS satellites. |
You're expected to filter your own data as-desired. The plugin will not perform any judgement upon the data. |
There was no fresh location data, so it re-played/re-inserted the last 100 received location records? |
on that particular device, yes. Realme devices tend to be some of the worst offenders for odd behaviour. |
Is there any situation where a large age number is not likely to be a redundant entry? It would be nice if we could filter based on age, event or some other attribute to know which data to trust as new. The event value seems to nearly always be null even though the documentation says it should be something else. Is that another case of "the device is screwy"? |
Yes, particularly on latest Android 14, where there are more strict limitations on when Foreground Services may be launched from the background (eg: calling
This isn't related to your issue. |
But is it possible to address the question anyway? It was one of the two
original concerns we raised when logging this issue.
…--
Tom Rupsis
Granite Peak Systems
Phone: 406-672-8292
Email: ***@***.***
On Mon, Apr 15, 2024, 9:08 AM Chris Scott ***@***.***> wrote:
Is there any situation where a large age number is not likely to be a
redundant entry?
Yes, particularly on latest Android 14, where there are more strict
limitations on when Foreground Services may be launched from the background
(eg: calling .getCurrentPosition from the background where the plugin
will *at least* return the last-known location if the OS doesn't allow
location-services to be turned on).
The event value seems to nearly always be null even though the
documentation
This isn't related to your issue.
—
Reply to this email directly, view it on GitHub
<#1993 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF52MZ26VBBGPSRF5GX7KZTY5PUPDAVCNFSM6AAAAABGCXUXEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXGA4TCMRUGQ>
.
You are receiving this because you authored the thread.Message ID:
<transistorsoft/react-native-background-geolocation/issues/1993/2057091244
@github.com>
|
But is it possible to address the question anyway? It was one of the two original concerns we raised when logging this issue. |
Restating from original post...
|
It’s supposed to generally be unset. |
Two issues/questions.
Why are we seeing nearly identical records inserted to the SQLLite db 10 minutes apart? In the attached log, see that UUID=24cbed22-c547-43b1-b9b9-ae0e0e7c7bca is inserted to the db at 04-11 07:24:07.830 (IST) and then UUID 4faa7d99-b8d2-4412-a415-84df5c4f9a6d is inserted to the db at 04-11 07:34:09.860 (IST). The records have identical timestamp and location data. The only differences are is_moving (true on the first, false on the second), age (90 on the first, 602120 on the second), and activity.type (walking on the first, still on the second). The device was set to GPS enabled but no network access during this timeframe.
Why is event: null in nearly every record? The documentation says it is a string and should have a value of motionchange, geofence, or heartbeat. Yet, throughout the entire period of this test, only a few records ever reflect one of those values.
Your Environment
System:
OS: macOS 14.4.1
CPU: (8) arm64 Apple M2
Memory: 107.06 MB / 8.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 16.20.2 - ~/.nvm/versions/node/v16.20.2/bin/node
Yarn: 1.22.21 - ~/Documents/GitHub/alt-tomrex-app/node_modules/.bin/yarn
npm: 8.19.4 - ~/.nvm/versions/node/v16.20.2/bin/npm
Watchman: 2024.01.22.00 - /opt/homebrew/bin/watchman
Managers:
CocoaPods: 1.15.0 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 23.2, iOS 17.2, macOS 14.2, tvOS 17.2, visionOS 1.0, watchOS 10.2
Android SDK: Not Found
IDEs:
Android Studio: 2023.1 AI-231.9392.1.2311.11330709
Xcode: 15.2/15C500b - /usr/bin/xcodebuild
Languages:
Java: 15.0.2 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 16.13.1 => 16.13.1
react-native: ^0.64.0 => 0.64.4
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Plugin version: "react-native-background-geolocation": "^4.15.0"
Platform: iOS or Android : Android
OS version: 12
Device manufacturer / model: realme 7 pro
React Native version (react-native -v): 0.64.0
Expected Behavior
A location record should only be inserted to the SQLLite database a single time. Each record should have one of the defined event values.
Actual Behavior
While offline (network access turned off), we see the same location inserted to the database multiple times. In some other tests, this has happened many more times than just twice. Event values on posted data nearly always has event:null.
Steps to Reproduce
Put device into offline mode while keeping GPS enabled. Walk, drive, or otherwise move around (to ensure different GPS locations are recorded as in our test data).
Context
We are trying to figure out how the library is producing so many redundant submissions to our API. In our production environment, we are seeing API posts that grew and grew and grew. We have since limited the maxBatchSize to 10, but the batching is not stopping the duplicate insertions. We can't figure out why the library is inserting nearly the same data 10 minutes apart. Somehow some part of the old data is being cached by the library and re-inserted after some other event?
Debug logs
Logs
[APILog of ClientID_ 61.xlsx](https://github.com/transistorsoft/react-native-background-geolocation/files/14949541/APILog.of.ClientID_.61.xlsx) [SuccessLogsRealme.log](https://github.com/transistorsoft/react-native-background-geolocation/files/14949542/SuccessLogsRealme.log)The text was updated successfully, but these errors were encountered: