transistorsoft / flutter_background_geolocation

Sophisticated, battery-conscious background-geolocation & geofencing with motion-detection
https://www.transistorsoft.com/shop/products/flutter-background-geolocation
Other
629 stars 231 forks source link

Duplicate locations detected #1307

Open KlipX opened 3 weeks ago

KlipX commented 3 weeks ago

Package detects and emits locations that have a new uuid but are duplicates because every other parameters are the same.

Your Environment

Doctor summary (to see all details, run flutter doctor -v): [✓] Flutter (Channel stable, 3.22.1, on macOS 14.1.1 23B81 darwin-arm64, locale pl-PL) [✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0) [✓] Xcode - develop for iOS and macOS (Xcode 15.3) [✓] Chrome - develop for the web [✓] Android Studio (version 2022.3) [✓] VS Code (version 1.90.0) [✓] Connected device (5 available) [✓] Network resources

• No issues found!

Expected Behavior

All locations events should be unique.

Actual Behavior

Currently, the package detects and emits event locations that have a new uuid but are duplicates because every other parameter is the same.

Steps to Reproduce


Context

My application tries to track a user's walk.

Hi, great package and thanks for your work. I facing some issue I don't understand why the package detects two events with the same coordinates. Why does it randomly detect old samples and put them into database? The only difference between the samples is the age, but the timestamp is the same so they are the same samples. In my case, I need to filter the samples by timestamp, not uuid, to make sure I don't have duplicates. Below I send an example of duplicate locations and also below this full logs from this walk.

I not sure but it can be related to https://github.com/transistorsoft/flutter_background_geolocation/issues/804

Debug logs

Example of duplicate events ``` ╔═════════════════════════════════════════════ ║ TrackingService: LocationResult ╠═════════════════════════════════════════════ ╟─ 📍 Location[fused 50.271479,19.019027 hAcc=5.145 et=+1d1h16m57s136ms alt=322.20001220703125 vAcc=1.0888693 vel=1.3144758 sAcc=0.17083769 bear=211.42012 bAcc=45.0] ╟─ Age: 40ms, time: 1718091016926 06-11 09:30:16.968 DEBUG [AbstractService a] ⚙️︎ FINISH [TrackingService startId: 98, eventCount: 0, sticky: true] 06-11 09:30:16.969 DEBUG [TSLocationManager onLocationResult] ╔═════════════════════════════════════════════ ║ Process LocationResult ╠═════════════════════════════════════════════ 06-11 09:30:16.971 DEBUG [TSLocationManager d] Distance from last location: 11.399263, apparent speed: 1.6699771 06-11 09:30:16.973 DEBUG [TSLocationManager a] Median accuracy: 5.145 06-11 09:30:16.976 DEBUG [TSLocationManager c] Odometer: 993.47363 06-11 09:30:17.002 INFO [SQLiteLocationDAO persist] ✅ INSERT: ac4463c5-ef03-4b6a-98fe-4238c7205085 06-11 09:30:22.138 DEBUG [AbstractService a] 🎾 start [TrackingService startId: 99, eventCount: 1] 06-11 09:30:22.140 DEBUG [TrackingService c] . . 4 minutes later . . ╔═════════════════════════════════════════════ ║ TrackingService: LocationResult ╠═════════════════════════════════════════════ ╟─ 📍 Location[fused 50.271479,19.019027 hAcc=5.145 et=+1d1h16m57s136ms alt=322.20001220703125 vAcc=1.0888693 vel=1.3144758 sAcc=0.17083769 bear=211.42012 bAcc=45.0] ╟─ Age: 250753ms, time: 1718091016926 06-11 09:34:27.681 DEBUG [AbstractService a] ⚙️︎ FINISH [TrackingService startId: 98, eventCount: 0, sticky: true] 06-11 09:34:27.681 DEBUG [TSLocationManager onLocationResult] ╔═════════════════════════════════════════════ ║ Process LocationResult ╠═════════════════════════════════════════════ 06-11 09:34:27.683 DEBUG [TSLocationManager d] Distance from last location: 11.399263, apparent speed: 1.6699771 06-11 09:34:27.685 INFO [SQLiteLocationDAO persist] ✅ INSERT: 4b3f4487-88f7-49e8-a02a-234c324d1926 06-11 09:34:27.685 DEBUG [TSLocationManager a] Median accuracy: 5.145 06-11 09:34:27.687 DEBUG [TSLocationManager c] Odometer: 2301.656 06-11 09:34:27.696 INFO [SQLiteLocationDAO persist] ✅ INSERT: a9283389-0a8f-4855-a3c9-b1e64d977c3d 06-11 09:34:27.707 DEBUG [AbstractService a] 🎾 start [TrackingService startId: 99, eventCount: 1] 06-11 09:34:27.709 DEBUG [TrackingService c] ```

Full logs on file for git limit reasons

logs-background-geolocation.log

efalco777 commented 3 weeks ago

Great that you're posting, I'm having the same issue. Any help?

christocracy commented 3 weeks ago

fastestLocationUpdateInterval: 500,

Why are you configuring that? The native Location API is likely delivering multiple locations for each location update, which the plugin iterates over and does an INSERT for each one received. Try removing that option completely and test again.

fastestLocationUpdateInterval controls the rate that your app receives locations from other apps (eg: Google Maps). With such a high interval, you're likely causing extra locations to be pushed into your app from another app.

christocracy commented 3 weeks ago

I think you just have location-updates coming in unusually fast.

KlipX commented 3 weeks ago

I think you just have location-updates coming in unusually fast.

First of all, thank you for your quick response.

I will check it, but the period between duplicates is 4 minutes so it isn't fast.

To be on the same page. Do I understand correctly fastestLocationUpdateInterval - determines how often my application receives updates from other applications. But it still receives updates every distanceFilter(10 meters), even if it is faster than fastestLocationUpdateInterval?

And also why my fastestLocationUpdateInterval is to fast? Default value is 30000 in that time user can move long way.